On Fri, 2006-01-20 at 14:26 +0100, Mathias Stein wrote: > > 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?
DataTable doesn't store the data model because (a) There is no guarantee that the data model is serializable. It's a user-provided object. And in addition, serializing/deserializing is not always the same as keeping the original object in the http session; an example is Hibernate entities, where serialize/deserialize results in the objects becoming "detached". (b) Storing it could make the saved state *much* larger. Ok, sometimes it's necessary but the code shouldn't default to doing this.. (c) It's consistent with the behaviour for other objects. An h:inputText component for example will call its property getter during the validate phase to determine whether the newly submitted value is different from the model value (ie whether a ValueChangeEvent should be queued). The t:dataTable does have attribute "preserveDataModel" which does preserve the data model. However it keeps the data for *too* long (ie doesn't refetch before render). Maybe t:dataTable should have another variant that preserves data from render to postback, but then clears it? > This concurrency issue seems to me like a standard problem of all table > based web applications. Yes it is. > Is this a problem with the specification or with the implementations? > By the way, myfaces and Suns RI show exacly the same behavior. The refetch is behaviour required by the spec. Regards, Simon
