IMO, the user is submitting the subform, not the entire page, therefore only the subform values should be sent & everything else lost right? Perhaps a toggle option would be desired. I can see the value of both approaches.
Using two different tr:forms would theoretically work, but that is not always easy to visually use. I would think that this would be discussed before any thought of a fix could be made. It just seems that there is no support for Walter's use case. I would think that it would be possible to come up with both use cases of (1) preserving current input components values that the client entered and (2) losing the values to reflect changes to the model. Right now, JSF treats use case #2 very poorly and the standard work-around is to clear the submitted value and local values from EditableValueHolders when it is desired to reset their rendered state to their model values. Maybe the subform is not the best place to fix this, I am not sure. -Andrew On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão <[EMAIL PROTECTED]> wrote: > Hi Volker, > > I think the question is not if it was submitted or not but if all the > visible references (inputText, outputText or everything else) of a property > instance show its current value when the view is rendered. > > Regards, > > Walter Mourão > http://waltermourao.com.br > http://arcadian.com.br > http://oriens.com.br > > > > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> why would you expect a not submited subform should loose changes made >> on the client (the submitted value)? >> >> This is exact the behavior i would expect. And BTW how the tobago subform >> works. >> >> >> Regards, >> Volker >> >> 2008/9/10 Andrew Robinson <[EMAIL PROTECTED]>: >> > Okay, I know the problem: >> > >> > The Subform allows the decode phase of all the children, regardless of >> > what was clicked on. If an event was queued inside of the subform, but >> > not during the apply phase, the form is considered "submitted". Only >> > the submitted form will be validated & updated. >> > >> > Now, UIXInput (and UIInput) render the submitted value as the current >> > value if it is set. Therefore: >> > >> > 1) subform 1 is submitted >> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for the >> > inputText in the 2nd subform) >> > 3) subform 1 is validated >> > 4) subform 1 is updated >> > 5) render subform 1, inputText renders the "value" attribute >> > 6) render subform 2, inputText renders the "submittedValue" attribute >> > (blank string - "") >> > >> > So to me this looks like a design flaw of the subform component. IMO, >> > I would file a bug. Fixing it based on looking at the current design >> > could be a pain in the rear. I wonder how the Tomahawk subform handles >> > the same situation? >> > >> > As a workaround, you would have to find all components under >> > non-submitted subforms that implement EditableValueHolder and set >> > their submitted value to null. >> > >> > -Andrew >> > >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <[EMAIL PROTECTED]> >> > wrote: >> >> Actually it looks like the issue isn't related with PPR. I just tested >> >> without PPR (see code below) and had the same result: >> >> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"; version="2.0" >> >> xmlns:f="http://java.sun.com/jsf/core"; >> >> xmlns:tr="http://myfaces.apache.org/trinidad"; > >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/> >> >> <f:view> >> >> <tr:document title="Apache Trinidad Blank Demo"> >> >> <tr:form> >> >> <tr:subform id="sub1"> >> >> <tr:panelPage> >> >> <tr:outputText value="#{helloWorldBacking.name}" /> >> >> <tr:inputText label="Your name" id="input1" >> >> value="#{helloWorldBacking.name}" required="true"/> >> >> <tr:commandButton id="button1" text="press me" >> >> action="#{helloWorldBacking.send}"/> >> >> </tr:panelPage> >> >> </tr:subform> >> >> <tr:subform id="sub2"> >> >> <tr:panelPage> >> >> <tr:outputText value="#{helloWorldBacking.name}" /> >> >> <tr:inputText label="Your name" id="input1" >> >> value="#{helloWorldBacking.name}" required="true"/> >> >> <tr:commandButton id="button1" text="press me" >> >> action="#{helloWorldBacking.send}"/> >> >> </tr:panelPage> >> >> </tr:subform> >> >> </tr:form> >> >> </tr:document> >> >> </f:view> >> >> </jsp:root> >> >> >> >> >> >> Walter Mourão >> >> http://waltermourao.com.br >> >> http://arcadian.com.br >> >> http://oriens.com.br >> >> >> >> >> >> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson >> >> <[EMAIL PROTECTED]> wrote: >> >>> >> >>> Looks like you need to add partialTriggers to the components you want >> >>> to update / refresh >> >>> >> >>> -A >> >>> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão >> >>> <[EMAIL PROTECTED]> >> >>> wrote: >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a >> >>> > workaround >> >>> > ? >> >>> > >> >>> > >> >>> > Walter Mourão >> >>> > http://waltermourao.com.br >> >>> > http://arcadian.com.br >> >>> > http://oriens.com.br >> >>> > >> >>> > >> >>> > >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão >> >>> > <[EMAIL PROTECTED]> >> >>> > wrote: >> >>> >> >> >>> >> Hi folks, >> >>> >> I'm dealing with a strange behavior when using subforms and I >> >>> >> reproduced >> >>> >> it using the trinidad-blank example (from 1.0.9, but I found the >> >>> >> problem >> >>> >> first with 1.0.5). >> >>> >> When executing an action from subform 1, only the inputs of the >> >>> >> subform >> >>> >> 1 >> >>> >> are refreshed and show the new value. Besides that, when I added a >> >>> >> tr:outputText to the subform, pointing to the same backing bean >> >>> >> property, it >> >>> >> shows the new value, so the tr:inputText and tr:outputText (of the >> >>> >> subform >> >>> >> 2) shows differente values... >> >>> >> >> >>> >> To reproduce using the trinidad-blank example: >> >>> >> 1 - change HelloWorldBacking.send to: >> >>> >> public String send() >> >>> >> { >> >>> >> _name = _name.toUpperCase(); >> >>> >> >> >>> >> return null; >> >>> >> } >> >>> >> >> >>> >> 2 - add the file two_subforms.jspx with the content: >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"; version="2.0" >> >>> >> xmlns:f="http://java.sun.com/jsf/core"; >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad"; > >> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/> >> >>> >> <f:view> >> >>> >> <tr:document title="Apache Trinidad Blank Demo"> >> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1"> >> >>> >> <tr:subform id="sub1"> >> >>> >> <tr:panelPage> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" /> >> >>> >> <tr:inputText label="Your name" id="input1" >> >>> >> value="#{helloWorldBacking.name}" required="true"/> >> >>> >> <tr:commandButton id="button1" text="press me" >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/> >> >>> >> </tr:panelPage> >> >>> >> </tr:subform> >> >>> >> <tr:subform id="sub2"> >> >>> >> <tr:panelPage> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" /> >> >>> >> <tr:inputText label="Your name" id="input1" >> >>> >> value="#{helloWorldBacking.name}" required="true"/> >> >>> >> <tr:commandButton id="button1" text="press me" >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/> >> >>> >> </tr:panelPage> >> >>> >> </tr:subform> >> >>> >> </tr:form> >> >>> >> </tr:document> >> >>> >> </f:view> >> >>> >> </jsp:root> >> >>> >> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a >> >>> >> text >> >>> >> in >> >>> >> one of the inputs and click "press me". >> >>> >> >> >>> >> This behavior happens with partialSubmit="false" too. >> >>> >> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and if it >> >>> >> has >> >>> >> an >> >>> >> workaround. >> >>> >> >> >>> >> Thanks in advance, >> >>> >> >> >>> >> >> >>> >> Walter Mourão >> >>> >> http://waltermourao.com.br >> >>> >> http://arcadian.com.br >> >>> >> http://oriens.com.br >> >>> >> >> >>> > >> >>> > >> >> >> >> >> > >> >> >> >> -- >> inexso - information exchange solutions GmbH >> Bismarckstraße 13 | 26122 Oldenburg >> Tel.: +49 441 4082 356 | >> FAX: +49 441 4082 355 | www.inexso.de > >
