Hi<br><br>To be more explicit, this is the example that should fail:<br><br><ez:loginPanel id="loginPanel" model="#{bean}"><br>
<f:actionListener for="loginEvent"<br>
binding="#{bean.loginEventListener}"
/><br><div id=":4r">
<f:actionListener for="loginEvent"<br>
binding="#{bean.loginEventListener2}"
/><br>
<f:actionListener for="cancelEvent"<br>
binding="#{bean.cancelEventListener}"
/><br>
</ez:loginPanel><br>
<br>
<composite:interface name="loginPanel"><br>
<composite:actionSource name="loginEvent" /><br>
<composite:actionSource name="cancelEvent" /><br>
</composite:interface><br>
<composite:implementation><br>
<h:commandButton name="button1"><br>
<f:actionListener<br>
binding="#{cc.actionSource.loginEvent}"/><br>
</h:commandButton><br>
<x:mycompositecomponent name="button2"><br>
<f:actionListener<br>
binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/><br>
</x:mycompositecomponent><br>
</composite:implementation><br><br>In this case, the binding #{cc.actionSource.loginEvent} does not point to just<br>one actionListener. <br><br>regards,<br><br>Leonardo<br></div> <br><br><div class="gmail_quote">
2010/10/28 Jakob Korherr <span dir="ltr"><<a href="mailto:jakob.korherr@gmail.com">jakob.korherr@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
In option 2 the f:actionListener is just used as a reference to the<br>
cc:actionSource (just as in option 1 but without introducing a new<br>
composite-tag).<br>
<br>
Thus it would actually be possible to have multiple ones!<br>
<br>
Regards,<br>
Jakob<br>
<br>
2010/10/28 Leonardo Uribe <<a href="mailto:lu4242@gmail.com">lu4242@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Hi<br>
><br>
> 2010/10/28 Jakob Korherr <<a href="mailto:jakob.korherr@gmail.com">jakob.korherr@gmail.com</a>><br>
>><br>
>> Hi,<br>
>><br>
>> Currently there are a lot of discussions (on spec-issues, on this list<br>
>> and also internally) about the problems with the targets attribute in<br>
>> the composite component interface and I'd like to wrap these up here.<br>
>><br>
>> IMHO the targets attribute is something we should get rid of, because<br>
>> it directly points to the implementation section and frankly somehow<br>
>> feels like the following piece of code:<br>
>><br>
>> if (this instanceof Foo)<br>
>> {<br>
>> // do something<br>
>> }<br>
>><br>
>> The interface section should just specify the interface for the<br>
>> composite component and should not include any information about the<br>
>> implementation section. However, the implementation section should of<br>
>> course refer to the interface section. Unfortunately the targets<br>
>> attribute works against this. And furthermore the targets attribute<br>
>> also confuses users, because the don't really know which clientid to<br>
>> use (especially with nested components in the implementation section).<br>
>><br>
>> The first step needed here is to put all attributes (also the<br>
>> "well-known" ones like action, actionListener, valueChangeListener) on<br>
>> the composite component attribute map in order to access them via<br>
>> #{cc.attrs.attributeName}. In this way the user can refer from the<br>
>> implementation section to the related attribute in the interface<br>
>> section, regardless of what it does. This was already discussed and is<br>
>> also already accepted, I guess.<br>
>><br>
>> The next step is to remove the targets attribute from cc:actionSource,<br>
>> cc:editableValueHolder and cc:valueHolder. Here we have two options:<br>
>><br>
>> 1) add new composite tags that insert the related listeners in the<br>
>> implementation section (proposed by Leonardo):<br>
>><br>
>> <ez:loginPanel id="loginPanel" model="#{bean}"><br>
>> <f:actionListener for="loginEvent"<br>
>> binding="#{bean.loginEventListener}" /><br>
>> <f:actionListener for="cancelEvent"<br>
>> binding="#{bean.cancelEventListener}" /><br>
>> </ez:loginPanel><br>
>><br>
>> <composite:interface name="loginPanel"><br>
>> <composite:actionSource name="loginEvent" /><br>
>> <composite:actionSource name="cancelEvent" /><br>
>> </composite:interface><br>
>> <composite:implementation><br>
>> <h:commandButton name="button1"><br>
>> <composite:insertActionSource name="loginEvent"/><br>
>> </h:commandButton><br>
>> <x:mycompositecomponent name="button2"><br>
>> <composite:insertActionSource<br>
>> name="cancelEvent" for="someOtherEvent"/><br>
>> </x:mycompositecomponent><br>
>> </composite:implementation><br>
>><br>
>><br>
>> 2) use the existing tags like f:actionListener and<br>
>> f:valueChangeListener and provide the actionSource,.. via<br>
>> ValueExpression:<br>
>><br>
>> <ez:loginPanel id="loginPanel" model="#{bean}"><br>
>> <f:actionListener for="loginEvent"<br>
>> binding="#{bean.loginEventListener}" /><br>
>> <f:actionListener for="cancelEvent"<br>
>> binding="#{bean.cancelEventListener}" /><br>
>> </ez:loginPanel><br>
>><br>
>> <composite:interface name="loginPanel"><br>
>> <composite:actionSource name="loginEvent" /><br>
>> <composite:actionSource name="cancelEvent" /><br>
>> </composite:interface><br>
>> <composite:implementation><br>
>> <h:commandButton name="button1"><br>
>> <f:actionListener<br>
>> binding="#{cc.actionSource.loginEvent}"/><br>
>> </h:commandButton><br>
>> <x:mycompositecomponent name="button2"><br>
>> <f:actionListener<br>
>> binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/><br>
>> </x:mycompositecomponent><br>
>> </composite:implementation><br>
>><br>
>><br>
>> Frankly I'd prefer option 2, because it is very similar to how we<br>
>> handle cc:attribute --> #{cc.attrs.xxx}.<br>
>><br>
>><br>
>> One remaining problem here, however, is how to handle non-required<br>
>> method-attributes (there's a thread about this on the<br>
>> myfaces-user-list). IMO the default attribute of cc:attribute should<br>
>> be able to resolve to a MethodExpression and not only to a String (I<br>
>> think this is already a spec-issue), but it should also work without<br>
>> providing a default value. In that case #{cc.attrs.thatAttribute}<br>
>> should internally return an empty action/listener/... so that there<br>
>> are no problems with the related implementation-components which refer<br>
>> to this attribute.<br>
>><br>
>> What do you think?<br>
>><br>
><br>
> Well, unfortunately use option 2 forces to use just one f:actionListener per<br>
> actionSource, and in theory, it should be possible to have multiple ones.<br>
><br>
> best regards,<br>
><br>
> Leonardo Uribe<br>
><br>
>><br>
>> Regards,<br>
>> Jakob<br>
>><br>
>> --<br>
>> Jakob Korherr<br>
>><br>
>> blog: <a href="http://www.jakobk.com" target="_blank">http://www.jakobk.com</a><br>
>> twitter: <a href="http://twitter.com/jakobkorherr" target="_blank">http://twitter.com/jakobkorherr</a><br>
>> work: <a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Jakob Korherr<br>
<br>
blog: <a href="http://www.jakobk.com" target="_blank">http://www.jakobk.com</a><br>
twitter: <a href="http://twitter.com/jakobkorherr" target="_blank">http://twitter.com/jakobkorherr</a><br>
work: <a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
</div></div></blockquote></div><br>