[ http://issues.apache.org/jira/browse/MYFACES-326?page=all ]
     
Grant Smith closed MYFACES-326:
-------------------------------

    Resolution: Invalid

> facesContext.renderResponse not skipping validation when immediate event 
> submitted twice
> ----------------------------------------------------------------------------------------
>
>          Key: MYFACES-326
>          URL: http://issues.apache.org/jira/browse/MYFACES-326
>      Project: MyFaces
>         Type: Bug
>     Versions: 1.0.9 beta
>  Environment: JBoss 4 and Tomcat 5.
>     <context-param>
>         <description>
>             State saving method: "client" or "server" (= default)
>             See JSF Specification 2.5.2
>         </description>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>server</param-value>
>     </context-param>
>     
>     <context-param>
>         <description>
>             Comma separated list of URIs of (additional) faces config files.
>             (e.g. /WEB-INF/my-config.xml)
>             See JSF 1.0 PRD2, 10.3.2
>         </description>
>         <param-name>javax.faces.CONFIG_FILES</param-name>
>         <param-value>
>                   /WEB-INF/faces-config.xml        
>         </param-value>
>     </context-param>
>     <context-param>
>         <description>
>             This parameter tells MyFaces if javascript code should be allowed 
> in the
>             rendered HTML output.
>             If javascript is allowed, command_link anchors will have 
> javascript code
>             that submits the corresponding form.
>             If javascript is not allowed, the state saving info and nested 
> parameters
>             will be added as url parameters.
>             Default: "true"
>         </description>
>         <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     
>     <context-param>
>         <description>
>             This parameter tells MyFaces if javascript code should be allowed 
> in the
>             rendered HTML output.
>             If javascript is allowed, command_link anchors will have 
> javascript code
>             that submits the corresponding form.
>             If javascript is not allowed, the state saving info and nested 
> parameters
>             will be added as url parameters.
>             Default: "false"
>             Setting this param to true should be combined with 
> STATE_SAVING_METHOD "server" for
>             best results.
>             This is an EXPERIMENTAL feature. You also have to enable the 
> detector filter/filter mapping below to get
>             JavaScript detection working.
>         </description>
>         <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
>         <param-value>false</param-value>
>     </context-param>
>     <context-param>
>         <description>
>             If true, rendered HTML code will be formatted, so that it is 
> "human readable".
>             i.e. additional line separators and whitespace will be written, 
> that do not
>             influence the HTML code.
>             Default: "true"
>         </description>
>         <param-name>org.apache.myfaces.PRETTY_HTML</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <context-param>
>         <description>
>             If true, a javascript function will be rendered that is able to 
> restore the
>             former vertical scroll on every request. Convenient feature if 
> you have pages
>             with long lists and you do not want the browser page to always 
> jump to the top
>             if you trigger a link or button action that stays on the same 
> page.
>             Default: "false"
>         </description>
>         <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     Reporter: Rick Hightower

>
> Bug Report:
> facesContext.renderResponse not skipping validation when immediate event 
> submitted twice.
> Description:
> The first time you render a page, and you hit the button that is configured 
> as such:
>             <h:selectOneRadio id="showSecondMortgage"
>                               value="#{lreController.form.showSecondMortgage}"
>                               immediate="true"
>                               onclick="submit()"
>                               
> valueChangeListener="#{lreController.showSecondMortgageChanged}">
>                 <f:selectItem itemLabel="Yes" itemValue="true"/>
>                 <f:selectItem itemLabel="No" itemValue="false"/>
>             </h:selectOneRadio>
> Notice that event handling is set to immediate.
> Also notice that onclick="submit()".
> First time through:
> The event handler gets called as expected:
> LREController.java:
>     public void showSecondMortgageChanged(ValueChangeEvent event) {
>         Boolean showSecondMortgage = (Boolean) event.getNewValue();
>         form.setShowSecondMortgage(showSecondMortgage);
>         FacesContext facesContext = getFacesContext(); //this method just get 
> Faces context the normal way.
>         facesContext.renderResponse();
>     }
> The event handler calls renderResponse.
> The phase progression is as follows:
> 1) Restore View
> 2) Apply Request Values (event handler called)
> 3) Render Response.
> The above is correct.
> It is the second time through that the problems occur.
> The second time the radio button get selected the event handler gets called, 
> but the phase does not go 
> directly to Render Response it goes as follows:
> Restore View
> Apply Request Values (event handler called)
> Process Validation
> Render Response
> It still skips Model Update phase and such, but it does not skip Process 
> Validation like it is suppose to.
> This causes the form to be validated when it is not suppose to be validated.
> I tried this with client side state saving and server side state saving with 
> the same behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to