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
