ICEfaces
  1. ICEfaces
  2. ICE-8261

IceClientBehaviorHolder specify their AjaxBehaviorEvent subclass

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.BETA1
    • Fix Version/s: EE-3.3.0.GA_P01, 4.0.BETA, 4.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ACE
    • Assignee Priority:
      P2

      Description

      IceClientBehaviorHolder is the interface that our ACE components implement when they have behavior events. Their Meta classes have a ClientBehaviorHolder annotation, with ClientEvent annotations per event. The ACE generator generates Base classes that implement IceClientBehaviorHolder with all the annotated events.

      When ace:ajax is nested within an ACE component, it needs to wire up its listener property so that it can invoke a MethodExpression in the bean that takes the appropriate event type. This requires knowing the appropriate javax.faces.event.AjaxBehaviorEvent sub-class that the ACE component will queue and broadcast. Or it might just be a plain AjaxBehaviorEvent itself, and not a sub-class.

      In AjaxBehaviorHandler.deriveEventClass(-) we attempt to derive which Class of event that the IceClientBehaviorHolder will use, by taking advantage of the fact that we happen to name our events after the event name, and that we can use reflection to test if that guess happens to be true, or if we should fall back to assuming it's a plain AjaxBehaviorEvent. This has the downside of using the hard-coded ACE component package that our events are in, and relies on our conventions, which won't necessarily work well for third parties making use of ACEnvironment for their own components.

      It would be better to augment the ClientEvent annotation, ACE generator, and IceClientBehaviorHolder interface, to allow for explicit declaration of the event type. It would also be more declarative and clearer, since if it's not mentioned in the TLDDOC, then auditing the component code is currently the only way of knowing the relevant event type that a bean should use as the argument type in its MethodExpression.

        Issue Links

          Activity

          Hide
          Mark Collette added a comment - - edited

          Added getListenerArgument(String) method to IceClientBehaviorHolder interface, and made generator generate it, and AjaxBehaviorHandler.deriveEventClass make use of it.

          This solves a problem where MaskedEntry's keypress ClientEvent used a KeyPressEvent, so the changing capitalisation did not work with the pre-existing deriveEventClass algorithm using Tomcat 6.

          icefaces3 trunk
          Subversion 37422

          Show
          Mark Collette added a comment - - edited Added getListenerArgument(String) method to IceClientBehaviorHolder interface, and made generator generate it, and AjaxBehaviorHandler.deriveEventClass make use of it. This solves a problem where MaskedEntry's keypress ClientEvent used a KeyPressEvent, so the changing capitalisation did not work with the pre-existing deriveEventClass algorithm using Tomcat 6. icefaces3 trunk Subversion 37422

            People

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

              Dates

              • Created:
                Updated:
                Resolved: