myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <>
Subject Re: [Trinidad] about CollectionModel semantics
Date Wed, 05 Sep 2007 13:56:53 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Thanks Simon. As a further guess - I think we have to distinguish
between phase usage of such methods.<br>
I presume (hopefully) that position-based indexing is used only during
rendering, and *not* during restore view/update model.<br>
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.<br>
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.<br>
Do you confirm that ?<br>
-- Renzo<br>
Simon Lessard wrote:
  <meta http-equiv="Context-Type"
 content="text/html; charset=ISO-8859-1">
Hello Renzo,<br>
Comments inline.<br>
  <div><span>On 9/5/07, <b>Renzo Tomaselli</b> &lt;<a
 moz-do-not-send="true" href=""></a>&gt;
  <blockquote>Hi, I'm using tr:table since a long time, where paging
through large<br>
data sets is implemented by my own CollectionModel.
But I still miss some logics behind CollectionModel methods I have to<br>
AFAIK, the overall strategy is to use getRowKey/setRowKey to enable<br>
content-based keys binding server model to client rendering, instead of
plain position-based indexing. This is important in concurrent cases<br>
where the dataset might change across requests, and position would lead<br>
to wrong rows.</blockquote>
Yep, but that feature become much much more relevant with TreeModel.
  <blockquote>Then current row can be retrieved by getRowData (far from
atomic, though).<br>
But then why do we need to implement setRowIndex/getRowIndex too, which<br>
defeats the previous purpose, falling back to position-based keys ?</blockquote>
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,<br>
~ Simon<br>
  <blockquote>I guess that these two methods should be alternative,
position-based indexing should be used only for non-mutable datasets.<br>
However I noticed that all above methods are actually called by<br>
component code.<br>
Any comment will be appreciated.<br>
-- Renzo<br>

View raw message