<div>2010/10/30 Jakob Korherr <span dir="ltr"><<a href="mailto:jakob.korherr@gmail.com">jakob.korherr@gmail.com</a>></span></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
Andy, I totally agree with you in all points mentioned in your<br>
previous mail (actually this just made my day).</blockquote><div><br></div><div>So do I. Perhaps I wasn't clear, but I agree that the problems outlined by Andy need to be addressed. I also understand, and agree with, the fact that targets is an OO misdemeanor, with an interface depending upon implementation details.</div>
<div><br></div><div>I'm just not crazy about the proposed solution. Consider the following example from earlier in this thread:</div><div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><composite:interface></span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "> <composite:actionSource name="loginButton"/><div class="im" style="color: rgb(80, 0, 80); ">
</composite:interface><br><br> <composite:implementation><br> <h:commandButton><br></div> <composite:implementsActionSource name="loginButton"/><br> </h:commandButton><br> </composite:implementation></span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; "><div>
In the preceding markup, the button doesn't implement the named action source, as advertised, because the action source is not an action source at all, but rather a reference to one -- and it's the action source that the button already implements! That bit of circular illogic hurts my head. It's also a lot of typing.</div>
<div><br></div><div>And then there's the problem of using the same attribute name ("name") for two different things in two closely related tags. At the very least, shouldn't the "name" attribute of <composite:implementsActionSource> be something else, maybe "source", for example?</div>
</span></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Also, if we're going to use "implements", why must we have separate tags for each type of source? Why not just <composite:implements name="loginButton"/>? Or perhaps something more semantically correct:</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><composite:interface></span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; "><div>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "> <composite:actionSource name="loginButton"/><div class="im" style="color: rgb(80, 0, 80); ">
</composite:interface><br><br> <composite:implementation><br> <h:commandButton><br></div><div class="im" style="color: rgb(80, 0, 80); "><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: arial; font-size: small; "><div>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "> <b><composite:references source="loginButton" </b>(or perhaps refersTo instead of references)</span></div>
</span></div> </h:commandButton><br> </composite:implementation></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div>
</span></span></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Is it just possible to do this with component ids, and forgo the extra tag altogether?</span></font></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; "><div>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><composite:interface></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; "><div>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "> <composite:actionSource name="loginButton"/><div class="im" style="color: rgb(80, 0, 80); ">
</composite:interface><br><br> <composite:implementation><br> <h:commandButton id="loginButton"></div> </h:commandButton><br> </composite:implementation></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br>
</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Finally, perhaps I missed this in the thread, but does this solution let a composite component author bind multiple targets (sorry) to a single source?</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Again, I agree with the problems that Andy so eloquently described. I'd just like to see us take a little more time to think through the solution.</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br>
</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">david</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br>
</span></div></span></span></div></span></span></font></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> And I most liked the<br>
following paragraph:<br>
<div class="im"><br>
>Seriously?? After reading this, is it any wonder that our users are flailing on this? If anything in this very extended email discussion reeks of arcane high priestdom-ness, this is it. Wouldn't life have been simpler for our users if <composite:attribute> had no "targets" attribute whatsoever, no special-casing for the "name" attribute and instead we simply boiled this down to: "use #{cc.attrs} for everything"?<br>
<br>
</div>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>
<div><div></div><div class="h5">> 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 care<br>
> for this solution.<br>
> To those of us that understand the rationale for removing targets and 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 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 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 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 that<br>
> this is a problem and are attempting to devise a solution that would be more<br>
> in line with how our users expect this to work. Perhaps we are off base 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 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 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 targets<br>
> attribute must be interpreted as a space (not tab) separated list of 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 Schema.<br>
> Each entry in the list must be interpreted as the id of an inner component<br>
> to which the MethodExpression from the composite component tag in the using<br>
> page must be applied. If this element has a method-signature attribute, but<br>
> no targets attribute, the value of the name attribute is used as the 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 (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 tag<br>
> in the using page. If the value of the name attribute is equal to (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, 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 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>
> I realize that the <composite:attribute> use case is a bit different from<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 is<br>
> worthwhile to look at the full solution and see whether there is room 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 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 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 to<br>
> work with. Id references can be confusing. It isn't always clear 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 specification<br>
> of id references in ways that can trip up unsuspecting users. Id 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 provides a<br>
> simple, clear way for the user to express their intentions without 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 included a<br>
> <composite:actionSource>/<composite:insert/implements/exposes/whateverActionSource><br>
> pair (like <composite:facet>/<composite:insertFacet>) and had not included<br>
> any notion of "targets", I don't think that our users would have had much<br>
> difficulty coping with this. If we had exclusively gone with a<br>
> "implementation references interface" approach (no references from interface<br>
> to implementation), I think our users would have been altogether better 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 design<br>
> choices were correct than to decide whether it makes sense to introduce 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 this,<br>
> and I completely agree that we need to be careful when pondering new APIs.<br>
> You are right that it is critical that we avoid unintentionally making life<br>
> more difficult for our users, not just in this case, but for all of our API<br>
> decisions.<br>
><br>
> Andy<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>