You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Rick Hightower (JIRA)" <my...@incubator.apache.org> on 2005/07/14 01:12:10 UTC
[jira] Commented: (MYFACES-326) facesContext.renderResponse not skipping validation when immediate event submitted twice
[ http://issues.apache.org/jira/browse/MYFACES-326?page=comments#action_12315795 ]
Rick Hightower commented on MYFACES-326:
----------------------------------------
This is not a bug. This was a mistake in one of our base classes.
Please ignore this.
> 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