@Manfred I see the problem but I don`t think that this can be solved by jsf and myfaces. I try to explain why:
Let us take your example. What happens if the user enters some values into the input form but don´t submit it and additionally enters something into the online help form and submits the online help form. The values of the input form are lost anyway (regardless if we try to save them) if the user has not submitted these values before submitting the online help form. We wouldn't solve this if we save the submitted value in the view state. IMO the users who have such a page should simply but both the input form an the online help form into a single form. That's more a problem if they use includes for the online help section and have a form in this include. But why not having a single form for the entire page? 2005/12/1, Manfred Geiler <[EMAIL PROTECTED]>: > 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 > > > -- Mathias
