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
|
