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

[Leonardo Uribe]

Hi Jakob

Could you create an issue on MyFaces and start providing some patches
there?. Right now I'm trying to make cc:attribute "targets" to work on any
condition, including nested composite components, to see if we can solve
that from Mojarra, but it will take some time.

best regards,

Leonardo Uribe

2010/10/29 Martin Marinschek <mmarinschek at apache.org>

> Hi Jakob,
>
> +1 from my side,
>
> best regards,
>
> Martin
>
> On 10/29/10, Jakob Korherr <jakob.korherr at gmail.com> 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 at apache.org>:
> >> 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 at oracle.com> wrote:
> >>>>>>>> On Thu, 28 Oct 2010 12:56:53 -0500, Leonardo Uribe
> >>>>>>>> <lu4242 at gmail.com>
> >>>>>>>> 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20101029/0a4fc1ff/attachment-0002.html