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

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).