PreserveDataModel behaviour

[Enrique Medina]

Hi,

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...).

Do you agree with my thoughts? Do you know more implications? Am I misunderstanding something?