[jsr-314-open] #{cc} semantics

[Lincoln Baxter, III]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090917/ff0d3102/attachment.html