cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Epheser <>
Subject Re: GSoC, repeater pagination in place
Date Fri, 28 Jul 2006 15:13:25 GMT
Simone Gianni schrieb:
> Hi all,
> I just committed the repeater pagination made by Matthias for his GSoC.
> He's here with me in Rome now, so that we can work together on this
> stuff. Could you please review it? We tested it on a big application
> where repeaters are used to display very big lists (11k items) backed by
> hibernate, and it works correctly.
> There are still some open problems for which we'd like to receive
> feedback from the community, Matthias will explain them.
> P.S. Google Maps stuff is also already working, we're now evaluating the
> possibility to add geocoding facilities in it, will hear about it in
> near future.
> Simone


As Simone mentioned we are currently working together on the repeater 
pagination. I want to explain shortly how it works what problems still 

Pagination can now be achieved by just adding a <fd:pages initial="1" 
size="20"/> tag to the repeater's definition. I added repeater actions 
as well for first, previous, next and last page.

The actual pageLoad/pageSave takes place in the binding. A storage area 
is used there to cache updated rows on page change. Once the user 
submits, the actual saving to the JXPathContext takes place.

To support really big lists managed by a persistency frameworks (like in 
the application Simone mentioned) we implemented the possibility to use 
"lazy collections". A lazy collection is simply an implementation of the 
java.util.Collection interface that knows how to handle size()- or 
get(i)- calls without fetching the whole data from the db.

Another feature we want to implement is sorting, more precisely 
displaying sorted rows. It's not our intention to actually store the 
data to the object in a different order but to make it possible for the 
user to click on the column-header and get the rows displayed in 
ascendant/descendant order. We think we need some data-providing class 
that act as a layer between the binding storage and the repeater rows, 
that provides sort(columnName) and getRows(from,to) or similar. We now 
have to evaluate how this could be done in a decent way and keep the 
door open for our lazy list here.

Concerning this we face some "indexing problems" after a page change. 
Row additions/deletions and sorting change the order and count of rows, 
therefore we need a technique to obtain the right start-index when we 
jump to a custom page. It's not guaranteed that our start-index in the 
collection is 100 if pageSize=10 and requestedPage=10.

These are our thoughts about it:

The previous and next actions are still able work because we could 
remember the fist and last index of the current page and start relative 
to them to fetch the next n rows.

First and last page could work the same way using 0 and collection.size().

So the problem is located in the goto-widget. We are thinking of a 
couple possible solutions. Precise positioning would only be possible if 
we use iteration and check all rows to compute the correct starting 
point. Another solution would be to use "approximative" starting 
indexes. That means that, facing large collections, we always take 
pageSumber*pageSize as the starting index after the custom-page action. 
This approach solves the (maybe resource intensive) iteration problem 
but could provide results that are not exact. Another option would be to 
move this problem to the not yet existing data-providing class I 
mentioned in the sorting part.

Do you think it's a real problem to have not exact starting indexes 
while jumping between pages in big repeaters?


View raw message