Simon Kitching wrote:
>The t:dataTable does have attribute "preserveDataModel" which does
>preserve the data model. However it keeps the data for *too* long (ie
>doesn't refetch before render). Maybe t:dataTable should have another
>variant that preserves data from render to postback, but then clears
>it?
Hi Simon,
I think we are not talking about the same problem here. Beside the general
problem of h:dataTable and the spec, I think there's a simple bug in the
implementation of t:dataTable. Perhaps my description of approach 4 was
ambiguous. So let me explain again in detail:
In my opinion perserveDataModel should guarantee the following constraint:
"dataModel(previous rendering phase) == dataModel(postback)"
(see also [1])
What t:dataTable really does at the moment, is:
1) In rendering phase getAllItems() is called the first time.
2) If preserveDataModel is enabled, t:dataTable calls getAllItems()
!!!one more time!!! to save the data model.
...some minutes later the user submits the form
3) In the postback t:dataTable restores the data model from the
serialized data (step 2) instead of calling getAllItems().
So the current validation phase uses probably the same data as in the
previous rendering phase.
Problem:
But if the dataModel changes between step 1 and 2, the previous
rendering phase still uses the old version, while t:dataTable stores and
restores already the changed one. So preserveDataModel only reduces the
risk. The problem is shifted between step 1 and 2.
I think step 1 and 2 should call getAllItems() only once per request,
and they should use exactly the same data model for rendering and for
storing.
Please correct me, if I'm wrong.
thx,
Mathias
[1]
http://wiki.apache.org/myfaces/Working_With_DataTable_And_PreserveDataModel
