[jsr-314-open] #{compositeComponent.attrs....}

[Andy Schwartz]

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