> > DataTable doesn't store the data model because ... > > The t:dataTable does have attribute "preserveDataModel" which does > > preserve the data model.
How does t:dataTable actually preserve the data model, when it doesn't store it? Regards, Matthias > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Martin Marinschek > Gesendet: Sonntag, 22. Januar 2006 11:33 > An: MyFaces Discussion; [EMAIL PROTECTED] > Betreff: Re: concurrency and t:dataTable (preserveDataModel, forceId, > param) > > > Hold on - t:dataTable refetches the data before rendering, right? > > regards, > > Martin > > On 1/22/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces
