[jsr-314-open-mirror] [jsr-314-open] [901-DeprecateTargetsConcept] (was: Re: composite components: targets attribute revisited)

[Ed Burns]

LU> To be more explicit, this is the example that should fail:

LU> <ez:loginPanel id="loginPanel" model="#{bean}">
LU> <f:actionListener for="loginEvent"
LU> binding="#{bean.loginEventListener}" />
LU> <f:actionListener for="loginEvent"
LU> binding="#{bean.loginEventListener2}" />
LU> <f:actionListener for="cancelEvent"
LU> binding="#{bean.cancelEventListener}" />
LU> </ez:loginPanel>

LU> <composite:interface name="loginPanel">
LU> <composite:actionSource name="loginEvent" />
LU> <composite:actionSource name="cancelEvent" />
LU> </composite:interface>
LU> <composite:implementation>
LU> <h:commandButton name="button1">
LU> <f:actionListener
LU> binding="#{cc.actionSource.loginEvent}"/>
LU> </h:commandButton>
LU> <x:mycompositecomponent name="button2">
LU> <f:actionListener
LU> binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/>
LU> </x:mycompositecomponent>
LU> </composite:implementation>

LU> In this case, the binding #{cc.actionSource.loginEvent} does not
LU> point to just one actionListener.

GP> Leo, IMO your example wouldn't need to fail: the nested
GP> actionListener with binding="#{cc.actionSource.loginEvent}" would
GP> need to execute *all* actionListeners that have been bound to
GP> "loginEvent". In this case "#{bean.loginEventListener}" and
GP> "#{bean.loginEventListener2}" would reside in a Map named
GP> cc.actionSource.loginEvent and could both be executed. Wouldn't this
GP> work?

EB> The type of the binding attribute is specified thus.

EB> Value binding expression that evaluates to an object that implements
EB> javax.faces.event.ActionListener

EB> How would you make that handle a list?

EB> Sure, we could go and add a raft of new "bindingList" attributes to all
EB> of the attached object handlers in f:, but is it worth the complexity?

>>>>> On Fri, 29 Oct 2010 12:05:17 +0200, Martin Marinschek <mmarinschek at apache.org> said:

MM> Hi Gentlemen,
MM> I am leaning toward Jakob's approach, but if it is not possible due to
MM> the constraints Leonardo mentioned, then why not add the necessary
MM> tags?

MM> @Leonardo, Jakob: can you put your heads together and come up with a
MM> combined proposal?

Please do so on this new issue I've created [1].  We will not be able to
put this into 2.1.  I'm afraid we'll have to live with only targets for
2.1.  This will have to go into 2.2.

Ed

[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=901
-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
|  8 work days until German Oracle User's Group Conference