ICEfaces
  1. ICEfaces
  2. ICE-7456

MyFaces 2: singleSubmit not working properly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-Beta2
    • Fix Version/s: 3.0.RC1, 3.0
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      MyFaces 2 ICEfaces 2
    • Assignee Priority:
      P1
    • Workaround Exists:
      Yes
    • Workaround Description:
      Replace singleSubmit with f:ajax tag

      Description

      There's an issue with some examples that use singleSubmit. For example, the Comp Suite Context Menu: Effects demo allows you to choose which effect to use when visually displaying the menu. The markup in question currently looks like this:

      <ui:define name="example">
          <h:form>
          <icecore:singleSubmit/>
          <h:panelGrid columns="3">
                 ...

      This doesn't work properly when running under MyFaces. Clicking a radio button does trigger a submit, but the resulting update simply resets the radio back to the default selection. Changing it to use an f:ajax tag appears to clear things up:

      <ui:define name="example">
          <h:form>
          <f:ajax execute="@this" render="@all">
          <h:panelGrid columns="3">
                 ...

      This isn't related to ACE at all. I can pare down the example to a very simply one using only stock components and the behaviour is the same.

        Activity

        Hide
        Deryk Sinotte added a comment -

        Assigned to Ted.

        Attached test case contains 2 identical pages except that one uses singleSubmit (ss.xhtml) and one uses f:ajax (fajax.xhtml). You can build it by unzipping it to the icefaces2/samples/core directory and using the normal build mechanisms:

        Mojarra:

        ant clean servlet-profile

        MyFaces:

        ant -Dmyfaces="true" clean servlet-profile

        Show
        Deryk Sinotte added a comment - Assigned to Ted. Attached test case contains 2 identical pages except that one uses singleSubmit (ss.xhtml) and one uses f:ajax (fajax.xhtml). You can build it by unzipping it to the icefaces2/samples/core directory and using the normal build mechanisms: Mojarra: ant clean servlet-profile MyFaces: ant -Dmyfaces="true" clean servlet-profile
        Hide
        Deryk Sinotte added a comment -

        Attaching test case.

        Show
        Deryk Sinotte added a comment - Attaching test case.
        Hide
        Ted Goddard added a comment -

        No matter what radio button is clicked on, the response is always:

        <input checked="checked" id="j_id76603324_490dfe1:theColours:0" name="j_id76603324_490dfe1:theColours" type="radio" value="red" />

        Show
        Ted Goddard added a comment - No matter what radio button is clicked on, the response is always: <input checked="checked" id="j_id76603324_490dfe1:theColours:0" name="j_id76603324_490dfe1:theColours" type="radio" value="red" />
        Hide
        Ted Goddard added a comment -

        This value is submitted, which seems unusual:

        javax.faces.partial.event=undefined

        Show
        Ted Goddard added a comment - This value is submitted, which seems unusual: javax.faces.partial.event=undefined
        Hide
        Ted Goddard added a comment -

        With f:ajax we have:

        javax.faces.partial.event=change

        however, fixing this does not seem sufficient

        The following change in submit.js

        +event.type = type(decoratedEvent);

        just before

        namespace.submitFunction(clonedElement, event, options);

        resolves the javax.faces.partial.event difference, but does not affect the returned page update.

        Show
        Ted Goddard added a comment - With f:ajax we have: javax.faces.partial.event=change however, fixing this does not seem sufficient The following change in submit.js +event.type = type(decoratedEvent); just before namespace.submitFunction(clonedElement, event, options); resolves the javax.faces.partial.event difference, but does not affect the returned page update.
        Hide
        Ted Goddard added a comment -

        The contents of the two requests become:

        (for singleSubmit)

        4z8pu82_SUBMIT=1
        javax.faces.ViewState=A%2FRyKRXY8NCEcSf%2BHaIwR2w4Qq%2BcnSwkueW5%2Br18lAEUYoDSkNFdygWEzCk3jB6cw3JxaPu5Yoal%0D%0A824hBPWsbZsxClcW0C9L35giy10JIrk6WDy%2Ba2a2aI8Cqnc%3D%0D%0A
        j_id76603324_490dfe1%3AtheColours=blue
        ice.window=1fgut0j52g
        ice.view=v4z8pu82
        ice.focus=
        ice.event.target=j_id76603324_490dfe1%3AtheColours%3A1
        ice.event.captured=j_id76603324_490dfe1%3AtheColours%3A1
        ice.event.type=onchange
        ice.submit.type=ice.se
        ice.submit.serialization=element
        javax.faces.partial.event=change
        javax.faces.source=j_id76603324_490dfe1%3AtheColours%3A1
        javax.faces.partial.ajax=true
        javax.faces.partial.execute=%40this%20j_id76603324_490dfe1%3AtheColours%3A1
        javax.faces.partial.render=%40all
        v4z8pu82=v4z8pu82

        (and f:ajax)

        ice.window=1fgut0j52g
        ice.view=v4z8pu82
        j_id76603324_490dea6%3AtheColours2=blue
        j_id76603324_490dea6_SUBMIT=1
        javax.faces.ViewState=A%2FRyKRXY8NCEcSf%2BHaIwR2w4Qq%2BcnSwkueW5%2Br18lAEUYoDSkNFdygWEzCk3jB6cw3JxaPu5YoZd%0A9vPsdPr7EZsxClcW0C9LUYC%2F5f%2B3JG00%2FH7cBN7EA%2FgkgMg%3D%0A
        javax.faces.behavior.event=valueChange
        javax.faces.partial.event=change
        javax.faces.source=j_id76603324_490dea6%3AtheColours2
        javax.faces.partial.ajax=true
        javax.faces.partial.execute=%40this%20j_id76603324_490dea6%3AtheColours2
        javax.faces.partial.render=%40all
        j_id76603324_490dea6=j_id76603324_490dea6

        There appears to be some confusion with the event source being the ID of the element vs the name. Perhaps these are identical in mojarra but are not in myfaces.

        Show
        Ted Goddard added a comment - The contents of the two requests become: (for singleSubmit) 4z8pu82_SUBMIT=1 javax.faces.ViewState=A%2FRyKRXY8NCEcSf%2BHaIwR2w4Qq%2BcnSwkueW5%2Br18lAEUYoDSkNFdygWEzCk3jB6cw3JxaPu5Yoal%0D%0A824hBPWsbZsxClcW0C9L35giy10JIrk6WDy%2Ba2a2aI8Cqnc%3D%0D%0A j_id76603324_490dfe1%3AtheColours=blue ice.window=1fgut0j52g ice.view=v4z8pu82 ice.focus= ice.event.target=j_id76603324_490dfe1%3AtheColours%3A1 ice.event.captured=j_id76603324_490dfe1%3AtheColours%3A1 ice.event.type=onchange ice.submit.type=ice.se ice.submit.serialization=element javax.faces.partial.event=change javax.faces.source=j_id76603324_490dfe1%3AtheColours%3A1 javax.faces.partial.ajax=true javax.faces.partial.execute=%40this%20j_id76603324_490dfe1%3AtheColours%3A1 javax.faces.partial.render=%40all v4z8pu82=v4z8pu82 (and f:ajax) ice.window=1fgut0j52g ice.view=v4z8pu82 j_id76603324_490dea6%3AtheColours2=blue j_id76603324_490dea6_SUBMIT=1 javax.faces.ViewState=A%2FRyKRXY8NCEcSf%2BHaIwR2w4Qq%2BcnSwkueW5%2Br18lAEUYoDSkNFdygWEzCk3jB6cw3JxaPu5YoZd%0A9vPsdPr7EZsxClcW0C9LUYC%2F5f%2B3JG00%2FH7cBN7EA%2FgkgMg%3D%0A javax.faces.behavior.event=valueChange javax.faces.partial.event=change javax.faces.source=j_id76603324_490dea6%3AtheColours2 javax.faces.partial.ajax=true javax.faces.partial.execute=%40this%20j_id76603324_490dea6%3AtheColours2 javax.faces.partial.render=%40all j_id76603324_490dea6=j_id76603324_490dea6 There appears to be some confusion with the event source being the ID of the element vs the name. Perhaps these are identical in mojarra but are not in myfaces.
        Hide
        Ted Goddard added a comment -

        Mojarra parameters:

        v6niaio1=v6niaio1
        javax.faces.ViewState=7608153838258384590%3A-5455391648256555334
        j_idt6%3AtheColours=blue
        javax.faces.source=j_idt6%3AtheColours%3A1
        javax.faces.partial.event=change
        javax.faces.partial.execute=j_idt6%3AtheColours%20j_idt6%3AtheColours%3A1
        javax.faces.partial.render=%40all
        ice.window=m3gutyqizu
        ice.view=v6niaio1
        ice.focus=
        ice.event.target=j_idt6%3AtheColours%3A1
        ice.event.captured=j_idt6%3AtheColours%3A1
        ice.event.type=onchange
        ice.submit.type=ice.se
        ice.submit.serialization=element
        javax.faces.partial.ajax=true

        j_idt14=j_idt14
        ice.window=m3gutyqizu
        ice.view=v6niaio1
        j_idt14%3AtheColours2=blue
        javax.faces.ViewState=7608153838258384590%3A-5455391648256555334
        javax.faces.source=j_idt14%3AtheColours2%3A1
        javax.faces.partial.event=click
        javax.faces.partial.execute=j_idt14%3AtheColours2%20j_idt14%3AtheColours2%3A1
        javax.faces.partial.render=%40all
        javax.faces.behavior.event=valueChange
        javax.faces.partial.ajax=true

        Show
        Ted Goddard added a comment - Mojarra parameters: v6niaio1=v6niaio1 javax.faces.ViewState=7608153838258384590%3A-5455391648256555334 j_idt6%3AtheColours=blue javax.faces.source=j_idt6%3AtheColours%3A1 javax.faces.partial.event=change javax.faces.partial.execute=j_idt6%3AtheColours%20j_idt6%3AtheColours%3A1 javax.faces.partial.render=%40all ice.window=m3gutyqizu ice.view=v6niaio1 ice.focus= ice.event.target=j_idt6%3AtheColours%3A1 ice.event.captured=j_idt6%3AtheColours%3A1 ice.event.type=onchange ice.submit.type=ice.se ice.submit.serialization=element javax.faces.partial.ajax=true j_idt14=j_idt14 ice.window=m3gutyqizu ice.view=v6niaio1 j_idt14%3AtheColours2=blue javax.faces.ViewState=7608153838258384590%3A-5455391648256555334 javax.faces.source=j_idt14%3AtheColours2%3A1 javax.faces.partial.event=click javax.faces.partial.execute=j_idt14%3AtheColours2%20j_idt14%3AtheColours2%3A1 javax.faces.partial.render=%40all javax.faces.behavior.event=valueChange javax.faces.partial.ajax=true
        Hide
        Ted Goddard added a comment -

        In the case of mojarra, the javax.faces.source and javax.faces.partial.execute have the same structure.

        Mojarra markup:

        <input id="j_idt6:theColours:0" name="j_idt6:theColours" type="radio" value="red">

        <input id="j_idt14:theColours2:0" name="j_idt14:theColours2" onclick="mojarra.ab(this,event,'valueChange','@this','@all')" type="radio" value="red">

        MyFaces markup:

        <input checked="checked" id="j_id76603324_490dfe1:theColours:0" name="j_id76603324_490dfe1:theColours" type="radio" value="red">

        <input checked="checked" id="j_id76603324_490dea6:theColours2:0" name="j_id76603324_490dea6:theColours2" onchange="jsf.ajax.request('j_id76603324_490dea6:theColours2',event,

        {execute:'@this',render:'@all','javax.faces.behavior.event':'valueChange'}

        )" type="radio" value="red">

        Show
        Ted Goddard added a comment - In the case of mojarra, the javax.faces.source and javax.faces.partial.execute have the same structure. Mojarra markup: <input id="j_idt6:theColours:0" name="j_idt6:theColours" type="radio" value="red"> <input id="j_idt14:theColours2:0" name="j_idt14:theColours2" onclick="mojarra.ab(this,event,'valueChange','@this','@all')" type="radio" value="red"> MyFaces markup: <input checked="checked" id="j_id76603324_490dfe1:theColours:0" name="j_id76603324_490dfe1:theColours" type="radio" value="red"> <input checked="checked" id="j_id76603324_490dea6:theColours2:0" name="j_id76603324_490dea6:theColours2" onchange="jsf.ajax.request('j_id76603324_490dea6:theColours2',event, {execute:'@this',render:'@all','javax.faces.behavior.event':'valueChange'} )" type="radio" value="red">
        Hide
        Ted Goddard added a comment -

        This seems to be a fix in META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js:

        /**

        • binding contract the javax.faces.source must be set
          */
          //passThrgh[this.P_PARTIAL_SOURCE] = elementId;
          passThrgh[this.P_PARTIAL_SOURCE] = elem.name;
        Show
        Ted Goddard added a comment - This seems to be a fix in META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js: /** binding contract the javax.faces.source must be set */ //passThrgh [this.P_PARTIAL_SOURCE] = elementId; passThrgh [this.P_PARTIAL_SOURCE] = elem.name;
        Hide
        Ted Goddard added a comment -

        Please take a look at the above myfaces change – we need to decide if they should modify this or if this is still really a problem in our code.

        Show
        Ted Goddard added a comment - Please take a look at the above myfaces change – we need to decide if they should modify this or if this is still really a problem in our code.
        Hide
        Ted Goddard added a comment -

        The spec simply says "identifier" rather than ID or name:

        http://download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/js-api/symbols/jsf.ajax.html#.request

        so the test is likely whether the above change fixes the problem. Alternatively, the MyFaces RadioButtonRenderer could be modified to accept a decode from a javax.faces.source that matches any ID it has written.

        Show
        Ted Goddard added a comment - The spec simply says "identifier" rather than ID or name: http://download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/js-api/symbols/jsf.ajax.html#.request so the test is likely whether the above change fixes the problem. Alternatively, the MyFaces RadioButtonRenderer could be modified to accept a decode from a javax.faces.source that matches any ID it has written.
        Hide
        Deryk Sinotte added a comment -

        So it appears that, when using singleSubmit with MyFaces, the "javax.faces.execute" parameter does not include the name of the component. For example, if you run the test case and run the ss.xhtml page:

        javax.faces.partial.execute:@this j_id76603324_490dfe1:theColours:0

        Running the fajax.xhtml page:

        javax.faces.partial.execute:j_id779036716_2e6f2877:theColours

        MyFaces looks like it processes things differently with the f:ajax tag whereas with singleSubmit, from the client perspective, it doesn't look like an Ajax request.

        Including the element.name is important for things like radio buttons and checkboxes because the id of the radio button/checkbox is indexed:

        j_id76603324_490dfe1:theColours:0

        but the actual component doesn't include this

        j_id76603324_490dfe1:theColours

        Without the element.name in this case, MyFaces fails to run the partial execution against the component and it doesn't get decode() 'd.

        Mojarra appears to append the element.name to the outgoing request regardless.

                       if (options.execute) {
                           none = options.execute.search(/@none/);
                           if (none < 0) {
                               all = options.execute.search(/@all/);
                               if (all < 0) {
                                   options.execute = options.execute.replace("@this", element.id);
                                   options.execute = options.execute.replace("@form", form.id);
                                   var temp = options.execute.split(' ');
                                   if (!isInArray(temp, element.name))

        {                                options.execute = element.name + " " + options.execute;                            }

                               } else

        {                            options.execute = "@all";                        }

                               args["javax.faces.partial.execute"] = options.execute;
                           }
                       } else

        {                    options.execute = element.name + " " + element.id;                    args["javax.faces.partial.execute"] = options.execute;                }

        So I've checked in a change to submit.js that appends the element.name to the execute parameter for radio buttons and checkboxes (if it's not already there) which fixes the issue we are seeing. The fix is currently only applied to singleSubmit for radio buttons and checkboxes as that's the only place we are currently seeing this behaviour.

        Show
        Deryk Sinotte added a comment - So it appears that, when using singleSubmit with MyFaces, the "javax.faces.execute" parameter does not include the name of the component. For example, if you run the test case and run the ss.xhtml page: javax.faces.partial.execute:@this j_id76603324_490dfe1:theColours:0 Running the fajax.xhtml page: javax.faces.partial.execute:j_id779036716_2e6f2877:theColours MyFaces looks like it processes things differently with the f:ajax tag whereas with singleSubmit, from the client perspective, it doesn't look like an Ajax request. Including the element.name is important for things like radio buttons and checkboxes because the id of the radio button/checkbox is indexed: j_id76603324_490dfe1:theColours:0 but the actual component doesn't include this j_id76603324_490dfe1:theColours Without the element.name in this case, MyFaces fails to run the partial execution against the component and it doesn't get decode() 'd. Mojarra appears to append the element.name to the outgoing request regardless.                if (options.execute) {                    none = options.execute.search(/@none/);                    if (none < 0) {                        all = options.execute.search(/@all/);                        if (all < 0) {                            options.execute = options.execute.replace("@this", element.id);                            options.execute = options.execute.replace("@form", form.id);                            var temp = options.execute.split(' ');                            if (!isInArray(temp, element.name)) {                                options.execute = element.name + " " + options.execute;                            }                        } else {                            options.execute = "@all";                        }                        args ["javax.faces.partial.execute"] = options.execute;                    }                } else {                    options.execute = element.name + " " + element.id;                    args["javax.faces.partial.execute"] = options.execute;                } So I've checked in a change to submit.js that appends the element.name to the execute parameter for radio buttons and checkboxes (if it's not already there) which fixes the issue we are seeing. The fix is currently only applied to singleSubmit for radio buttons and checkboxes as that's the only place we are currently seeing this behaviour.

          People

          • Assignee:
            Ted Goddard
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: