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