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

Hi Jakob, +1 from my side, best regards, Martin On 10/29/10, Jakob Korherr <jakob.korherr(a)gmail.com&gt; wrote: > Hi, > > Thinking more of it and trying out some prototypes, I now think > Leonardo's approach is the way to go. Of course, it would somehow be > possible to circumvent the problems mentioned before (like multiple > action listeners or the missing f: tag for client behaviors), but > after reading the vdldocs again, I think it's much more consistent > with what we have right now. > > Consider the current facet solution: The user can provide facets for > the composite component and the author of the composite component can > add them to implementation-components via cc:insertFacet. And this is > exactly what we need for cc:actionSource, cc:valueHolder, > cc:editableValueHolder and cc:clientBehavior. > > Thus I would propose the following new tags (from Leonardo's original > proposal): > > <cc:insertActionSource name="XXX" /> > <cc:insertEditableValueHolder name="XXX"/> > <cc:insertValueHolder name="XXX" /> > <cc:insertClientBehavior name="XXX" /> > > What do you think? > > Regards, > Jakob > > 2010/10/29 Martin Marinschek <mmarinschek(a)apache.org&gt;: >> Hi Gentlemen, >> >> I am leaning toward Jakob's approach, but if it is not possible due to >> the constraints Leonardo mentioned, then why not add the necessary >> tags? >> >> @Leonardo, Jakob: can you put your heads together and come up with a >> combined proposal? >> >> best regards, >> >> Martin >> >> On 10/29/10, Ed Burns <edward.burns(a)oracle.com&gt; wrote: >>>>>>>> On Thu, 28 Oct 2010 12:56:53 -0500, Leonardo Uribe >>>>>>>> <lu4242(a)gmail.com&gt; >>>>>>>> said: >>> >>> LU> Hi >>> 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 >>> point >>> to >>> LU> just >>> LU> 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? >>> >>> The type of the binding attribute is specified thus. >>> >>> Value binding expression that evaluates to an object that implements >>> javax.faces.event.ActionListener >>> >>> How would you make that handle a list? >>> >>> Sure, we could go and add a raft of new "bindingList" attributes to all >>> of the attached object handlers in f:, but is it worth the complexity? >>> >>> >>> Ed >>> -- >>> | edward.burns(a)oracle.com | office: +1 407 458 0017 >>> | homepage: | http://ridingthecrest.com/ >>> | 9 work days until German Oracle User's Group Conference >>> >> >> >> -- >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces