myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <simon.lessar...@gmail.com>
Subject Re: [Trinidad] about CollectionModel semantics
Date Wed, 05 Sep 2007 15:01:51 GMT
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 <renzo.tomaselli@tecnotp.it> 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* < renzo.tomaselli@tecnotp.it> 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* <renzo.tomaselli@tecnotp.it> 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
>
>
>
>
>

Mime
View raw message