You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/12/07 14:28:49 UTC
[cforms] Repeater and large collections
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.
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?
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?
WDYT? Other suggestions?
--
Reinhard
Re: [cforms] Repeater and large collections
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
>
>
> 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?
>
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=30213
>
> you'll make a few users@ people (including me) happy if you can adapt
> the patch to Sylvain's liking and land it on the trunk :-)
>
> Regards
> Jorg
>
>
Thanks for the pointer!
--
Reinhard
Re: [cforms] Repeater and large collections
Posted by Jorg Heymans <jh...@domek.be>.
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?
http://issues.apache.org/bugzilla/show_bug.cgi?id=30213
you'll make a few users@ people (including me) happy if you can adapt
the patch to Sylvain's liking and land it on the trunk :-)
Regards
Jorg
Re: [cforms] Repeater and large collections
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
>
> You put them in in your flow.
>
> function whatever() {
> // Create binding context, populate
> var context =
> Packages.org.apache.commons.jxpath.JXPathContext.newContext(bean);
> context.getVariables().declareVariable("first", 10);
> while (true) {
> form.load(context);
> ...
> }
Many thanks!
--
Reinhard
Re: [cforms] Repeater and large collections
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> 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 :-)
>>
>>
>>
>> Then, just don't bind what's not needed...
>>
>> <wb:repeater id="x" parent-path="."
>> row-path="data[position() >= $first and position() <= $last]">
>>
>>
>> Vadim
>>
>
> Where do $first and $last come from?
>
You put them in in your flow.
function whatever() {
// Create binding context, populate
var context =
Packages.org.apache.commons.jxpath.JXPathContext.newContext(bean);
context.getVariables().declareVariable("first", 10);
while (true) {
form.load(context);
...
}
Vadim
Re: [cforms] Repeater and large collections
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> 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 :-)
>
>
> Then, just don't bind what's not needed...
>
> <wb:repeater id="x" parent-path="."
> row-path="data[position() >= $first and position() <= $last]">
>
>
> Vadim
>
Where do $first and $last come from?
--
Reinhard
Re: [cforms] Repeater and large collections
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> 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 :-)
Then, just don't bind what's not needed...
<wb:repeater id="x" parent-path="."
row-path="data[position() >= $first and position() <= $last]">
Vadim
Re: [cforms] Repeater and large collections
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
<snip/>
> 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
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109950611823830&w=2)
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 ...
--
Reinhard
Re: [cforms] Repeater and large collections
Posted by Sylvain Wallez <sy...@apache.org>.
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] Repeater and large collections
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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?
I am doing pagination but use CForms only for handling actions and
buttons. I do not render rows with a repeater. It is implemented by a
set of jx macros. The control allows for following:
- display a set of rows
- display navigation (first, prev, next, last)
- control the number of rows displayed
- seek to a specified page
- filter the results with cforms widgets
>
> 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.
>
> 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?
each row having a checkbox and a delete action. Would have to fetch ids
to delete by yourself (out of CForms).
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65