Re: [Trinidad] about CollectionModel semantics

[Renzo Tomaselli]

Thanks Simon. As a further guess - I think we have to distinguish between phase usage of such methods. I presume (hopefully) that position-based indexing is used only during rendering, and *not* during restore view/update model. In other words, we told the component to render a range [first, first + rowsPerPage -1], and only there I expect that row retrieval occurs by position, calling setRowIndex/getRowData/getRowKey along that range. At that point the game is consistent, since we are still retrieving data from the business layer. But I expect that during restore view/update model, only setRowKey/getRowData is used (if any updating is required), since the business layer might have changed positions in the mean time. Do you confirm that ? -- Renzo Simon Lessard wrote: 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