ICEfaces
  1. ICEfaces
  2. ICE-7523

MyFaces 2: listeners registered with ace:ajax tags are not called

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1-Beta2, 3.0.RC1
    • Fix Version/s: 3.0.RC2, 3.0
    • Component/s: Documentation
    • Labels:
      None
    • Environment:
      MyFaces 2 ICEfaces 3 ACE
    • Assignee Priority:
      P1

      Description

      The Panel Listeners demo does not work when running with MyFaces 2. The methods of the PanelListener that are registered to handle the "toggle" and "close" events are never fired.

      The events used to work in a previous revision (26555) but that was when each menu link was bookmarkable and triggered a full page load. That scenario still works - ie if you load the panelListener.xhtml file on its own, the panel events do fire.

      So the problem is related to ace:ajax listeners that are added to the component tree dynamically after the page has initially been rendered.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          A couple of other things to note:

          I checked another example, the Date Time Entry Ajax Submit example as it's characteristics are very similar to to the Panel Listeners and it turns out that the listener is not fired there either. It's just that there is nothing in the UI to make this easily detectable. The setter is actually updating the date.

          To boil down what I think the problem is. The AjaxBehavior(s) associated with the component are being handled differently than Mojarra. When you interact with the component

          Mojarra:

          AjaxBehaviour 'A' is created as part of Facelets construction
          Listener is associated
          AjaxBehaviour 'B' is created as part of View restoration
          Listener is not associated
          AjaxBehaviour 'A' is used (which has the associated Listener)

          MyFaces:

          AjaxBehaviour 'A' is created as part of Facelets construction
          Listener is associated
          AjaxBehaviour 'B' is created as part of View restoration
          Listener is not associated
          AjaxBehaviour 'B' is used (which does not have the associated Listener)

          Show
          Deryk Sinotte added a comment - A couple of other things to note: I checked another example, the Date Time Entry Ajax Submit example as it's characteristics are very similar to to the Panel Listeners and it turns out that the listener is not fired there either. It's just that there is nothing in the UI to make this easily detectable. The setter is actually updating the date. To boil down what I think the problem is. The AjaxBehavior(s) associated with the component are being handled differently than Mojarra. When you interact with the component Mojarra: AjaxBehaviour 'A' is created as part of Facelets construction Listener is associated AjaxBehaviour 'B' is created as part of View restoration Listener is not associated AjaxBehaviour 'A' is used (which has the associated Listener) MyFaces: AjaxBehaviour 'A' is created as part of Facelets construction Listener is associated AjaxBehaviour 'B' is created as part of View restoration Listener is not associated AjaxBehaviour 'B' is used (which does not have the associated Listener)
          Hide
          Deryk Sinotte added a comment -

          So the issue definitely seems to be that, with MyFaces, when restoring the state, it creates new AjaxBehaviours for the ace:ajax listeners. However, unlike Mojarra, MyFaces uses the instance of the behaviours that were created during view restoration

          I've tweaked a number of things (like ensuring transient is set, etc) but haven't yet found a way to either:

          1) Tell MyFaces to not use the AjaxBehavior created during the restore view phase or
          2) Have the listener attributed re-evaluated so that the listener is not null when the event is broadast to it.

          I also haven't been able to come up with a non-ICEfaces test case that shows the same problem.

          Show
          Deryk Sinotte added a comment - So the issue definitely seems to be that, with MyFaces, when restoring the state, it creates new AjaxBehaviours for the ace:ajax listeners. However, unlike Mojarra, MyFaces uses the instance of the behaviours that were created during view restoration I've tweaked a number of things (like ensuring transient is set, etc) but haven't yet found a way to either: 1) Tell MyFaces to not use the AjaxBehavior created during the restore view phase or 2) Have the listener attributed re-evaluated so that the listener is not null when the event is broadast to it. I also haven't been able to come up with a non-ICEfaces test case that shows the same problem.
          Hide
          Deryk Sinotte added a comment -

          We've now run into a bit of a conundrum. I thought I had tested this before but just to verify if it had an impact or not, I removed the following context parameters from the showcase:

          <context-param>
          <param-name>org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS</param-name>
          <param-value>true</param-value>
          </context-param>

          <context-param>
          <param-name>org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE</param-name>
          <param-value>true</param-value>
          </context-param>

          which, while breaking other things, allows the listeners to fire properly. These parameters were initially added to fix ICE-7017 and related to https://issues.apache.org/jira/browse/MYFACES-3271 as well.

          Show
          Deryk Sinotte added a comment - We've now run into a bit of a conundrum. I thought I had tested this before but just to verify if it had an impact or not, I removed the following context parameters from the showcase: <context-param> <param-name>org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS</param-name> <param-value>true</param-value> </context-param> <context-param> <param-name>org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE</param-name> <param-value>true</param-value> </context-param> which, while breaking other things, allows the listeners to fire properly. These parameters were initially added to fix ICE-7017 and related to https://issues.apache.org/jira/browse/MYFACES-3271 as well.
          Hide
          Deryk Sinotte added a comment -

          Turns out that adding save/restore state operations to AjaxBehavior was required. Not sure what went wrong before as the initial attempts to add state saving didn't appear to work. In this case, we simply did something similar to what the Mojarra AjaxBehavior class was already doing.

          Show
          Deryk Sinotte added a comment - Turns out that adding save/restore state operations to AjaxBehavior was required. Not sure what went wrong before as the initial attempts to add state saving didn't appear to work. In this case, we simply did something similar to what the Mojarra AjaxBehavior class was already doing.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: