cocoon-dev mailing list archives

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


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

I think of holding a list of all repeater rows with data that has changed. A 
second list contains all rows that are displayed. When rendering the table, all 
rows of the "display-list" are shown, but if a modified row in the 
"modified-list" exists, its values are taken to be displayed.

The tricky part for me is the lazy loading from the business object because this 
  is in contradiction to the way how binding works today, isn't it?

Maybe we can work out a solution also including your binding ideas 

Anyway, I'm speaking withoug having looked into the code yet :-/ and I fear that 
it won't be easy to implement it, especially for me who hasn't touched cForms 
code in those deep layers yet.

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

For tables and selection lists, yep.
One of the points that should be thought through before we mark cForms as stable ...


View raw message