Hi Leszek,
Leszek Gawron wrote:
> What about:
> - goto a specific page action
> - change page size action
The goto a specific page action already exist in some preliminary form,
we should solve the page to index conversion problem before actually
have a working one.
>
> I would like to propose something else:
> public interface ValueListProvider() {
> public List getRows( SomeContextForFilteringAndSorting context, long
> offset, long rowCount );
> public long getTotalRowCount( SomeContextForFilteringAndSorting
> context );
> }
Actually we decided to use the List interface for it, and on the test
project we have a List implementation that actually works on a Hibernate
Criteria in a way that it's able to retrieve blocks of records from
hibernate and ask directly to the database the size, only implementing
some basic methods of the List interface.
>
>> 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.
>
>
> It may be a little bit too hot here because I cannot think of a reason
> why. Why is that?
We have a collection gained from the load binding, and then some
deletions and additions made to this collection, which are not in the
collection until the save method of binding is called. This means that i
have page 1 going from item 0 to item 10 of the collection, but if
element 5 has been deleted (actually marked for deletion) page 1 goes
from 0 to 11, and page 2 starts at 12 instead than 11, and so on.
What makes this harder is the fact that saying "element 5 has been
deleted" is relative to the actualy sorting of the table, since if we
change the sort order the previous element 5 could now became element
35, and so shift only form the page 3 on.
>>
>> 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().
>
>>
>> Do you think it's a real problem to have not exact starting indexes
>> while jumping between pages in big repeaters?
>
>
> I would rather have a little bit inexact results than something that
> would kill my server if 100 users used it at the same time.
Yep, we are asking this because it could be possible that we don't
manage to have precise indexing on a sorted repeater without fetching
all elements in the collection, but we could use approximate positioning
(like, page 5 starts at 50) and then adjust it as needed if we manage to.
So it means +1 for not precise positioning over performances.
Simone
