Uploaded image for project: 'MyFaces Core'
  1. MyFaces Core
  2. MYFACES-3251

composite component attributes with @method-signature declared should carry through as MethodExpressions, but do not

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.1.2-SNAPSHOT
    • 2.0.8, 2.1.2
    • None
    • None

    Description

      for this reason e.g. a cc cannot propagate an action attribute to an inner h:commandButton.

      Attachments

        1. MYFACES-3251.tar.gz
          5 kB
          Matthew Jason Benson

        Activity

          test project demonstrating the problem. Works on mojarra.

          mbenson Matthew Jason Benson added a comment - test project demonstrating the problem. Works on mojarra.
          lu4242 Leonardo Uribe added a comment -

          It seems mojarra guys finally applied the patch sent by myself long time ago about resolve #

          {cc.attrs.action}

          . I never thought they will apply it on 2.0.x/2.1.x branches, because this is not documented anywhere on the spec.

          The good news is the alternative using "targets" property works on MyFaces as discussed previously on the EG:
          <composite:interface>
          <composite:attribute name="action" required="true" method-signature="java.lang.Object action()" targets="button"/>
          <composite:attribute name="value" required="true" />
          </composite:interface>
          <composite:implementation>
          <h:commandButton id="button" value="#

          {cc.attrs.value}

          " styleClass="justificationForMyExistence" />
          </composite:implementation>

          In theory, in JSF 2.1 a new attribute on <cc:attribute> was added called targetAttributeName to complete the solution using "targets". But I never ported the other alternative to myfaces, because both algorithm are very different in this part.

          The big problem is how to deal when nested EL expressions are used. It is not simple, because you have to "chain" the expressions.

          This issue is not considered a bug, instead it is an improvement proposed from MyFaces side.

          lu4242 Leonardo Uribe added a comment - It seems mojarra guys finally applied the patch sent by myself long time ago about resolve # {cc.attrs.action} . I never thought they will apply it on 2.0.x/2.1.x branches, because this is not documented anywhere on the spec. The good news is the alternative using "targets" property works on MyFaces as discussed previously on the EG: <composite:interface> <composite:attribute name="action" required="true" method-signature="java.lang.Object action()" targets="button"/> <composite:attribute name="value" required="true" /> </composite:interface> <composite:implementation> <h:commandButton id="button" value="# {cc.attrs.value} " styleClass="justificationForMyExistence" /> </composite:implementation> In theory, in JSF 2.1 a new attribute on <cc:attribute> was added called targetAttributeName to complete the solution using "targets". But I never ported the other alternative to myfaces, because both algorithm are very different in this part. The big problem is how to deal when nested EL expressions are used. It is not simple, because you have to "chain" the expressions. This issue is not considered a bug, instead it is an improvement proposed from MyFaces side.
          lu4242 Leonardo Uribe added a comment -

          This was very difficult to solve. I created many junit cases to ensure the hack proposed will work, even when nested composite components are used or mixtures between "targets" and expressions.

          lu4242 Leonardo Uribe added a comment - This was very difficult to solve. I created many junit cases to ensure the hack proposed will work, even when nested composite components are used or mixtures between "targets" and expressions.

          Thanks, Leo... actually as it turned out in this case I needed to pull the current value of the attribute for inspection, which made the @targets setup more suited to my needs anyway: pulling getActionExpression().getExpressionString() returned "#

          {cc.attrs.action}

          ", on which I'd have had to do a lot of mining to do the inspection I am doing.

          mbenson Matthew Jason Benson added a comment - Thanks, Leo... actually as it turned out in this case I needed to pull the current value of the attribute for inspection, which made the @targets setup more suited to my needs anyway: pulling getActionExpression().getExpressionString() returned "# {cc.attrs.action} ", on which I'd have had to do a lot of mining to do the inspection I am doing.

          People

            lu4242 Leonardo Uribe
            mbenson Matthew Jason Benson
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: