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. > > > >
