return a outcome != null in your action. This will create a new view, so there are no submitted values in the components.
Regards, Volker 2008/9/19 Walter Mourão <[EMAIL PROTECTED]>: > Hi Andrew, > Is there a way to force all components (editable or not) to be "refreshed" > from the bean values ? > > Thanks in advance, > > Walter Mourão > http://waltermourao.com.br > http://arcadian.com.br > http://oriens.com.br > > > > On Wed, Sep 10, 2008 at 4:04 PM, Andrew Robinson > <[EMAIL PROTECTED]> wrote: >> >> I wonder if a better idea is to address this from JSF or from the >> Input behavior. This is not restricted to the subform. The problem is >> that a component with a submitted value will not display a model value >> if the model value changes. >> >> This could be addressed by something like: >> >> <tr:inputText value="#{bean.value}"> >> <trs:modelChangeBehavior /> >> </tr:inputText> >> >> The modelChangeBehavior would be a component that would clear the >> submitted value & local value when the value of the >> EditableValueHolder parent (requirement) changes between the end of >> the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION >> phase. >> >> Note that this can be done in JSF 1.2 without a custom component by >> using the <f:phaseListener /> tag. This may be the best solution. >> >> How to implement: >> 1) Add <f:phaseListener /> >> 2) Have that bound to a managed bean (request scope) >> 3) Have that managed bean implement PhaseListener >> 4) Use ANY_PHASE for the PhaseId >> 5) on APPLY_REQUEST_VALUES get the component (use component binding is >> the best solution I guess) >> 6) get the value attribute & store it somewhere (in the bean probably >> best) >> 7) in INVOKE_APPLICATION, check the value and see if it changed. If >> so, then clear the component >> >> -Andrew >> >> >> On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <[EMAIL PROTECTED]> >> wrote: >> > I will try the Andrew's workaround and/or try another way to accomplish >> > what >> > I want. >> > >> > I will defend my point of view because: >> > 1 - PPR already allows perfectly one to avoid refresh some of the view, >> > so >> > it is possible to have control when it is not desired to refresh a >> > subform; >> > 2 - tr:outputText and tr:inputText should have a similar behavior when >> > showing the property value. >> > >> > Thank you very much, guys. >> > >> > Walter Mourão >> > http://waltermourao.com.br >> > http://arcadian.com.br >> > http://oriens.com.br >> > >> > >> > >> > On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson >> > <[EMAIL PROTECTED]> wrote: >> >> >> >> 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 >> >> > >> >> > >> > >> > > > -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
