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