myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Working With DataTable And PreserveDataModel" by Enrique Medina
Date Thu, 01 Sep 2005 15:34:48 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by Enrique Medina:
http://wiki.apache.org/myfaces/Working_With_DataTable_And_PreserveDataModel

New page:
I must admit I was using the preserveDataModel functionality without really knowing what was
going behind and, most important, its implications in my application's behaviour.

So I just wanted to share my thoughts with anyone who might be using this functionality and
might find this information useful ;-)

Basically, the preserveDataModel attribute allows to store the collection of objects that
is being populated in the dataTable somewhere, so sometime when it is needed by the application,
it can be restored directly from that 'somewhere' location. So the main question is: where
is 'somewhere'? and when is 'sometime'? Understanding these couple of concepts makes the use
of this functionality a child's play ;-)

Let me explain it with an example for the sake of clearness and comprehension.

Imagine you have a list of cars you want to present to the user. So your application shows
a link to show the dataTable from a main window. The user clicks on the link, so he is forwarded
to the page where the dataTable is defined. Two situations can happen:

a) If the dataTable is defined with its preserveDataModel set to "true", then the data from
your backend will be requested twice:

1) One in the RENDER PHASE by the HtmlTableRenderer as a consequence of the execution of the
HtmlTableTag doEndTag() method (obviously to be able to 'paint' the data in the view)
2) Another one again in the RENDER PHASE, but this time due to the execution of the ViewTag
doAfterBody() method, that in turn calls the UIViewRoot processSaveState() method, and then
the HtmlDataTable saveState() method. More precisely, when saving the state of the dataTable,
as we have set preservedDataModel to "true", the data is again request from the backend to
be serialized and stored in the session (if server state saving) or the client (if client
state saving, gzipping and base 64 enconding it).

b) If the dataTable is defined with its preserveDataModel set to "false", then the data from
your backend will be requested only once (as there is no need to serialize the data):

1) In the RENDER PHASE by the HtmlTableRenderer as a consequence of the execution of the HtmlTableTag
doEndTag() method (obviously to be able to 'paint' the data in the view)

Once the view where the dataTable is defined is rendered, imagine your user clicks on the
scrollers (e.g. the 'next' link). Again, two situations can happen:

a) If the dataTable is defined with its preserveDataModel set to "true", then the data from
your backend will not be requested at all neither when applying the request values nor when
updating the model values, as the data will be retrieved directly from the previously serialized
data.

b) If the dataTable is defined with its preserveDataModel set to "false", then the data from
your backend will be requested at the APPLY REQUEST VALUES phase.

Lastly, the Render phase will occur just equal as decribed before...

What are the implications about this approach? Consider the case of having preserveDataModel
set to "false" and clicking on the "next" click to navigate to the next bunch of data. As
described above, the data from the backend will be requested in the APPLY REQUEST VALUES phase,
so lately in the UPDATE MODEL phase the changes will be applied to the data recently retrieved
from the backend, which is not guaranteed to be the same as the one the user was seeing before
clicking on the link. In resume, maybe we are working with stale data (big problem, indeed).

But if we take the same approach, but using preserveDataModel to "true", the data used to
update the model will be exactly the same that the client was seeing before, so we can be
sure that no strange behaviour occurs. (Please note that this does not prevent from having
and old version of the data, as it might have changed between these requests...).

Mime
View raw message