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

[Andy Schwartz]

Dan Allen wrote On 4/8/2009 1:59 PM ET:
> In general I agree with Ken. I have been able to measure considerable 
> performance degradation from not qualifying any EL expression. 
> However, in this particular case, Facelets always checks its own 
> context first before it even delegates to an EL resolver (since it has 
> control over the template and hence the initial EL lookup.

Though if the attribute in question isn't actually set by the user of 
the composite component, then we won't find the attribute in the 
component's attribute map, which presumably means that we end up going 
through normal EL/managed bean resolving, which gets us back to the 
performance hit.

>
> While the performance argument doesn't really apply here, there is 
> another problem. The Facelets vars shadow all other EL attributes, so 
> the more attributes you have the more likely that will happen. For 
> instance, say you have an attribute named "view" and in the 
> implementation you were trying to use the implicit object "view". Now 
> you have a problem.

Right.  For me the potential for collision between attribute names and 
other named objects (eg. implicit objects, managed beans) is the more 
serious issue.  I prefer a solution where the composite component 
attributes are partitioned off into their own name space.  However, I 
completely agree with David's point that "compositeComponent.attrs" is 
annoyingly verbose.  As I've mentioned when this has come up in the 
past, my preferred solution would be to give the composite component 
author the ability to define their own name/alias for 
"compositeComponent.attrs" object (similar to the h:dataTable "var" 
attribute).  So, something like:

  <composite:implementation attributesVar="a">
    <h:graphicImage style="border: none" value="#{a.image}"/>
  </composite:implementation>

Andy