Adam Winer wrote:
On 11/30/05, Mathias Brökelmann <[EMAIL PROTECTED]> 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.
This is not guaranteed. Take the following hierarchy (ignoring table, for now):
disclosure component
input field
By a "disclosure" component, I mean one that can toggle open and shut.
When it's open, the input field is visible, when it's not the input field
is not rendered at all (I'm talking a server-side component here, not
a client-side CSS toggling thing). And let's assume that the server-side
event is "immediate" - it doesn't do validation, etc., but just toggles
visibility.
So, you:
1. Enter a value
2. Click the disclosure component closed (i.e., a submit)
3. Reopen the disclosure component (i.e., another submit)
If you did not save "submittedValue", the value you typed in step #1
is gone. That's because in step #3 the field is hidden - and therefore
your statement that "the values are submitted again through the next
request" is false.
Basically, UIInput *does* need to include the submitted value in
saveState(), and UIData does need to save _rowState.
So would saving the state if-and-only-if rendered=false work around
this? For most cases the component would be rendered, so saved state
would not be needed.
BTW, an independent reason why you have to save _rowState:
if you have component in a table (checkboxes, say) that are
not EL bound, but simply store their value locally, even though
you might successfully get the value resubmitted on a subsequent
request, you'll get lots of incorrect ValueChangeEvents since
the prior value has been forgotten.
So would it be adequate to also save state for components where the
"value" attribute is a literal (not an EL expression)? Again, this would
seem to make it unnecessary to save state in *most* cases.
Cheers,
Simon
