Hello Renzo, We're using it during rendering, but we're also using it during all other phases as well and it's quite understandable. Let take a table for example. Let say the table contains only one column with an input inputText component nodestamp. The renderer obviously has to loop through all elements to render all rows. All client ids will be name spaced using tableId:rowIndex:inputId. Whatever the phase we're in, we have to run it on every row, thus looping through all elements is again required. Since rowKey does not provide looping API, we have to do that usins row indexes.
Regards, ~ Simon On 9/5/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > 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 > > > >
