Some more observations regarding PagingScrollTable: Right now the developer is responsible for calling setRowCount on the table model after retrieving data. If you don't call this method you'll get strange results like flashing empty table + endless paging.
Unfortunately there is no method like "getRowCount()" defined in the Response. The if you are using paging in conjunction with remote requests there is no way to get the number of total available rows (they differ from the actual requested rows as they are limited by the page size). Proposal: Add the getRowCount() method to the Reponse and call the setRowCount on the table model in the callback. I've implemented this in my branch. While implementing this I found it very annoying that Iterators are used heavily insted of Collections, so you can never tell easily how many rows are available in total. What is the reason for using Iterators instead of Collections? Maybe it's just me but my guts tell me Iterators are error prone and scaring... --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
