Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.BETA1
    • Fix Version/s: 3.1.0.RC1, 3.1
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ACE
    • Assignee Priority:
      P1
    • Affects:
      Compatibility/Configuration

      Description

      Bring ace:ajax more in line with f:ajax in its ability to operate with composite components and have its properties be specified by EL expressions coming from ui:parameters.

        Issue Links

          Activity

          Mark Collette created issue -
          Mark Collette made changes -
          Field Original Value New Value
          Salesforce Case []
          Fix Version/s 3.1.0.RC1 [ 10337 ]
          Assignee Mark Collette [ mark.collette ]
          Mark Collette made changes -
          Salesforce Case []
          Description Bring ace:ajax more in line with f:ajax Bring ace:ajax more in line with f:ajax in its ability to operate with composite components and have its properties be specified by EL expressions coming from ui:parameters.
          Mark Collette made changes -
          Link This issue depends on ICE-8260 [ ICE-8260 ]
          Mark Collette made changes -
          Link This issue blocks ICE-8221 [ ICE-8221 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #29525 Mon Jun 18 05:18:15 MDT 2012 mark.collette ICE-8258 : Re-architect ace:ajax
          Files Changed
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorHandler.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorRenderer.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehavior.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorHandlerMeta.java
          Commit graph ADD /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorListenerImpl.java
          Mark Collette made changes -
          Link This issue depends on ICE-8223 [ ICE-8223 ]
          Mark Collette made changes -
          Link This issue depends on ICE-8180 [ ICE-8180 ]
          Hide
          Mark Collette added a comment -

          This is a fuller solution to ICE-8180 / ICE-8223, and uses lessons learned from them, as well as some of the code developed in them, although re-architected.

          Extend TagHandler instead of BehaviorHandler, which involves directly implementing code instead of delegating to opaque JSF impl class. Also adds the concept of having nested (f:ajax is child of another tag), and wrapped (f:ajax is the parent of other tags) scenarios. Can more directly setup the created AjaxBehavior instance. And there's a subtle difference of treating a composite component parent as potentially a ClientBehaviorHolder itself. Not sure if that was relevant though.

          Investigated Mojarra and MyFaces techniques of having f:ajax work both in a nested, and wrapped scenarios. Found way of interoperating with Mojarra for all nested scenarios, but only some with MyFaces. More work could be done there with proper test cases. Won't fully work with wrapping composite components though, as this is done incompatibly and opaquely in Mojarra and MyFaces. Refer to comments in AjaxBehaviorHandler.applyWrapped for more details.

          Moved the listener invocation from AjaxBehavior.broadcast to AjaxBehaviorListenerImpl, and the MethodExpression creation from AjaxBehaviorHandler's MetaRuleset code to AjaxBehaviorHandler.addListenerToAjaxBehavior. New superclass doesn't provide MetaRuleset creation anymore. Now we don't need the MethodRule changes that were introduced in ICE-8180 / ICE-8223.

          Added lazy evaluation of ValueExpressions for ace:ajax properties, which had previously been evaluated at construction time to their primitive values. Now state save the attached state for the ValueExpressions.

          trunk
          Subversion 29525

          Show
          Mark Collette added a comment - This is a fuller solution to ICE-8180 / ICE-8223 , and uses lessons learned from them, as well as some of the code developed in them, although re-architected. Extend TagHandler instead of BehaviorHandler, which involves directly implementing code instead of delegating to opaque JSF impl class. Also adds the concept of having nested (f:ajax is child of another tag), and wrapped (f:ajax is the parent of other tags) scenarios. Can more directly setup the created AjaxBehavior instance. And there's a subtle difference of treating a composite component parent as potentially a ClientBehaviorHolder itself. Not sure if that was relevant though. Investigated Mojarra and MyFaces techniques of having f:ajax work both in a nested, and wrapped scenarios. Found way of interoperating with Mojarra for all nested scenarios, but only some with MyFaces. More work could be done there with proper test cases. Won't fully work with wrapping composite components though, as this is done incompatibly and opaquely in Mojarra and MyFaces. Refer to comments in AjaxBehaviorHandler.applyWrapped for more details. Moved the listener invocation from AjaxBehavior.broadcast to AjaxBehaviorListenerImpl, and the MethodExpression creation from AjaxBehaviorHandler's MetaRuleset code to AjaxBehaviorHandler.addListenerToAjaxBehavior . New superclass doesn't provide MetaRuleset creation anymore. Now we don't need the MethodRule changes that were introduced in ICE-8180 / ICE-8223 . Added lazy evaluation of ValueExpressions for ace:ajax properties, which had previously been evaluated at construction time to their primitive values. Now state save the attached state for the ValueExpressions. trunk Subversion 29525
          Hide
          Mark Collette added a comment - - edited

          Instead of the re-architecting, I had investigated an in-between change, of still inheriting from BehaviorHandler, instead of TagHandler; using the MetaRuleset and broadcast, instead of an AjaxBehaviorListener; and not needing the ICE-8260 generator change, while still incorporating lazy evaluation of ValueExpressions. It didn't work though, failing the ICE-8221 test. I've attached the source for that attempt, in case it's ever needed.

          Show
          Mark Collette added a comment - - edited Instead of the re-architecting, I had investigated an in-between change, of still inheriting from BehaviorHandler, instead of TagHandler; using the MetaRuleset and broadcast, instead of an AjaxBehaviorListener; and not needing the ICE-8260 generator change, while still incorporating lazy evaluation of ValueExpressions. It didn't work though, failing the ICE-8221 test. I've attached the source for that attempt, in case it's ever needed.
          Mark Collette made changes -
          Attachment ajax.zip [ 14583 ]
          Mark Collette made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Ken Fyten added a comment -

          Re-open due to regressions.

          Show
          Ken Fyten added a comment - Re-open due to regressions.
          Ken Fyten made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Assignee Priority P1
          Hide
          Cruz Miraback added a comment -

          When navigating to the ace:ajax test page, there is an exception in the server logs. To reproduce:
          1. Build / deploy test application (this can be for any component with ajax functionality, for example: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dialog)
          2. Navigate to the Ajax test page

          SEVERE: Servlet.service() for servlet Faces Servlet threw exception
          java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
          at org.icefaces.ace.component.ajax.AjaxBehavior.isDisabled(AjaxBehavior.java:142)
          at org.icefaces.ace.component.ajax.AjaxBehaviorRenderer.getScript(AjaxBehaviorRenderer.java:69)
          at javax.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:103)
          at org.icefaces.ace.renderkit.CoreRenderer.encodeClientBehaviors(CoreRenderer.java:249)
          at org.icefaces.ace.component.tooltip.TooltipRenderer.encodeScript(TooltipRenderer.java:178)
          at org.icefaces.ace.component.tooltip.TooltipRenderer.encodeEnd(TooltipRenderer.java:76)
          at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
          at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1764)
          at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
          at org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49)
          at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
          at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
          at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
          at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
          at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757)
          at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
          at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
          at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
          at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
          at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
          at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
          at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
          at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
          at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
          at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
          at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
          at java.lang.Thread.run(Thread.java:619)

          Show
          Cruz Miraback added a comment - When navigating to the ace:ajax test page, there is an exception in the server logs. To reproduce: 1. Build / deploy test application (this can be for any component with ajax functionality, for example: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dialog ) 2. Navigate to the Ajax test page SEVERE: Servlet.service() for servlet Faces Servlet threw exception java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean at org.icefaces.ace.component.ajax.AjaxBehavior.isDisabled(AjaxBehavior.java:142) at org.icefaces.ace.component.ajax.AjaxBehaviorRenderer.getScript(AjaxBehaviorRenderer.java:69) at javax.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:103) at org.icefaces.ace.renderkit.CoreRenderer.encodeClientBehaviors(CoreRenderer.java:249) at org.icefaces.ace.component.tooltip.TooltipRenderer.encodeScript(TooltipRenderer.java:178) at org.icefaces.ace.component.tooltip.TooltipRenderer.encodeEnd(TooltipRenderer.java:76) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1764) at javax.faces.render.Renderer.encodeChildren(Renderer.java:168) at org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619)
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #29534 Mon Jun 18 17:46:47 MDT 2012 mark.collette ICE-8258 : Re-architect ace:ajax
          Files Changed
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorHandler.java
          Hide
          Mark Collette added a comment -

          When literal values were used, instead of EL, for the ace:ajax properties, I wasn't using the API that did EL coercion. This affected disabled and immediate.

          trunk
          Subversion 29534

          Show
          Mark Collette added a comment - When literal values were used, instead of EL, for the ace:ajax properties, I wasn't using the API that did EL coercion. This affected disabled and immediate. trunk Subversion 29534
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #29535 Mon Jun 18 19:55:13 MDT 2012 mark.collette ICE-8258 : Re-architect ace:ajax
          Files Changed
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/ajax/AjaxBehaviorHandler.java
          Hide
          Mark Collette added a comment -

          When relying on the default event name, instead of an explicit one, the code that adds the AjaxBehavior to the ClientBehaviorHolder was doing nothing given a null event name. Had to resolve the event name from the default first, before adding it.

          trunk
          Subversion 29535

          Show
          Mark Collette added a comment - When relying on the default event name, instead of an explicit one, the code that adds the AjaxBehavior to the ClientBehaviorHolder was doing nothing given a null event name. Had to resolve the event name from the default first, before adding it. trunk Subversion 29535
          Hide
          Ken Fyten added a comment -

          Possible regression:

          I've retested showcase on icefaces3/trunk revision# 29535. The following issue is present:

          ace:panel > Listener

          • The listener never gets called (or at least, the values do not get updated on the page) when interacting with the panel.
          Show
          Ken Fyten added a comment - Possible regression: I've retested showcase on icefaces3/trunk revision# 29535. The following issue is present: ace:panel > Listener The listener never gets called (or at least, the values do not get updated on the page) when interacting with the panel.
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #29555 Tue Jun 19 23:37:28 MDT 2012 mark.collette ICE-8258 : Re-architect ace:ajax
          Files Changed
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/event/DateTextChangeEvent.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/event/CloseEvent.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/event/DateSelectEvent.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/event/ToggleEvent.java
          Hide
          Mark Collette added a comment -

          Basically this is the same root issue as ICE-8223, but with the new code base. dateTimeEntry, dialog and panel all use custom event objects that sub-class AjaxBehaviorEvent. When the ace:ajax listener invocation was changed from using MethodRule and broadcast, to using AjaxBehaviorListenerImpl, those custom events needed to be updated. With broadcast invocation, events don't fire themselves, but with the AjaxBehaviorListenerImpl way, they do fire themselves (as is the JSF norm). So the events just need to stop overriding and thwarting the self firing methods inherited from their super-class.

          Show
          Mark Collette added a comment - Basically this is the same root issue as ICE-8223 , but with the new code base. dateTimeEntry, dialog and panel all use custom event objects that sub-class AjaxBehaviorEvent. When the ace:ajax listener invocation was changed from using MethodRule and broadcast, to using AjaxBehaviorListenerImpl, those custom events needed to be updated. With broadcast invocation, events don't fire themselves, but with the AjaxBehaviorListenerImpl way, they do fire themselves (as is the JSF norm). So the events just need to stop overriding and thwarting the self firing methods inherited from their super-class.
          Hide
          Mark Collette added a comment -

          Tested dateTimeEntry, dialog, panel regression tests, and can confirm they all submit to the server, but the listener isn't invoked. Tested against the different special case from ICE-8223, notificationPanel, that does use an AjaxBehaviorEvent, and not a custom sub-class, and found that its listener is getting invoked.

          Removed the isAppropriateListener and processListener overrides from CloseEvent, DateSelectEvent, DateTextChangeEvent and ToggleEvent, and retested the components. They all work now.

          trunk
          Subversion 29555

          Show
          Mark Collette added a comment - Tested dateTimeEntry, dialog, panel regression tests, and can confirm they all submit to the server, but the listener isn't invoked. Tested against the different special case from ICE-8223 , notificationPanel, that does use an AjaxBehaviorEvent, and not a custom sub-class, and found that its listener is getting invoked. Removed the isAppropriateListener and processListener overrides from CloseEvent, DateSelectEvent, DateTextChangeEvent and ToggleEvent, and retested the components. They all work now. trunk Subversion 29555
          Mark Collette made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 3.1 [ 10312 ]
          Ken Fyten made changes -
          Salesforce Case []
          Affects [Compatibility/Configuration]
          Ken Fyten made changes -
          Issue Type New Feature [ 2 ] Improvement [ 4 ]
          Salesforce Case []
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Mark Collette
              Reporter:
              Mark Collette
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: