Paginated Lists
Jon Wells
I checked out the latest source code in order to make use of your
paginated list impl class. I ran the TestTable app in hosted mode,
then added 500 records. I then went to the first "page" of records
and pressed the "Deep Remove" btn and nothing happened. I would have
expected the first record of the table to disappear. Am I correct in
my thinking and you're still working out the kinks or am I missing
something.
Also, are you working in Eclipse? My group is and I was wondering if
you had any objections to adding an eclipse project file to source
control or suggestions otherwise.
My goal for the next couple of days is to create a widget that
displays a paginated list and supports the ability to select rows of
the list, and "disable" some of the rows in the list for selection.
Jon
Sandy McArthur
new paginated code. I've packaged up the current code at:
http://code.google.com/p/gwt-stuff/downloads/detail?name=GWT-Stuff-20070131.jar
I still want to make a PaginatedEventList implementation that tries to
be more stable in the presented elements. For example, if you have 100
elements and the paginated list start is set to 50 so it currently
shows 50-99, when an element is inserted at index 0 of the backing
list the start in the paginated list is automatically updated to be 51
so the same set of elements are displayed. Currently, the elements in
the paginated list will be shuffled down so what was element 49 is now
50 and visible via the paginated list. Any thoughts on what that
feature should be called? Would people rather that behavior be the
default?
The "Deep Remove" button removes an item from the deepest list in the
hierarchy of lists between the table and the actual elements. As it is
now in the Table Test you have like:
1 . The Table
2. PaginatedEventList
3. Filtered List
4. Sorted List
5. The actual list of elements
Because the SortedEventList and FilteredEventList can obscure or
reorder some of the elements deep in the, it is possible "Deep Remove"
will remove an element that isn't made visible to the table. This is
probably the source of your confusion.
I am using IDEA, I haven't used Eclipse much. I have nothing against
providing an Eclipse project (or other IDE project files) to make
working with the source easier. I'd like to keep any IDE or non-
project related files out of the trunk to help keep the project clean
and environment neutral. I believe with a little cleverness and use of
svn:externals we could keep IDE configs in their own directory (/ide/
eclipse/... maybe) and pull the trunk in as if it were a child of
those project setting so one checkout would grab the settings and
trunk. See:
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
Sandy McArthur
Glazed List calls it and it's more accurate.
And unless there is a better suggestion I intend to name the ranged
list that updates it's start offset to keep the same elements visible
"SteadyRangeList".
Jon Wells
what the default behavior would be it does seem a little weird to have
your page changing dynamically, so I guess I would prefer the "steady"
version.
I just started using the paging stuff yesterday and so far it's been
going mostly ok, tho I found a possible bug. It seems that the
contains() method on PaginatedEventListImpl considers more than the
current "page". I peeked at the code and it just delegates the
contains call to the underlying list.
Sandy McArthur
> I just started using the paging stuff yesterday and so far it's been
> going mostly ok, tho I found a possible bug. It seems that the
> contains() method on PaginatedEventListImpl considers more than the
> current "page". I peeked at the code and it just delegates the
> contains call to the underlying list.
good catch, that would also mean the retainAll and removeAll methods
probably need to be fixed too.