Re: [jsr-314-open] #{compositeComponent.attrs....}
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