myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <>
Subject Re: New "initId" attribute
Date Tue, 21 Jun 2005 08:50:07 GMT
I agree with Manfred that preserveDataModel is quite efficient in it's
But it doesn't solve the same kind of problem.
preserveDataModel allows you to keep user modifications between
rowId would allow you to avoid concurrency problems as just using the
preserveDataModel can't be safely used to modify critical data.

The rowId approach is absolutely safe and efficient as no data is
It's also a very light modification as only the UIData.getClientId needs
to be overridden.

By the way, maybe a more explicit attribute name would be rowClientId.


On Tue, 2005-06-21 at 09:33 +0200, Manfred Geiler wrote:

> What do you mean by "preserveDataModel is too aggressive"?
> It was introduced to exactly solve this common problem. Fact is, we
> want UI components that behave as simple as fat client components
> (Swing) do. What we expect is, that when an action is fired, a table
> must not be changed in the meantime (regardless of what happend
> technically in the meantime: response, request, post parameteres,
> etc.). A data refresh must not happen before the new render phase
> starts. And: the component user should not have to bother with these
> kind of issues. Only thing he needs to worry about: the row objects
> must be Serializable and should be lightweight. If they are not, than
> wrap them! That's the difference between business objects and GUI
> display objects as was mentioned before in this thread.
> BTW, preserveDataModel does only save the 5 displayed rows of the
> 1000. So, for 99% of user interfaces (where there are not displayed
> 1000 rows on one page) the saved DataModel does not blow up the
> transferred data amount at all.
> -Manfred
> 2005/6/21, John Fallows <>:
> > Hi Sylvian,
> > 
> > On 6/20/05, Sylvain Vieujot <> wrote:
> > >  The solution you propose with an attached state is the same as the
> > > x:dataTable's preserveDataModel attribute which solves the problem by ...
> > > storing the data model.
> > 
> > I was quite deliberate in avoiding the assumption that we would need
> > to store the entire data model, and I agree that preserveDataModel is
> > too aggressive in this regard.
> > 
> > Wouldn't it be sufficient to only capture the mapping for rows
> > currently being displayed?
> > 
> > For example, even if the whole data model has 1000 rows, but only 5
> > are being displayed, why would we need the mapping for the other 995
> > rows that are not displayed?
> > 
> > Kind Regards,
> > John Fallows.
> >

View raw message