On Tue, 2009-09-15 at 18:34 -0400, Andy Schwartz wrote:
I feel that
the current behavior violates the principle of least surprise (both
Lincoln and I were surprised) and also breaks encapsulation (ie.
introduces implementation-specific dependencies).
Andy, I agree.
+1
In every other EL situation, values are rooted in the context within
which they were defined. I didn't give it too much thought at first, but
this would definitely be counter-intuitive.
This is probably stating the obvious, but I don't want to forget about
use case #4: passing as an attribute should also behave the same way
(see inline.)
<composite:implementation>
<!-- 1. Expression directly in the implementation -->
<h:outputText value="#{cc.attrs.value}">
<!-- 2. Expression in non-composite component facet -->
<bar:someJavaComposite>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</bar:someJavaComponent>
<!-- 3. Expression in composite component facet -->
<foo:someCompositeComponent>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</foo:someCompositeComponent>
<!-- 4. Expression in composite component attribute -->
<bar:someCompositeComponent value="#{cc.attrs.value}" />
</composite:implementation>
It boggles my mind thinking about how to go about implementing this, but
it needs to happen in order to, as Andy said, "adhere to the principle
of least surprise".
--Lincoln
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF