Hello Renzo, There's an InternalState that we use to keep the mapping toward the rowKey during those phases to handle that issue.
Regards, ~ Simon On 9/5/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > Simon, not sure I got it. If you use rowIndex to identify a row during > update model, how do you provide consistency ? I thought that rowKey was > introduced exactly to avoid any potential mismatch when rows have to be > reloaded from the business layer. Thus if we need to update a field of the > third row, my guess was that this CollectionModel allows for asking the bean > for that row by key - not by position 2 - which now might lead to another > row as compared to the previous rendering. > > -- Renzo > > Simon Lessard wrote: > > 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 > > > > >
