myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <svieu...@apache.org>
Subject Re: New "initId" attribute
Date Wed, 03 Aug 2005 14:17:58 GMT
Hello Martin,

I still have this problem with the item ids in tables.
As a quick reminder, if your item's list isn't constant, changing some
data from components embeded in the table's row sometimes apply to the
wrong row as the id's are numbered 0, 1, ...
Exemples where this is a problem are :
- quick changing data or data with concurrent accesses
- data list backed up by a set (very frequent with hibernate)

I proposed to use a unique id (the row data's primary key for example)
to solve the problem.

Does you new autoUpdateDataTable from the sandbox somehow helps with
that problem ?

Thanks,

Sylvain.

On Tue, 2005-06-21 at 10:03 -0400, Sylvain Vieujot wrote:

> No worry, I didn't got you wrong.
> 
> I'll try to get you the example asap, but I might require some times,
> as I can't play with that on my production system. So I'll have to go
> through the code.
> 
> I agree that we should make thing as simple as possible.
> 
> I think there are good reasons to provide this attribute anyway.
> Maybe the best way to proceed would be to write this dataTable best
> practice page before coding the new attribute.
> It'll help to make things more clear.
> If you agree, I'll start writing the page in forest (but without any
> link to it). So, we'll all be able to contribute to clear this issue.
> And anyway, even if we end up refusing this new attribute, a good
> explanation on preserveDataModel would be quite useful.
> 
> Sylvain.
> 
> On Tue, 2005-06-21 at 13:50 +0200, Manfred Geiler wrote: 
> 
> > Don't get me wrong. I'm not against the new id proposal(s) a priori.
> > What I would like to make sure first: Is there really no other way
> > then to bother the user (when I say user I mean the JSF user i.e.
> > developer that uses JSF, not the end user!) with such implementation
> > issues? My understanding of JSF is to provide the user a bunch of
> > components that are as simple to use as Swing components. Ideal world
> > looks like this: user designs JSF pages (by visual drag and drop for
> > example), then he writers some straight forward beans to glue GUI and
> > Business Logic together, voila. No twiddling with ids.
> > 
> > Of course we can and should discuss this. I'm no Swing developer at
> > all. Perhaps the problem is equal there and cannot be resolved easily
> > in Swing either? I don't know. Any Swing guru listening?
> > 
> > Your "preserveDataModel fails" example will be a good basis for
> > discussion. Thanks for the efforts.
> > 
> > -Manfred
> > 
> > 
> > 2005/6/21, Sylvain Vieujot <svieujot@apache.org>:
> > >  Hello Manfred,
> > >  
> > >  I'll try to find a good explanation why it doesn't solve the concurrency
> > > problem.
> > >  The only explanation I have right now is that it's the first thing I tried,
> > > and it didn't fix the problem (it was even worse, but I don't know why yet).
> > >  
> > >  Another issue is the need to have a serializable row data.
> > >  We can make a serializable wrapper as you suggested, but it's more work for
> > > a not so efficient solution to the problem.
> > >  
> > >  Do you think we should allow both approaches (with a good best practices
> > > explanation page that's lacking for the preserveDataModel too anyway), or do
> > > you think we should Not implement the rowClientId ?
> > >  
> > >  Thanks,
> > >  
> > >  Sylvain.
> > >  
> > >  P.S. I'll work to give a good example when the preserveDataModel fails.
> > > 
> > >  
> > >  On Tue, 2005-06-21 at 11:29 +0200, Manfred Geiler wrote: 
> > >  Cannot fully agree:
> > > I'm sure preserveDataModel *does* avoid concurrency problems, because
> > > all phases prior to re-rendering see the old unchanged row set. Only
> > > after all pre-render phases (model update, application actions, ..)
> > > have ended, the table data is refreshed from the backing bean i.e.
> > > from the current real data. And that is what solves all these
> > > problems, IMO. Application events and actions are all based on the
> > > very same data, that the user saw when he triggered the action.
> > > Ok, what could have happened in the meantime, of course, is that some
> > > row was concurrently deleted. But to handle this (by throwing some
> > > error message for example) is always the job of the backing bean, of
> > > course.
> > > 
> > > -Manfred
> > > 
> > > 
> > > 2005/6/21, Sylvain Vieujot <svieujot@apache.org>:
> > > > I agree with Manfred that preserveDataModel is quite efficient in it's
> > > > implementation.
> > > > But it doesn't solve the same kind of problem.
> > > > preserveDataModel allows you to keep user modifications between requests.
> > > > 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 stored.
> > > > 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.
> > > > 
> > > > Sylvain.
> > > > 
> > > > 
> > > > 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 <john.r.fallows@gmail.com>:
> > > > > Hi Sylvian,
> > > > > 
> > > > > On 6/20/05, Sylvain Vieujot <svieujot@apache.org> 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.
> > > > >
> > > > 
> > > >
> > > 
> > >

Mime
View raw message