myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Medina <e.medin...@gmail.com>
Subject Re: PreserveDataModel behaviour
Date Thu, 01 Sep 2005 15:36:17 GMT
As promised,

http://wiki.apache.org/myfaces/Working_With_DataTable_And_PreserveDataModel

2005/9/1, Enrique Medina <e.medina.m@gmail.com>:
> 
> Let me take it into the wiki then ;-)
> 
> 2005/9/1, Mike Kienenberger <mkienenb@gmail.com>:
> > 
> > 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 <e.medina.m@gmail.com > 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?
> > >
> > 
> 
>

Mime
View raw message