Forum OpenACS Development: Re: SharePoint: AJAX Tables for List Builder?

Collapse
Posted by Nathan Lunt on
Currently, the list builder does not have the AJAX functionality you're looking for. That said, I've done some work using YUI's Datatable widget (See http://developer.yahoo.com/yui/examples/datatable/index.html) as a list template (replacing table.adp), and I've also created a version of file-storage's folder-chunk that does the AJAX pagination and sorting. Extending that to inline cell-editing would be pretty trivial, as well.

Unfortunately, the work I've done really works around the list builder and doesn't really accomplish the goal you're hoping for (global integration of these features) because the code is page/package specific, however, I believe it has the potential to be put us significantly closer to that result.

To make the list builder do everything required, there are essentially two pieces missing: A mechanism to define the external data source (usually JSON), and a mechanism to define more properties for columns, such as sortablity, visibilty, data type, cell editor to use, etc.

Long story short: the bad news is that this isn't not currently possible, but the good news is that we (particularly Dave Bauer, Ryan Gallimore and me) have been discussing AJAX integration in OpenACS pretty extensively over the last few months and if those plans are achieved, the feature you're requesting will occur naturally.

Collapse
Posted by Frank Bergmann on
Hi Nathan,

Great to see there's work going on.

works around list builder

I know that there are many fans of the current List Builder around. We also use it a lot in ]po[, but only for small lists, because of it's client-side only pagination. So I don't expect that our requirement of server-side pagination will become part of an OpenACS standard...

inline cell-editing

I believe you're underestimating this one. At least in ]po[ we are working with DynFields (Quest name: FlexBase, an extension of AMS) to determine the widgets for editing object attributes. "Widgets" frequently contain the ranges of values for drop-down boxes, but can also include default values, security permissions and data range constraints. Widgets would also include AJAX stuff like calendar selects, auto-completion fields etc.

Also, you'll need a generic "receiver" for the results from in-line editing, which is definitely not trivial. This receiver would have to perform data-range and permission checking (permissions in DynField can be per column) and possibly convert object names to object IDs etc.

So I think that inline editing would be tightly related to Form Builder...

Could you please let us know if you are progressing on your side?

Thanks for your reply!
Frank

Collapse
Posted by Nathan Lunt on
YUI's datatable widget has a range of default cell-editors for specifying various datatypes, and it also provides a mechanism for creating new ones.

You bring up an interesting point with form builder, though. It sounds like we need a datatable form template.

Collapse
Posted by Malte Sussdorff on
Frank, you mentioned:

We also use it a lot in ]po[, but only for small lists, because of it's client-side only pagination

What do you mean by client side only pagination? Last time I developed with list builder (http://cognovis.de/developer/en/list_pagination) the pagination made sure only to retrieve the rows from the database which were needed to display the result to the end user, taking into account any filters first.

With regards to the editing of table values with widgets, I am wondering if from a user point of view we provide an editable version of the table (actually displaying a table with from builder) or if we are providing a cell based editing (e.g. if you click on a value, a single widget form pops up which allows you to edit the content if you have editing permissions, otherwise just use the display part of formbuilder).

Collapse
Posted by Michael Aram on

I just wanted to mention here that I am currently developing a specialization of xotcl-core's TableWidget called ::YUI::DataTable, which progressively enhances the markup generated by the TableWidget.

It behaves a little bit different compared to the standard OpenACS tables regarding the form, which wraps the table. Instead of changing the forms "action" attribute via JavaScript when the user clicks on a bulk-action, I implemented each bulk-action as a submit button. The value of the button represents the method called on the object, which "sits behind" the action-url of the form.

However, this code is subject to frequent changes and currently not very well isolated. I will publish it as soon as it is mature enough (beta or so).

Collapse
Posted by Nathan Lunt on
That's essentially what my Datatable table.adp list template does. My table.adp is a drop-in replacement for the existing one and does progressive enhancement. I actually did it for cosmetic reasons (to match other non-list Datatables), and to get the row highlighting. Beyond that, the only thing I can think of that this provides is client-side sorting, which ultimately is quite difficult to do right in a template because of the varying data types.

If we could define data types for the columns and specify a URL for retrieving JSON data to populate, we'd have pretty much everything we need for an "ajaxified" table except inline editing, but as mentioned previously, the inline editing might be better handled by a form template. I'm really not sure about that, yet.