<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Andy Schwartz wrote:
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Hey Ken -<br>
<br>
Ken Paulsen wrote On 4/13/2009 2:34 AM ET:
<blockquote cite="mid:49E2DCE6.5040305@sun.com" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
<br>
My 2 cents....<br>
<br>
I'd rather see us pick a *standard value* for "a" ("ezcomp",
"compositeComponent" too long??, etc.).</blockquote>
<br>
I would be okay with picking a standard value, though if we do this,
the name should include something to indicate that this refers to an
attribute map and not to the component. So, "attrs" (or something like
that) - not "ezcomp" or "compositeComponent", since this should refer
to the composite component itself.<br>
</blockquote>
Ok, sounds good to me. Maybe compAttrs? (I'm not particularly good at
naming. ;) )<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite"><br>
<blockquote cite="mid:49E2DCE6.5040305@sun.com" type="cite"> This is
less confusing. Less
to worry about in the ezcomp declaration.</blockquote>
<br>
Hmm... Personally I don't find the use of a "var" attribute especially
confusing, though perhaps I am not the typical user. :-) Anyone who
has used c:forEach or h:dataTable is already familiar with this
concept, so there is precedent for this approach in the platform. I
keep thinking about c:forEach and h:dataTable and wondering whether
these tags would have been better if the designers had just said:
"Forget the var and varStatus attributes - let's just spec 'item' and
'status' implicit variables." Personally I don't think this would have
been an improvement.<br>
</blockquote>
Agreed... but if you have nested loops, that model falls apart. I
don't think we have that problem re: nested composite components
(assuming scoping is done correctly -- it should).<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite"><br>
BTW, we've been using the "var" approach for the ADF Faces page
template component for years. I don't remember our clients ever
raising this as a point of confusion. Actually, if composite component
authors do find this confusing, they can of course always stick with
good old compositeComponent.attrs.<br>
</blockquote>
If we go that route, why not alias any other variable that way? I'd
like to see a general mechanism, not a one-off impl for areas we deem
to be special.<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite"><br>
<blockquote cite="mid:49E2DCE6.5040305@sun.com" type="cite"> Page
author won't have to
worry about the EZComp author masking their values.</blockquote>
<br>
Unless I am missing something here, the same is true if we go with a
"var" approach.<br>
</blockquote>
<br>
I think you mean "without" the var approach? The difference is the
page author can expect what the reserved word will be vs. every
component being different.<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite"><br>
<blockquote cite="mid:49E2DCE6.5040305@sun.com" type="cite"> And if
scoping is
done correctly, this value won't exist automatically outside the
component which consumes it... so there's no name-space collision issue
here.<br>
</blockquote>
<br>
I don't think we have namespace collision problems if we allow the
composite component author to define their own attribute var name.<br>
</blockquote>
Agreed, and I don't think it is a problem if every composite component
uses "X". This value should only be meaningful while processing that
composite component.<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite"><br>
<blockquote cite="mid:49E2DCE6.5040305@sun.com" type="cite"><br>
If a mapping *is* desired to make it shorter in later references, I'd
suggest solving it more generically. For example, in JSFTemplating an
event handler can set a request attribute:<br>
<br>
<tt><event type="beforeCreate"><br>
setAttribute(key="a" value="#{compositeComponent.attributes}");<br>
</event></tt><br>
<br>
The above is not a proposal. I am trying to point out that there are
more generic easy solutions for this. I don't like the complexity
involved in a dynamic variable name -- it'll just confuse people. Keep
it simple.<br>
</blockquote>
<br>
To me the "var" approach seems much simpler than, say, requiring the
composite component author to manually move the attributes map to a
request-scoped variable. Also, a solution where we shove the
attributes map into some other scope (eg. request scope) has the
downside of raising the name collision problem again, since now we need
to compete with managed beans names that occupy that scope.<br>
</blockquote>
The above was not a suggested syntax, it's just one that works today.
If I had to pick a syntax on the fly, perhaps:<br>
<br>
<f:alias var="foo" target="#{some.el}" /><br>
<br>
We could then make the "alias" scope it's own scope to avoid EL
collisions, but masking will still be a problem (EL is poor that way
unless you always are explicit... i.e: #{alias.foo} vs. #{foo}).<br>
<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite">I guess
the bottom line is that I can live with picking a standard
name, but the "var" approach seems more elegant to me, and not
especially confusing/complex, since this approach should already be
familiar to JSTL/JSF users. I can also live with not doing anything of
course, though it would be nice to provide a more concise syntax so
that composite component authors can tighten up their implementations.<br>
</blockquote>
I'm for it if its generalized (i.e. <f:alias /> type of
solution)), I don't see the rationale for making a special case here.<br>
<br>
Thanks!<br>
<br>
Ken<br>
<blockquote cite="mid:49E34D31.7060007@oracle.com" type="cite"><br>
Andy<br>
<br>
</blockquote>
</body>
</html>