> The data list used during validation phase *must* be the same as the one > used during the previous rendering phase, otherwise as you note the > wrong object can be accessed.
As fas as I know the view is serialized, stored in the session and deserialized on request submition. Why doesn't dataTable simply store the data model or at least the row bindings automatically? This concurrency issue seems to me like a standard problem of all table based web applications.
Is this a problem with the specification or with the implementations? By the way, myfaces and Suns RI show exacly the same behavior. >But the list *must* be refetched before the render phase if you don't >want to render stale data. Okay it must be refetched before the render phase. But why is it refetched before calling the action? >There was a thread on creating a "PhaseTracker" just yesterday or the >day before; see the user list email archives. > >This doesn't seem very elegant, but it's the best I've found. Any better >suggestions are very welcome. Thanks a lot for your solution. I'll try as soon as possible. >> Approach 3: (t:commandButton and forceId > This won't work anyway because if it wasn't a static value then the > button for row N of the table would just be taking the id from the Nth > element in the data list at postback - and therefore using the wrong > record key if the datalist at postback != datalist at render. Is there any other way to use user defined row ids like item primary keys? By the way, user defined row ids could help to solve problems with the browsers back button, too. tanks so far Mathias
