IMO Simon You are right in every point (like everytime ;) 2005/12/1, Simon Kitching <[EMAIL PROTECTED]>: > Thanks for the info Mathias. > > I'm not personally suggesting that there *is* a need to serialize the > _rowState. I was just puzzled why it wasn't. > > Thanks for pointing out that a component's _submittedValue will be > restored on postback via processDecodes; I'd not thought about that. > However the UIInput.saveState method clearly *does* serialize this data > for standard input components. It looks like *one* of these two is doing > something wrong... > > What will happen if server-size state-saving is used, together with the > newly introduced feature to save multiple views? The view gets rendered > to the user who then pushes the "back" button, alters some fields, then > presses "submit". Even then, the "back" button will restore the values > displayed by input fields, so it looks to me like _submittedValue is > still restored correctly. So what's the point of ever saving it in > UIInput.saveState? > > Members _localValueSet and _valid seem to me to fall in the same > category - stuff that gets reset anyway during processDecodes, so > there's no point in storing it. Well, storing it *does* make that info > available during the "restore view" and processDecodes bits, but I can't > imagine what use anyone would make of that data during those steps. > > By the way, the _rowState data only contains saved state for the above > fields, though the components themselves have many more members. The > implications of not saving the other fields is interesting. A UIInput > saves _immediate, _required, _validatorList, _valueChangeListener. > However the "real" child components of the UIData will cause these > values to be serialized once, yes? Then during the iteration over the > rows the real child components take on the "row state" for each row but > keep the same values from their original instances for these fields. > That implies that changing any of these fields programmatically while > rowIndex=N will cause a change to that property for all rows in the > table, yes? That's ok by me but would be good to document. If you can > confirm that this paragraph is correct, I'll write the necessary javadoc. > > Cheers, > > Simon > > Mathias Brökelmann wrote: > > the rowstate is not serialized with the view. If validation fails the > > submitted value of any input component is rendered in the response. > > IMO it is not necessary to save the sate of each row if validation > > fails since the values are submitted again through the next request. > > > > In any case saving this rowstate value would not save the complete > > state for every component in the row since saveState/restoreState is > > not called for the components. Only EditableValueHolder components and > > their current values of the attributes value, submittedvalue, valid > > and localvalueset are saved in this state. Any other stateful > > component in a datatable can not be used anyway (its state would not > > be saved for each row between requests). > > > > To make saving the state for each row work for every component we > > would need to implement UIData.saveState/restoreState to iterate > > through the rows and call processSaveState/processRestoreState for > > each uicolumn and serialize this with the view. This would make every > > component work inside a datatable. But I think we need to keep in mind > > that this may produce a really big state which must be rendered in the > > response if client side state is used and the datatable contains a lot > > of rows. > > > > I suggest to implement it in t:datatable with an aditional switch > > parameter. So users who need it can enable this rowstate saving > > between requests. > > > > 2005/11/29, Manfred Geiler <[EMAIL PROTECTED]>: > >> That's a perfect question and an important issue. > >> Indeed there was such a "save descendant states" logic in my original > >> UIData code. As I remember this was one of the more complex parts. > >> States where only to be saved when all children where valid, and so > >> on. Well, this logic has vanished during the refactoring by Mathias > >> Broekelmann. > >> > >> Mathias, can you please disclose your rationale to drop this?! > >> > >> Thanks, > >> Manfred > >> > >> > >> 2005/11/29, Simon Kitching <[EMAIL PROTECTED]>: > >>> Hi, > >>> > >>> The UIData uses the "flyweight" pattern so that a single set of > >>> component children for a single row are enough to implement a table with > >>> any number of rows. The state for each row is stored in _rowState. > >>> > >>> When a view is serialized, the state for ordinary components is stored. > >>> I presume that the _rowState is also stored at the same time, and for > >>> the same reasons. Among other things I believe this info would be > >>> necessary to re-rended submitted values for input fields if validation > >>> should fail. > >>> > >>> But I just can't see anything in the UIData component that saves the > >>> _rowState. > >>> > >>> Can anyone give me a hint? > >>> > >>> Thanks, > >>> > >>> Simon > >>> > > > > > > -- > > Mathias > > > >
-- Mathias
