cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [cforms] Repeater and large collections
Date Tue, 07 Dec 2004 13:50:13 GMT
Reinhard Poetz wrote:

> Suppose you have a repeater that is bound to a potentially very large 
> collection of objects (e.g. a list with 8000 objects) provided by an 
> O/R-mapper.
> First, it is not a good idea to show all 8000 rows on one page. Some 
> kind of paginating functionality is needed. Does anyone have a working 
> "paging" solution?
> Second, I don't want to bind, let's say 10000 objects (means copying 
> 10000 objects!) to a repeater, though the user should have the 
> possibility to edit all rows.

Not binding everything is indeed a good idea :-)

> I can think of
> a) Don't use cForms for the table. Each row has an "edit" button and 
> after clicking it, a new page that only shows a single object opens.
>  + use lazy loading features of O/R mapping tool
>    --> low memory consumption
>  - works around the cForms framework
>    --> how to implement "mass operations" like deleting a group of 
> objects?

Even if you don't use CForms to display the table, you can still add 
checkboxes on each row to "manually" handle deletion.

> b) Use cForms and event handling "magic" to load as less objects into 
> the reapeater as possible.
>  + use cForms framework and its validation features
>  - when are the changed repeater rows written back?
>    --> a user browses the rows and he only changes some of the fields
>        the changes should only be written when the form is submitted.
>        This would require a destinction between changed rows and 
> temporary
>        rows that are shown. When saving the changed rows only those are
>        written back.
>        Question to the binding specialists: How difficult would an
>        implementation be? Or, any better ideas?

Interesting problem... I understand that you don't want changes to be 
committed when the user just asks for another page of the repeater.

That would require to hold a list of modifications "in front" of the 
actual collection. By "in front", I mean that when populating the 
repeater starting at a given index, you should check this collection for 
modified/deleted rows and fall back to the actual data collection. That 
would minimize the form data that must be held server-side.

The problem becomes tricky if you also want to allow reordering.

> WDYT? Other suggestions?

Something that really should be studied for this is the use of 
XmlHttpRequest to post only row data and update only the table.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message