Yes, as Adam pointed out the value state of a component always MUST be saved as long as the model could not be have been updated with a valid value. Please keep in mind: The values of a component are NOT GUARANTEED to be submitted upon the next request. To give you a practical example, imagine two forms on one page: For instance one input form and one online help form in kind of a toolbox component on the right margin. The user entered something wrong and got an error message for one of the entry fields. Now he wants to know why and does a lookup in the online help toolbox - ie. he enters a value in the online help search field and does a submit - if he is lucky he finds what he has looked for. But certainly (if MyFaces did not save the values) he lost all his inputs in the data form - which makes him shout loud for sure! ;-)
Mathias, this worked before the major UIData refactoring. Can you please revise your changes and rethink your motivation to remove the save rowstates logic? Thanks, Manfred 2005/12/1, Adam Winer <[EMAIL PROTECTED]>: > 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. > > 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. > > -- Adam >
