ICEfaces
  1. ICEfaces
  2. ICE-10080

ace:ajax - Support nesting multiple components in a single ace:ajax tag

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 4
    • Assignee Priority:
      P1
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial

      Description

      With the singleSubmit tag going away in IF4 it would be handy if the ace:ajax tag could support both of the following use-cases:

      1. Support form-level ace:ajax the way that the f:ajax tag does, meaning that when placed outside the form it applies to all input components in the form, using their default event (either "action", or "valueChange").

      2. Support nesting one or more input components inside a single ace:ajax tag, inside a form. Again, this scenario assumes only the default client event will be supported for each component-type.


      1. after.PNG
        16 kB
      2. before.PNG
        11 kB
      3. multi.PNG
        14 kB

        Activity

        Ken Fyten created issue -
        Hide
        Ken Fyten added a comment -

        Example for scenario #1 above:

        <h:body>
            <f:view>
                <ace:ajax render="output">
                <h:form>
                    <h3>This Ajax is Default Triggered</h3>
                    <h:inputText id="input" value="#{indexBean.message}"
                        valueChangeListener="#{indexBean.valueChange}"/>
                    #{' '}
                    <h:commandButton value="Display" action="#{indexBean.displayText}">
                    </h:commandButton>
                    #{' '}
                    <h:commandLink value="Display" action="#{indexBean.displayText}">
                    </h:commandLink>
                    #{' '}
                    <h:outputText id="output" value="#{indexBean.message}"></h:outputText>
                </h:form>
                </f:ajax>
            </f:view>
        </h:body>
        
        Show
        Ken Fyten added a comment - Example for scenario #1 above: <h:body> <f:view> <ace:ajax render= "output" > <h:form> <h3>This Ajax is Default Triggered</h3> <h:inputText id= "input" value= "#{indexBean.message}" valueChangeListener= "#{indexBean.valueChange}" /> #{' '} <h:commandButton value= "Display" action= "#{indexBean.displayText}" > </h:commandButton> #{' '} <h:commandLink value= "Display" action= "#{indexBean.displayText}" > </h:commandLink> #{' '} <h:outputText id= "output" value= "#{indexBean.message}" ></h:outputText> </h:form> </f:ajax> </f:view> </h:body>
        Hide
        Ken Fyten added a comment -

        Example for scenario #2 above:

        <h:body>
            <f:view>
                <h:form>
                    <h:inputText id="input" value="#{indexBean.message}"
                        valueChangeListener="#{indexBean.valueChange}"/>
                    #{' '}
                    <h:commandButton value="Display" action="#{indexBean.displayText}">
                    </h:commandButton>
                   <ace:ajax render="output">
                       #{' '}
                       <h:commandLink value="Display" action="#{indexBean.displayText}">
                       </h:commandLink>
                       #{' '}
                       <h:outputText id="output" value="#{indexBean.message}"></h:outputText>
                    </ace:ajax>
                </h:form>
                </f:ajax>
            </f:view>
        </h:body>
        
        Show
        Ken Fyten added a comment - Example for scenario #2 above: <h:body> <f:view> <h:form> <h:inputText id= "input" value= "#{indexBean.message}" valueChangeListener= "#{indexBean.valueChange}" /> #{' '} <h:commandButton value= "Display" action= "#{indexBean.displayText}" > </h:commandButton> <ace:ajax render= "output" > #{' '} <h:commandLink value= "Display" action= "#{indexBean.displayText}" > </h:commandLink> #{' '} <h:outputText id= "output" value= "#{indexBean.message}" ></h:outputText> </ace:ajax> </h:form> </f:ajax> </f:view> </h:body>
        Ken Fyten made changes -
        Field Original Value New Value
        Assignee Arturo Zambrano [ artzambrano ]
        Fix Version/s 4.0 [ 11382 ]
        Affects Documentation (User Guide, Ref. Guide, etc.),Sample App./Tutorial [ 10003, 10001 ]
        Assignee Priority P1 [ 10010 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #41494 Wed Jun 18 16:47:44 MDT 2014 art.zambrano ICE-10080 added support for nesting multiple components in a single ace:ajax tag
        Files Changed
        Commit graph MODIFY /icefaces4/trunk/icefaces/ace/generator/src/org/icefaces/ace/generator/artifacts/ComponentHandlerArtifact.java
        Commit graph MODIFY /icefaces4/trunk/icefaces/ace/generator/src/org/icefaces/ace/generator/context/ComponentContext.java
        Commit graph ADD /icefaces4/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviors.java
        Commit graph MODIFY /icefaces4/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorHandler.java
        Commit graph MODIFY /icefaces4/trunk/icefaces/ace/generator/src/org/icefaces/ace/generator/context/MetaContext.java
        Hide
        Arturo Zambrano added a comment - - edited

        Committed improvement to the 4.0 trunk at revision 41494.

        Since our ace:ajax tag is modelled after the f:ajax tag of Mojarra, to add this improvement an approach similar to that of Mojarra was implemented. The main idea is to create an application-scoped stack that stores client behavior settings. Then, as the facelet tags are being processed, when an ace:ajax tag is reached, after we determine that the ace:ajax tag is wrapping other components (in our AjaxBehaviorHandler class), we add the facelet context, tag settings and event name to this stack. Then all the tags of components that implement IceClientBehaviorHolder will look for this stack and add the behaviours to the newly-created component. After all children of the ace:ajax tag have been processed, the behaviour settings are removed (popped) from the stack.

        Thus, the ace:ajax tag follows the same rules or precedence described in the section 10.4.1.1 of the JSF 2.0 specification.

        Unfortunately, at the moment it doesn't seem feasible to also support/affect standard (h: ) components nested inside our ace:ajax tag, since Mojarra and Myfaces use different approaches to support f:ajax in wrapping mode. Each of them uses their own classes that aren't part of the standard API. Many of these methods are private and we can't access them. Also, the different component implementations expect different things to be available when looking for ajax behaviours defined by a wrapping tag. There might also be some conflicts using ids to store application-wide objects. Each implementation has its own approach since the JSF specification doesn't mention any details regarding how this mechanism should be implemented. Also, when traversing the tag tree, it's not possible to directly access tag children and the components they create at the times where it would be optimal do be able to do so.

        However, both ace:ajax and f:ajax tags can coexist and each will only affect the components they support. It's possible to wrap a set of ace: and h: components inside an ace:ajax and f:ajax tag. The order is not relevant.

        Show
        Arturo Zambrano added a comment - - edited Committed improvement to the 4.0 trunk at revision 41494. Since our ace:ajax tag is modelled after the f:ajax tag of Mojarra, to add this improvement an approach similar to that of Mojarra was implemented. The main idea is to create an application-scoped stack that stores client behavior settings. Then, as the facelet tags are being processed, when an ace:ajax tag is reached, after we determine that the ace:ajax tag is wrapping other components (in our AjaxBehaviorHandler class), we add the facelet context, tag settings and event name to this stack. Then all the tags of components that implement IceClientBehaviorHolder will look for this stack and add the behaviours to the newly-created component. After all children of the ace:ajax tag have been processed, the behaviour settings are removed (popped) from the stack. Thus, the ace:ajax tag follows the same rules or precedence described in the section 10.4.1.1 of the JSF 2.0 specification. Unfortunately, at the moment it doesn't seem feasible to also support/affect standard (h: ) components nested inside our ace:ajax tag, since Mojarra and Myfaces use different approaches to support f:ajax in wrapping mode. Each of them uses their own classes that aren't part of the standard API. Many of these methods are private and we can't access them. Also, the different component implementations expect different things to be available when looking for ajax behaviours defined by a wrapping tag. There might also be some conflicts using ids to store application-wide objects. Each implementation has its own approach since the JSF specification doesn't mention any details regarding how this mechanism should be implemented. Also, when traversing the tag tree, it's not possible to directly access tag children and the components they create at the times where it would be optimal do be able to do so. However, both ace:ajax and f:ajax tags can coexist and each will only affect the components they support. It's possible to wrap a set of ace: and h: components inside an ace:ajax and f:ajax tag. The order is not relevant.
        Arturo Zambrano made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Liana Munroe added a comment - - edited

        New failures are seen with certain ace:dataTable test applications. Tomcat 7, all browsers. Icefaces 4 trunk r41494.
        The new failures are seen in the following test applications:
        Row State EL
        Input Component Processing
        Input Component Processing/ with FAjax
        StateMap Size
        StateMap Sync
        Not an issue with ee-maintenance branch.
        Browser error appears:
        For input string: "7895466090007243068:-5492966339740380774"
        class.java.lang.NumberFormatException
        Text input changes to a large number after submission.
        Example: "test1" was entered into the UPC header filter. Input was submitted. The return value of the input is correct but the textEntry value changes to number. See screen shots before.PNG, after.PNG
        Test application located at:
        C:\svn\repo\qa\trunk\Regression-Icefaces4\Sparkle\Nightly\dataTable

        Show
        Liana Munroe added a comment - - edited New failures are seen with certain ace:dataTable test applications. Tomcat 7, all browsers. Icefaces 4 trunk r41494. The new failures are seen in the following test applications: Row State EL Input Component Processing Input Component Processing/ with FAjax StateMap Size StateMap Sync Not an issue with ee-maintenance branch. Browser error appears: For input string: "7895466090007243068:-5492966339740380774" class.java.lang.NumberFormatException Text input changes to a large number after submission. Example: "test1" was entered into the UPC header filter. Input was submitted. The return value of the input is correct but the textEntry value changes to number. See screen shots before.PNG, after.PNG Test application located at: C:\svn\repo\qa\trunk\Regression-Icefaces4\Sparkle\Nightly\dataTable
        Liana Munroe made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Liana Munroe made changes -
        Attachment after.PNG [ 17245 ]
        Attachment before.PNG [ 17246 ]
        Liana Munroe made changes -
        Attachment before.PNG [ 17246 ]
        Liana Munroe made changes -
        Attachment before.PNG [ 17247 ]
        Hide
        Arturo Zambrano added a comment -

        I haven't been able to see/reproduce those last issues. I checked out the test application from...

        http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataTable

        ...and I navigated to the pages 'Input Component Processing' and 'Input Component Processing w/ f:ajax'. Then, I entered 'test1' and 'test2' in the filter fields of the first two columns, respectively, and then I clicked the submit button, and both filter strings stayed the same; they didn't change to a number. I didn't see errors in the server console nor in the browser console either.

        Can you please provide steps to reproduce the issues in other test pages?

        Show
        Arturo Zambrano added a comment - I haven't been able to see/reproduce those last issues. I checked out the test application from... http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataTable ...and I navigated to the pages 'Input Component Processing' and 'Input Component Processing w/ f:ajax'. Then, I entered 'test1' and 'test2' in the filter fields of the first two columns, respectively, and then I clicked the submit button, and both filter strings stayed the same; they didn't change to a number. I didn't see errors in the server console nor in the browser console either. Can you please provide steps to reproduce the issues in other test pages?
        Ken Fyten made changes -
        Issue Type Improvement [ 4 ] New Feature [ 2 ]
        Hide
        Liana Munroe added a comment -

        The input Component Processing test produces this error when entering test into the first 2 test applications header fields. In the normal header test the input text is changed, in the 2nd app (multi row header) the input field displays correctly but the submit button below the table displays the long number as a value instead of "Submit". See screen shot Multi.PNG. These results were produced on 3 different machines using IF4 code revisions 41494, 41495 and 41497.
        For the other applications just general interaction would spawn the error, inputting text or clicking on table rows.
        Server errors are also seen
        Jun 19, 2014 4:31:56 PM com.sun.faces.lifecycle.ApplyRequestValuesPhase execute
        WARNING: For input string: "-4144328025155680052:4219605870235345986"
        java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:495)
        at java.lang.Integer.parseInt(Integer.java:527)
        at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState
        at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53)
        at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43)
        at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61)
        at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)
        at org.icefaces.ace.component.datatable.DataTable.processDecodes(DataTable.java:456)
        at javax.faces.component.UIForm.processDecodes(UIForm.java:225)
        at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220)....

        Jun 19, 2014 4:31:56 PM com.sun.faces.context.AjaxExceptionHandlerImpl handlePartialResponseError
        SEVERE: java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:495)
        at java.lang.Integer.parseInt(Integer.java:527)
        at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState.java:114)
        at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53)
        at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43)
        at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61)
        at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)...........

        Show
        Liana Munroe added a comment - The input Component Processing test produces this error when entering test into the first 2 test applications header fields. In the normal header test the input text is changed, in the 2nd app (multi row header) the input field displays correctly but the submit button below the table displays the long number as a value instead of "Submit". See screen shot Multi.PNG. These results were produced on 3 different machines using IF4 code revisions 41494, 41495 and 41497. For the other applications just general interaction would spawn the error, inputting text or clicking on table rows. Server errors are also seen Jun 19, 2014 4:31:56 PM com.sun.faces.lifecycle.ApplyRequestValuesPhase execute WARNING: For input string: "-4144328025155680052:4219605870235345986" java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:495) at java.lang.Integer.parseInt(Integer.java:527) at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53) at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43) at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) at org.icefaces.ace.component.datatable.DataTable.processDecodes(DataTable.java:456) at javax.faces.component.UIForm.processDecodes(UIForm.java:225) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220).... Jun 19, 2014 4:31:56 PM com.sun.faces.context.AjaxExceptionHandlerImpl handlePartialResponseError SEVERE: java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:495) at java.lang.Integer.parseInt(Integer.java:527) at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState.java:114) at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53) at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43) at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)...........
        Liana Munroe made changes -
        Attachment multi.PNG [ 17249 ]
        Hide
        Arturo Zambrano added a comment -

        The last issues reported above are not caused by this fix. They are caused by ICE-9953.

        You can try reverting the core and push folders to the revision before the ICE-9953 commit (41493) and you can see that these issues aren't present, whether the fix for ICE-10080 is in effect or not. Likewise, using jars (core and push) with the ICE-9953 fix, these issues will happen, whether the ace jar has the ICE-10080 fix or not.

        Please re-open ICE-9953 or create another JIRA for these new issues.

        Show
        Arturo Zambrano added a comment - The last issues reported above are not caused by this fix. They are caused by ICE-9953 . You can try reverting the core and push folders to the revision before the ICE-9953 commit (41493) and you can see that these issues aren't present, whether the fix for ICE-10080 is in effect or not. Likewise, using jars (core and push) with the ICE-9953 fix, these issues will happen, whether the ace jar has the ICE-10080 fix or not. Please re-open ICE-9953 or create another JIRA for these new issues.
        Arturo Zambrano made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Liana Munroe added a comment -

        ICE-9953 was reopened.

        Show
        Liana Munroe added a comment - ICE-9953 was reopened.
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Ken Fyten
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: