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