[jsr-314-open-mirror] [jsr-314-open] composite components: targets attribute revisited

[Leonardo Uribe]

Hi

2010/10/28 Jakob Korherr <jakob.korherr at gmail.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20101028/31341b82/attachment-0002.html