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 14:21:17 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">
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&nbsp; 2 - which
now might lead to another row as compared to the previous rendering.<br>
-- Renzo<br>
Simon Lessard wrote:
  <meta http-equiv="Context-Type"
 content="text/html; charset=ISO-8859-1">
Hello Renzo,<br>
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.<br>
~ Simon<br>
  <div><span>On 9/5/07, <b>Renzo Tomaselli</b> &lt;<a
 moz-do-not-send="true" href=""></a>&gt; wrote:</span>
    <div>Thanks Simon. As a further guess - I think we have to
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</span>
Simon Lessard wrote:
    <blockquote type="cite"> 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;
wrote: </span>
      <blockquote>Hi, I'm using tr:table since a long time, where
through large<br>
data sets is implemented by my own CollectionModel. <br>
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. <br>
      <blockquote>Then current row can be retrieved by getRowData (far
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. <br>
Hope it makes some sense,<br>
~ Simon<br>
      <blockquote>I guess that these two methods should be alternative,
where <br>
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