Hi<br><br>Attached to this issue:<br><br><a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755</a><br><br> there is a patch that shows what is required to use<br>
<br>#{cc.attrs.action} , <br>#{cc.attrs.actionListener} , <br>#{cc.attrs.validator} ,  <br>#{cc.attrs.valueChangeListener} <br><br>The idea is just use this expressions instead set &quot;targets&quot; property on cc:attribute.<br>
<br>In this way it is possible to write something like this:<br><br>testActionVE.xhtml<br><br>&lt;testcc:actionVE label=&quot;Press me&quot; action=&quot;#{helloWorld.send2}&quot;/&gt;<br><br>actionVE.xhtml<br><br>&lt;cc:interface&gt;<br>
    &lt;cc:attribute name=&quot;action&quot;/&gt;<br>    &lt;cc:attribute name=&quot;label&quot;/&gt;<br>&lt;/cc:interface&gt;<br>&lt;cc:implementation&gt;<br>    &lt;h:commandButton value=&quot;#{cc.attrs.label}&quot; action=&quot;#{cc.attrs.action}&quot;/&gt;<br>
&lt;/cc:implementation&gt;<br><br>Fortunately, this change does not prevent &quot;targets&quot; attribute to work. From my point<br>of view seems to be very intuitive, compared with the other style.<br><br>&lt;cc:interface&gt;<br>

    &lt;cc:attribute name=&quot;action&quot; targets=&quot;button&quot; /&gt;<br>
    &lt;cc:attribute name=&quot;label&quot;/&gt;<br>
&lt;/cc:interface&gt;<br>
&lt;cc:implementation&gt;<br>
    &lt;h:commandButton id=&quot;button&quot; value=&quot;#{cc.attrs.label}&quot;/&gt;<br>
&lt;/cc:implementation&gt;<br><br>So at least for cc:attribute it seems valid (and wanted) to do the change.<br><br>Thinking more about this issues I have a proposal to solve:<br><br><a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=859">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=859</a><br>
<br>Composite components only support one action attribute<br><br>Why this syntax is not possible?<br><br>&lt;cc:interface&gt;<br>
    &lt;cc:attribute name=&quot;action&quot; method-signature=&quot;Object myMethod();void myMethod()&quot; ..../&gt;<br>    &lt;cc:attribute name=&quot;actionListener&quot; method-signature=&quot;void myMethod(javax.faces.event.ActionEvent);void 
myMethod()&quot; ..../&gt;<br>
    &lt;cc:attribute name=&quot;label&quot;/&gt;<br>
&lt;/cc:interface&gt;<br><br>That means, allow multiple signatures for a method expression and use some wrapper <br>like the one proposed with the previous patch.<br><br>One last comment: How to deprecate &quot;targets&quot; also for cc:actionSource, cc:valueHolder, <br>
cc:editableValueHolder and cc:clientBehavior? One possibility is do something like this:<br><br>      &lt;ez:loginPanel id=&quot;loginPanel&quot; model=&quot;#{bean}&quot;&gt;<br>        &lt;f:actionListener for=&quot;loginEvent&quot;<br>
                          binding=&quot;#{bean.loginEventListener}&quot; /&gt;<br>        &lt;f:actionListener for=&quot;cancelEvent&quot;<br>                          binding=&quot;#{bean.cancelEventListener}&quot; /&gt;<br>
      &lt;/ez:loginPanel&gt; <br><br>      &lt;composite:interface name=&quot;loginPanel&quot;&gt;<br>        &lt;composite:actionSource name=&quot;loginEvent&quot; /&gt;<br>        &lt;composite:actionSource name=&quot;cancelEvent&quot; /&gt;<br>
      &lt;/composite:interface&gt; <br>      &lt;composite:implementation&gt;<br>                  &lt;h:commandButton name=&quot;button1&quot;&gt;<br>                         &lt;composite:insertActionSource name=&quot;loginEvent&quot;/&gt;<br>
                  &lt;/h:commandButton&gt;<br>                  &lt;x:mycompositecomponent name=&quot;button2&quot;&gt;<br>
                         &lt;composite:insertActionSource 
name=&quot;cancelEvent&quot; for=&quot;someOtherEvent&quot;/&gt;<br>
                  &lt;/x:mycompositecomponent&gt;<br>
      &lt;/composite:implementation&gt;<br><br>In few words, use a tag to insert the attached objects. That will work, because<br>in a composite component first it is resolved the body on the page than the tags<br>inside composite:implementation. The advantage over &quot;targets&quot; stuff is the <br>
implementation details are when the people expect and it could handle complex<br>cases in a better way like nested composite components usage, and override &quot;for&quot;<br>attribute.<br><br>I know implement that proposal could be complex to implement, but I think it <br>
could be good to at least take it into consideration. <br><br>I can provide more code of each proposal if necessary.<br><br>best regards,<br><br>Leonardo Uribe<br>