GWT 2.1 cell table paging bug?

[Sebastian Beigel]

AbstractPager uses HasRows#getVisibleRange()#getLength() to obtain the
page size. This doesn't seem to be a good idea as you can see in the
Showcase exmpale (Cell Widgets/Cell Table [1]).

This table gets populated with 250 entries and shows 15 per page. Now
click on the "next page" button. You go (correctly) all the way to
showing "226 - 240". But the next click switches to "236 - 250". I
expect the table to go to "241 - 250" (and thus showing only 10 rows).
But it gets worse: If you now start to navigate back, the display
range is moved by this offset. So you reach "11 - 25" and then "1 -
15"?!

I don't think this behaviour is intentional. At least the "go to last
page" and "go to first page" buttons work properly (showing "1 - 15"
and "241 - 250").

Bug?

Sebastian

[1] http://gwt.google.com/samples/Showcase/Showcase.html#!CwCellTable

[sebrojas]

Yes, is a bug!

Also, I´m having other problems with celltable paging.
When I set the page size to 12 or less, and I click the button next
page or last page, and rows away is a picture of charging that is not
removed.
When I set the page size in 13 or more, and I click the button next
page or last page, and then on the previous page shows several rows
without values (the first).
Please answer, need help
I don´t understand why the pager have a setPageSize method and the
dell table too??? :s, but it seems to the table method is the one that
have effect

...
ProvidesKey<Depuracion> pk = new ProvidesKey<Depuracion>() {
public Object getKey(Depuracion item) {
return item.getId();
}
};

final CellTable<Depuracion> table = new CellTable<Depuracion>(pk);
table.addStyleName("tabla");
table.setPageSize(8);

// Create a Pager to control the table.
SimplePager.Resources pagerResources = GWT
.create(SimplePager.Resources.class);
pager = new SimplePager(TextLocation.CENTER, pagerResources, false,
0,
true);
pager.setDisplay(table);
...

[Arnaud]

I have exactly the same problem than sebrojas, if someone has a
solution. Would appreciate any help.

Thanks
Arnaud

[manstis]

I encountered the same problem :-(

What's more ominous is that the change in visibleRange also causes a
second onRangeChange event (which is undesirable if nothing else): (1)
For the initial page forward to the last page (with potential unequal
number of rows to pageSize) and (2) For the re-rendering of the last
page with visibleRange set to show pageSize rows but indexed from
display.getRowCount() - pageSize (as noted by OP).

I found a fix however, by overriding setPageStart in SimplePager, as
follows:-

public void setPageStart(int index) {
if ( getDisplay() != null ) {
Range range = getDisplay().getVisibleRange();
int pageSize = range.getLength();
if ( isRangeLimited()
&& getDisplay().isRowCountExact() ) {
pageSize = Math.min( pageSize,

getDisplay().getRowCount()
- index );
}
index = Math.max( 0,
index );
if ( index != range.getStart() ) {
getDisplay().setVisibleRange( index,
pageSize );
}
}
}

This shows the last page with a number of rows less than pageSize if
getRowCount() is less than pageSize * numberOfPages.

I hope it is of use.

Cheers,

Mike

[zixzigma]

I do not think this is a bug,
and in fact I found the current implementation very desirable.

your table always shows X number of rows per page, even if its the last page.
with this implementation your table will always have the same height, and same number of rows.
and you dont have to deal with cases where there is only 1 or two items in the last page,
which might make your UI look inconsistent.

I believe making the table to act this way is more difficult than traditional way of paging,
because you have to do some range manipulation, check if its last page,
and if so, display enough rows for table pageSize to be met. and GWT CellTable already does this.

[Jeff Schwartz]

On Tue, Feb 1, 2011 at 3:16 PM, zixzigma <zixz...@gmail.com> wrote:

I do not think this is a bug,
and in fact I found the current implementation very desirable.

your table always shows X number of rows per page, even if its the last page.
with this implementation your table will always have the same height, and same number of rows.
and you dont have to deal with cases where there is only 1 or two items in the last page,
which might make your UI look inconsistent.

Unfortunately the paging mechanism in GWT v2.1 is inconsistent when using the mouse and the keyboard to scroll a paged table. When using the mouse it works the way you describe but when using the keyboard and scrolling down to the last page you will sometimes get an 'odd' number of rows.
 

I believe making the table to act this way is more difficult than traditional way of paging,
because you have to do some range manipulation, check if its last page,
and if so, display enough rows for table pageSize to be met. and GWT CellTable already does this.

Yes, I agree.
 
Jeff

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff Schwartz

[Steve]

This behavior deviates from widespread usage of pagination across the web so I don't see how it's desirable to do something unexpected by users unless it's clearly superior.

When I navigate from one page to another it's because I want to see the next set of results/data and I expect the stuff at the top to be different than what was on the previous page I was on. If it overlaps, then I have to scan down and figure out where to start looking.

[Emilian Bold]

I agree. The current GWT pagination seems to be more of a workaround.
They try to avoid having less items on the last page because it might
change the layout and the pager position.

What should actually happen is that the table should maintain the full
height as if it has all the rows, but display only the few remaining
rows on the last page.

Basically, the table should have the same height regardless of the
number of rows and the pager component should remain in place when
switching pages.

I'm surprised there isn't an actual bugreport for this.

--emi

[Patrick Tucker]

I'd star the issue if some filed one.

[JahSon]

If you want the table height to remain consistent, couldn't you wrap the table in a containing element (e.g. div) of a fixed height?  That way, if you display the pager directly underneath the table for example, it will always stay in the same spot and just the table itself will shrink.

I prefer manstis' (Mike's) fix to the default behavior of AbstractPager.  I couldn't agree more with Steve's remarks.  To reiterate: when you page over, I would expect to see a new result at the start of the table.  Yes, that means the table must shrink, but you can use CSS to deal with that.

I also want to reiterate manstis' concern of a second RangeChangeEvent being fired.  I would think this behavior to be extremely undesirable as I would imagine most of us are performing a server side call to a database to retrieve more data in onRangeChange().  So a needless call to the server will be made.  This is bad!

I think that the behavior of AbstractPager should be modified and manstis' implementation of setPageStart() should be the default.  Perhaps a boolean configurable (restrictVisibleRowsToPageSize) should be added which allows for the user to utilize the current behavior of setPageStart().

Just in case anyone else comes across this post, it should also be noted (I found it very confusing, at least) that while setting AbstractPager.isRangeLimited via AbstractPager.setRangeLimited() will make the next page and last page buttons behave the same (showing only new data, even if less than pageSize) it is not a solution to this problem because then the next and last page buttons will not be disabled.