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
Hi,
As Simone mentioned we are currently working together on the repeater
pagination. I want to explain shortly how it works what problems still
exist.
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?
Regards,
Matthias
