How about sticking this info in the wiki? More documented information about the behavior of perserveDataModel would be great!
On 9/1/05, Enrique Medina <[EMAIL PROTECTED]> wrote: > 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? >
