Hmm, I'll have to test it out. normally, you Trinidad component should not rely on row indexes once a row key was provided for it (after first iteration though it). However, I'm not an InternalState expert yet, Adam might have something to say on that statement. As for what you should set with setRowIndex, simply the current value at that index. Trinidad should be able to deal with it, I don't think you have to do some mapping on your own.
Regards, ~ Simon On 9/5/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > Simon, ok but the point is that the CollectionModel I have to publish is > directly called to set/get rowIndex, and from the provided value it has to > go to the business layer. I would expect that such InternalState should hide > position-based calls on my model, using only keys. I miss the reason of > getting both kind of calls, which was my original question. > If the model is requested to set rowIndex to some value, which record > should if safely go to ? > On another side, row selection works through keys only (RowKeySet) and > that's nice. But model updating seems to work also on positions. > > -- Renzo > > Simon Lessard wrote: > > 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 > > > > > >
