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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]>: > > > Hi Sylvian, > > > > > > On 6/20/05, Sylvain Vieujot <[EMAIL PROTECTED]> 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. > > > > > > > > >
