myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hightower (JIRA)" <myfaces-...@incubator.apache.org>
Subject [jira] Created: (MYFACES-326) facesContext.renderResponse not skipping validation when immediate event submitted twice
Date Tue, 12 Jul 2005 22:23:22 GMT
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


Mime
View raw message