<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/29/10 11:06 PM, David Geary wrote:<br>
<blockquote
cite="mid:AANLkTimj3TV-yHYXcs7tpCPh+LfZn9OYjRGEvdrwyNS-@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<meta charset="utf-8">
<div>It seems that I am perhaps the only dissenting voice here, but I
don't care for this solution. </div>
<div><br>
</div>
<div>To those of us that understand the rationale for removing
targets and adding these cc:implements... tags, the new tags make
perfect sense. But to the uninitiated, they will be bewildering. What
does it mean for a button to "implements action source"? Buttons
already implement action source.</div>
</div>
</blockquote>
<br>
Ed also raised this concern. If we are going to continue on with this
approach (and I hope that we do), perhaps we need to come up with less
ambiguous names for these tags.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTimj3TV-yHYXcs7tpCPh+LfZn9OYjRGEvdrwyNS-@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> IMO, targets are much easier to understand, and to explain.</div>
<div><br>
</div>
<div>I understand the urge to remove the targets attribute based on
their OO impurity,</div>
</div>
</blockquote>
<br>
OO purity may be part of it, though I believe that the a bigger reason
for focusing on this area is that end users (and even EG members) seem
to be having difficulty with our existing APIs.<br>
<br>
<blockquote
cite="mid:AANLkTimj3TV-yHYXcs7tpCPh+LfZn9OYjRGEvdrwyNS-@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> but I think the solution could use some more thought. There are
already too many arcane oddities in JSF, whose rationale is only
intuited by high priests, and I hate to see us adding more.</div>
</div>
</blockquote>
<br>
The "high priest" analogy does not present an especially charitable
view of what is happening here. We released an API in JSF 2.0 that
users are finding problematic. Expert group/community members have
recognized that this is a problem and are attempting to devise a
solution that would be more in line with how our users expect this to
work. Perhaps we are off base in aspects of this solution, but the
fact that we are looking to address a problem area is a good thing. I
don't think it is fair to apply the old high priest/ivory tower motif
here.<br>
<br>
My own take is that a big reason why our end users are having
difficulty with our current solution is that it is internally
inconsistent. In some cases implementation tags refer to interface
metadata (eg. <composite:insertFacet>). In other cases interface
metadata refers to implementation tags (eg.
<composite:actionSource>). In one case, that in retrospect seems
embarrassingly convoluted, we have bi-directional references between
interface and implementation: <composite:attribute>, which
sometimes uses "targets" and other times is referenced via #{cc.attrs}.<br>
<br>
Looking at the tag documentation for the <composite:attribute>
"targets" attribute:<br>
<br>
<blockquote type="cite">If this element has a method-signature
attribute, the value of the
targets attribute must be interpreted as a space (not tab) separated
list of client ids (relative to the top level component) of components
within the <composite:implementation> section. Space is used as
the delimiter for compatibility with the IDREFS and NMTOKENS data types
from the XML Schema. Each entry in the list must be interpreted as the
id of an inner component to which the MethodExpression from the
composite component tag in the using page must be applied. If this
element has a method-signature attribute, but no targets attribute, the
value of the name attribute is used as the single entry in the list. If
the value of the name attribute is not one of the special values listed
in the description of the name attribute, targets (or its derived
value) need not correspond to the id of an inner component.<br>
</blockquote>
<br>
The "name" attribute documentation isn't especially reassuring:<br>
<br>
<blockquote type="cite">The name of the attribute as it must appear on
the composite component tag in the using page. If the value of the name
attribute is equal to (without the quotes) “action”, “actionListener”,
“validator”, or “valueChangeListener”, the action described in
ViewHandler.retargetMethodExpressions() must be taken to handle the
attribute. In these cases, the method-signature attribute, if present,
must be ignored as its value is derived as described in
retargetMethodExpressions().</blockquote>
<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>
I realize that the <composite:attribute> use case is a bit
different from
<composite:actionSource>/<composite:valueHolder>/<composite:editableValueHolder>
cases, so perhaps it would be sufficient to address the
<composite:attribute> insanity and stop there. However, I do
think it is worthwhile to look at the full solution and see whether
there is room for additional simplification/consistency.<br>
<br>
To me, <composite:actionSource> is not all that different from
<composite:facet>. The <composite:facet> API, like
<composite:actionSource>, could have just as easily used a target
approach. Yet we decided to go with this:<br>
<br>
<br>
<blockquote type="cite"><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></blockquote>
<br>
<br>
Instead of:<br>
<br>
<br>
<blockquote type="cite"><composite:interface><br>
<composite:facet name="foo" target="mySomeComp"/><br>
<composite:interface><br>
<br>
<composite:implementation><br>
<bar:someComp id="mySomeComp"/><br>
</composite:implementation></blockquote>
<br>
<br>
<br>
Why did we go with <composite:insertFacet> instead of "target"?
Which approach is easier for users? If we had provided both of these
approaches in 2.0, which would users prefer?<br>
<br>
In my experience I have found our id-referencing APIs to be a difficult
to work with. Id references can be confusing. It isn't always clear
whether relative or full ids should be used or what location relative
ids are relative to. The presence of naming containers influence the
specification of id references in ways that can trip up unsuspecting
users. Id references 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
<composite:facet>/<composite:insertFacet> design. This
solution provides a simple, clear way for the user to express their
intentions without suffering any of the above drawbacks.<br>
<br>
While I admit that the <composite:actionSource> case is not
identical to <composite:facet>, the similarities seem strong. If
JSF 2.0 had included a
<composite:actionSource>/<composite:insert/implements/exposes/whateverActionSource>
pair (like <composite:facet>/<composite:insertFacet>) and
had not included any notion of "targets", I don't think that our users
would have had much difficulty coping with this. If we had exclusively
gone with a "implementation references interface" approach (no
references from interface 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 2.0. It is less important for us to question whether our original
design choices were correct than to decide whether it makes sense to
introduce new APIs now. In my mind, this looks like the proposals that
we have been discussion are a step in the right direction. I like the
consistency of this new approach; it allows users to interact with all
of our interface metadata in a similar manner. I am certainly open to
discussion on this, and I completely agree that we need to be careful
when pondering new APIs. You are right that it is critical that we
avoid unintentionally making life more difficult for our users, not
just in this case, but for all of our API decisions.<br>
<br>
Andy<br>
<br>
</body>
</html>