Hello Renzo, Comments inline.
On 9/5/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > Hi, I'm using tr:table since a long time, where paging through large > data sets is implemented by my own CollectionModel. > But I still miss some logics behind CollectionModel methods I have to > implement. > AFAIK, the overall strategy is to use getRowKey/setRowKey to enable > content-based keys binding server model to client rendering, instead of > plain position-based indexing. This is important in concurrent cases > where the dataset might change across requests, and position would lead > to wrong rows. Yep, but that feature become much much more relevant with TreeModel. Then current row can be retrieved by getRowData (far from atomic, though). > But then why do we need to implement setRowIndex/getRowIndex too, which > defeats the previous purpose, falling back to position-based keys ? setRowIndex is, most of the time, faster. However, it cannot navigate through the depth of a TreeModel. Therefore, most of the time, you use the rowKey to select a specific element, or the first element of the depth you're interested in and then, if you need to loop, you use setRowIndex from 0 to rowCount for faster access. Also, it's required to support those method to be compatible with the other JSF components using JSF DataModel that CollectionModel extends. Hope it makes some sense, ~ Simon I guess that these two methods should be alternative, where > position-based indexing should be used only for non-mutable datasets. > However I noticed that all above methods are actually called by > component code. > Any comment will be appreciated. > > -- Renzo > > >
