Hi I think the reason for the iterators is that you will be able to implement an iterator to anything, for example my PagingScrollTable is filled by a service that returns an JS Array of JS Object, I implemented my own iterators that use JSNI, so i dont need to transform the service result to a list of list.
I have liked the PagingScrollTable so far but is true that it took me some time get it right, i like the idea of removing the need of passing a dataTable and a header table, but i think maybe creating another subclass that has a default header table of one column per row its better maybe somthing like SimplePagingScrollTable, I like the flexibility of passing your own HeaderTable PagingScrollTable On Nov 15, 12:20 pm, dflorey <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
