Hi Jakob<br><br>I checked the patch and is not possible to add a method to an interface<br>(addTarget on javax.faces.view.AttachedObjectTarget). In that case it is<br>better to let that as an implementation detail.<br><br>
I think in this case (note this is my personal opinion) it is necessary <br>to take a different route than "reuse" the algorithm for <br>vdl.retargetAttachedObjects. In theory, every tag that<br>expose an attached object when is inside a composite component<br>
(ex: f:actionListener), register it in a implementation specific list to be<br>used later by vdl.retargetAttachedObjects. I was thinking on just use<br>another list that will be used by these tags, but in this case take into<br>
account how facelets algorithm is executed and affect it properly when<br>the proposed tags are executed.<br><br>regards,<br><br>Leonardo Uribe<br><br><div class="gmail_quote">2010/11/1 Jakob Korherr <span dir="ltr"><<a href="mailto:jakob.korherr@gmail.com">jakob.korherr@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi guys,<br>
<br>
I added a prototype patch for this problem to the spec issue at [1].<br>
<br>
The patch adds the following tags:<br>
<br>
- cc:implementsActionSource<br>
- cc:implementsEditableValueHolder<br>
- cc:implementsValueHolder<br>
- cc:insertClientBehavior<br>
<br>
In addition, the patch contains a systest for cc:implementsActionSource and<br>
cc:implementsEditableValueHolder.<br>
<br>
Everything works great and it really felt good writing the tests with these new<br>
tags.<br>
<br>
One thing did not work though: f:ajax. It seems that it has some hack for<br>
composite components which uses the targets attribute of cc:clientBehavior. Did<br>
not jump into deep here, but "normal" client behaviors are working.<br>
<br>
@David: OK, sorry I misunderstood your mail. Please take a look at the<br>
patch and also the usage examples in the systest. IMHO "implements"<br>
(or "insert" in the case of clientBehavior) fits really, really well<br>
here, because it tells us that the surrounding button implements the<br>
action source with the name XXX of the composite component. And yes,<br>
multiple action source implementations are possible. However we most<br>
certainly can discuss this ;)<br>
<br>
Frankly, it would be very, very great to have this in JSF 2.1.<br>
<br>
Regards,<br>
Jakob<br>
<br>
[1] <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=901" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=901</a><br>
<br>
2010/10/31 David Geary <<a href="mailto:clarity.training@gmail.com">clarity.training@gmail.com</a>>:<br>
<div><div></div><div class="h5">> 2010/10/30 Jakob Korherr <<a href="mailto:jakob.korherr@gmail.com">jakob.korherr@gmail.com</a>><br>
>><br>
>> Hi,<br>
>><br>
>> Andy, I totally agree with you in all points mentioned in your<br>
>> previous mail (actually this just made my day).<br>
><br>
> So do I. Perhaps I wasn't clear, but I agree that the problems outlined by<br>
> Andy need to be addressed. I also understand, and agree with, the fact that<br>
> targets is an OO misdemeanor, with an interface depending upon<br>
> implementation details.<br>
> I'm just not crazy about the proposed solution. Consider the following<br>
> example from earlier in this thread:<br>
> <composite:interface><br>
> <composite:actionSource name="loginButton"/><br>
> </composite:interface><br>
><br>
> <composite:implementation><br>
> <h:commandButton><br>
> <composite:implementsActionSource name="loginButton"/><br>
> </h:commandButton><br>
> </composite:implementation><br>
> In the preceding markup, the button doesn't implement the named action<br>
> source, as advertised, because the action source is not an action source at<br>
> all, but rather a reference to one -- and it's the action source that the<br>
> button already implements! That bit of circular illogic hurts my head. It's<br>
> also a lot of typing.<br>
> And then there's the problem of using the same attribute name ("name") for<br>
> two different things in two closely related tags. At the very least,<br>
> shouldn't the "name" attribute of <composite:implementsActionSource> be<br>
> something else, maybe "source", for example?<br>
> Also, if we're going to use "implements", why must we have separate tags for<br>
> each type of source? Why not just <composite:implements<br>
> name="loginButton"/>? Or perhaps something more semantically correct:<br>
> <composite:interface><br>
> <composite:actionSource name="loginButton"/><br>
> </composite:interface><br>
><br>
> <composite:implementation><br>
> <h:commandButton><br>
> <composite:references source="loginButton" (or perhaps refersTo instead<br>
> of references)<br>
> </h:commandButton><br>
> </composite:implementation><br>
> Is it just possible to do this with component ids, and forgo the extra tag<br>
> altogether?<br>
> <composite:interface><br>
> <composite:actionSource name="loginButton"/><br>
> </composite:interface><br>
><br>
> <composite:implementation><br>
> <h:commandButton id="loginButton"><br>
> </h:commandButton><br>
> </composite:implementation><br>
> Finally, perhaps I missed this in the thread, but does this solution let a<br>
> composite component author bind multiple targets (sorry) to a single source?<br>
> Again, I agree with the problems that Andy so eloquently described. I'd just<br>
> like to see us take a little more time to think through the solution.<br>
><br>
> david<br>
><br>
>><br>
>> And I most liked the<br>
>> following paragraph:<br>
>><br>
>> >Seriously?? After reading this, is it any wonder that our users are<br>
>> > flailing on this? If anything in this very extended email discussion reeks<br>
>> > of arcane high priestdom-ness, this is it. Wouldn't life have been simpler<br>
>> > for our users if <composite:attribute> had no "targets" attribute<br>
>> > whatsoever, no special-casing for the "name" attribute and instead we simply<br>
>> > boiled this down to: "use #{cc.attrs} for everything"?<br>
>><br>
>> IMHO: Yes, totally!<br>
>><br>
>> The current solution really is internally inconsistent, and<br>
>> furthermore many developers (and as you mentioned: even EG members)<br>
>> are having trouble with it. I myself implemented a lot of this for<br>
>> MyFaces, but I still have problems when using it without looking at my<br>
>> cheat-sheet...<br>
>><br>
>> And it's not just the inconsistency: the ID-reference approach really<br>
>> is something we should stay away from, because no-one actually knows<br>
>> which ID to use: full clientid? last part of the clientid? what about<br>
>> naming containers? or even worse: what about data tables or<br>
>> <ui:repeat> (because they add an index to the clientId)? Doing a<br>
>> back-reference to the interface section here seems just soooo much<br>
>> better.<br>
>><br>
>> David, although I know you don't really like the OO reference here,<br>
>> but IMO the target approach is even worse than this:<br>
>><br>
>> public interface MyInterface implemented-by Foo, Bar, Bas {}<br>
>><br>
>> ... because even in this scenario you definitely would know the<br>
>> package of Foo, Bar and Bas (or in other words: you would know which<br>
>> client-id to use).<br>
>><br>
>> However, I always know how to insert a facet into a composite<br>
>> component, because this approach is very intuitive. Thus I think the<br>
>> right thing to do is to add those tags for actionSource, valueHolder,<br>
>> editableValueHolder and clientBehavior too and to "get rid" of the<br>
>> targets-solution.<br>
>><br>
>> In the case of actionSource, valueHolder and editableValueHolder I<br>
>> really like "implementsXXX", because it shows that the certain<br>
>> implementation component implements this functionality for/of the<br>
>> composite component. However in the case of clientBehavior, I think we<br>
>> should go with cc:insertClientBehavior, just as we did with<br>
>> cc:insertFacet, because facets and clientBehaviors are somehow related<br>
>> here..<br>
>><br>
>> To wrap this up again, I'd propose to add these tags for JSF 2.1 in<br>
>> order to make the life of our users a lot easier:<br>
>><br>
>> <cc:implementsActionSource name="XXX" /><br>
>> <cc:implementsEditableValueHolder name="XXX" /><br>
>> <cc:implementsValueHolder name="XXX" /><br>
>> <cc:insertClientBehavior name="XXX" /><br>
>><br>
>> Regards,<br>
>> Jakob<br>
>><br>
>><br>
>><br>
>> 2010/10/30 Andy Schwartz <<a href="mailto:andy.schwartz@oracle.com">andy.schwartz@oracle.com</a>>:<br>
>> > On 10/29/10 11:06 PM, David Geary wrote:<br>
>> ><br>
>> > It seems that I am perhaps the only dissenting voice here, but I don't<br>
>> > care<br>
>> > for this solution.<br>
>> > To those of us that understand the rationale for removing targets and<br>
>> > adding<br>
>> > these cc:implements... tags, the new tags make perfect sense. But to the<br>
>> > uninitiated, they will be bewildering. What does it mean for a button to<br>
>> > "implements action source"? Buttons already implement action source.<br>
>> ><br>
>> > Ed also raised this concern. If we are going to continue on with this<br>
>> > approach (and I hope that we do), perhaps we need to come up with less<br>
>> > ambiguous names for these tags.<br>
>> ><br>
>> ><br>
>> > IMO, targets are much easier to understand, and to explain.<br>
>> > I understand the urge to remove the targets attribute based on their OO<br>
>> > impurity,<br>
>> ><br>
>> > OO purity may be part of it, though I believe that the a bigger reason<br>
>> > for<br>
>> > focusing on this area is that end users (and even EG members) seem to be<br>
>> > having difficulty with our existing APIs.<br>
>> ><br>
>> > but I think the solution could use some more thought. There are already<br>
>> > too<br>
>> > many arcane oddities in JSF, whose rationale is only intuited by high<br>
>> > priests, and I hate to see us adding more.<br>
>> ><br>
>> > The "high priest" analogy does not present an especially charitable view<br>
>> > of<br>
>> > what is happening here. We released an API in JSF 2.0 that users are<br>
>> > finding problematic. Expert group/community members have recognized<br>
>> > that<br>
>> > this is a problem and are attempting to devise a solution that would be<br>
>> > more<br>
>> > in line with how our users expect this to work. Perhaps we are off base<br>
>> > in<br>
>> > aspects of this solution, but the fact that we are looking to address a<br>
>> > problem area is a good thing. I don't think it is fair to apply the old<br>
>> > high priest/ivory tower motif here.<br>
>> ><br>
>> > My own take is that a big reason why our end users are having difficulty<br>
>> > with our current solution is that it is internally inconsistent. In<br>
>> > some<br>
>> > cases implementation tags refer to interface metadata (eg.<br>
>> > <composite:insertFacet>). In other cases interface metadata refers to<br>
>> > implementation tags (eg. <composite:actionSource>). In one case, that<br>
>> > in<br>
>> > retrospect seems embarrassingly convoluted, we have bi-directional<br>
>> > references between interface and implementation: <composite:attribute>,<br>
>> > which sometimes uses "targets" and other times is referenced via<br>
>> > #{cc.attrs}.<br>
>> ><br>
>> > Looking at the tag documentation for the <composite:attribute> "targets"<br>
>> > attribute:<br>
>> ><br>
>> > If this element has a method-signature attribute, the value of the<br>
>> > targets<br>
>> > attribute must be interpreted as a space (not tab) separated list of<br>
>> > client<br>
>> > ids (relative to the top level component) of components within the<br>
>> > <composite:implementation> section. Space is used as the delimiter for<br>
>> > compatibility with the IDREFS and NMTOKENS data types from the XML<br>
>> > Schema.<br>
>> > Each entry in the list must be interpreted as the id of an inner<br>
>> > component<br>
>> > to which the MethodExpression from the composite component tag in the<br>
>> > using<br>
>> > page must be applied. If this element has a method-signature attribute,<br>
>> > but<br>
>> > no targets attribute, the value of the name attribute is used as the<br>
>> > single<br>
>> > entry in the list. If the value of the name attribute is not one of the<br>
>> > special values listed in the description of the name attribute, targets<br>
>> > (or<br>
>> > its derived value) need not correspond to the id of an inner component.<br>
>> ><br>
>> > The "name" attribute documentation isn't especially reassuring:<br>
>> ><br>
>> > The name of the attribute as it must appear on the composite component<br>
>> > tag<br>
>> > in the using page. If the value of the name attribute is equal to<br>
>> > (without<br>
>> > the quotes) “action”, “actionListener”, “validator”, or<br>
>> > “valueChangeListener”, the action described in<br>
>> > ViewHandler.retargetMethodExpressions() must be taken to handle the<br>
>> > attribute. In these cases, the method-signature attribute, if present,<br>
>> > must<br>
>> > be ignored as its value is derived as described in<br>
>> > retargetMethodExpressions().<br>
>> ><br>
>> > Seriously?? After reading this, is it any wonder that our users are<br>
>> > flailing on this? If anything in this very extended email discussion<br>
>> > reeks<br>
>> > of arcane high priestdom-ness, this is it. Wouldn't life have been<br>
>> > simpler<br>
>> > for our users if <composite:attribute> had no "targets" attribute<br>
>> > whatsoever, no special-casing for the "name" attribute and instead we<br>
>> > simply<br>
>> > boiled this down to: "use #{cc.attrs} for everything"?<br>
>> ><br>
>> > I realize that the <composite:attribute> use case is a bit different<br>
>> > from<br>
>> ><br>
>> > <composite:actionSource>/<composite:valueHolder>/<composite:editableValueHolder><br>
>> > cases, so perhaps it would be sufficient to address the<br>
>> > <composite:attribute> insanity and stop there. However, I do think it<br>
>> > is<br>
>> > worthwhile to look at the full solution and see whether there is room<br>
>> > for<br>
>> > additional simplification/consistency.<br>
>> ><br>
>> > To me, <composite:actionSource> is not all that different from<br>
>> > <composite:facet>. The <composite:facet> API, like<br>
>> > <composite:actionSource>, could have just as easily used a target<br>
>> > approach.<br>
>> > Yet we decided to go with this:<br>
>> ><br>
>> ><br>
>> > <composite:interface><br>
>> > <composite:facet name="foo"/><br>
>> > <composite:interface><br>
>> ><br>
>> > <composite:implementation><br>
>> > <bar:someComp><br>
>> > <composite:insertFacet name="foo"/><br>
>> > </bar:someComp><br>
>> > </composite:implementation><br>
>> ><br>
>> > Instead of:<br>
>> ><br>
>> ><br>
>> > <composite:interface><br>
>> > <composite:facet name="foo" target="mySomeComp"/><br>
>> > <composite:interface><br>
>> ><br>
>> > <composite:implementation><br>
>> > <bar:someComp id="mySomeComp"/><br>
>> > </composite:implementation><br>
>> ><br>
>> ><br>
>> > Why did we go with <composite:insertFacet> instead of "target"? Which<br>
>> > approach is easier for users? If we had provided both of these<br>
>> > approaches<br>
>> > in 2.0, which would users prefer?<br>
>> ><br>
>> > In my experience I have found our id-referencing APIs to be a difficult<br>
>> > to<br>
>> > work with. Id references can be confusing. It isn't always clear<br>
>> > whether<br>
>> > relative or full ids should be used or what location relative ids are<br>
>> > relative to. The presence of naming containers influence the<br>
>> > specification<br>
>> > of id references in ways that can trip up unsuspecting users. Id<br>
>> > references<br>
>> > are fragile and can easily go stale when refactoring content.<br>
>> ><br>
>> > I believe that we had the right idea when we went with the<br>
>> > <composite:facet>/<composite:insertFacet> design. This solution<br>
>> > provides a<br>
>> > simple, clear way for the user to express their intentions without<br>
>> > suffering<br>
>> > any of the above drawbacks.<br>
>> ><br>
>> > While I admit that the <composite:actionSource> case is not identical to<br>
>> > <composite:facet>, the similarities seem strong. If JSF 2.0 had<br>
>> > included a<br>
>> ><br>
>> > <composite:actionSource>/<composite:insert/implements/exposes/whateverActionSource><br>
>> > pair (like <composite:facet>/<composite:insertFacet>) and had not<br>
>> > included<br>
>> > any notion of "targets", I don't think that our users would have had<br>
>> > much<br>
>> > difficulty coping with this. If we had exclusively gone with a<br>
>> > "implementation references interface" approach (no references from<br>
>> > interface<br>
>> > to implementation), I think our users would have been altogether better<br>
>> > off.<br>
>> ><br>
>> > Of course, we cannot go back and time and undo what we've started in JSF<br>
>> > 2.0. It is less important for us to question whether our original<br>
>> > design<br>
>> > choices were correct than to decide whether it makes sense to introduce<br>
>> > new<br>
>> > APIs now. In my mind, this looks like the proposals that we have been<br>
>> > discussion are a step in the right direction. I like the consistency of<br>
>> > this new approach; it allows users to interact with all of our interface<br>
>> > metadata in a similar manner. I am certainly open to discussion on<br>
>> > this,<br>
>> > and I completely agree that we need to be careful when pondering new<br>
>> > APIs.<br>
>> > You are right that it is critical that we avoid unintentionally making<br>
>> > life<br>
>> > more difficult for our users, not just in this case, but for all of our<br>
>> > API<br>
>> > decisions.<br>
>> ><br>
>> > Andy<br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jakob Korherr<br>
>><br>
>> blog: <a href="http://www.jakobk.com" target="_blank">http://www.jakobk.com</a><br>
>> twitter: <a href="http://twitter.com/jakobkorherr" target="_blank">http://twitter.com/jakobkorherr</a><br>
>> work: <a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Jakob Korherr<br>
<br>
blog: <a href="http://www.jakobk.com" target="_blank">http://www.jakobk.com</a><br>
twitter: <a href="http://twitter.com/jakobkorherr" target="_blank">http://twitter.com/jakobkorherr</a><br>
work: <a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
</div></div></blockquote></div><br>