[jsr-314-open] #{compositeComponent.attrs....}
Andy Schwartz
andy.schwartz at ORACLE.COM
Mon Apr 13 10:33:21 EDT 2009
Hey Ken -
Ken Paulsen wrote On 4/13/2009 2:34 AM ET:
>
> My 2 cents....
>
> I'd rather see us pick a *standard value* for "a" ("ezcomp",
> "compositeComponent" too long??, etc.).
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.
> This is less confusing. Less to worry about in the ezcomp declaration.
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.
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.
> Page author won't have to worry about the EZComp author masking
> their values.
Unless I am missing something here, the same is true if we go with a
"var" approach.
> 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.
I don't think we have namespace collision problems if we allow the
composite component author to define their own attribute var name.
>
> 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:
>
> <event type="beforeCreate">
> setAttribute(key="a" value="#{compositeComponent.attributes}");
> </event>
>
> 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.
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.
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.
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090413/450ceb10/attachment.html
More information about the jsr-314-open-mirror
mailing list