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

Ryan, All - Breaking this topic off into a separate thread, though I am impressed with the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-) Ryan Lubke wrote: I am concerned about this behavior. It isn't clear to me whether the spec is explicit about this behavior, or whether this is something that happens to fall out of the implementation. Either way, the current behavior seems counterintuitive to me, and, well... wrong. My feeling is that when a composite component author uses a #{cc} expression in a composite component implementation, eg: <composite:implementation> <h:outputText value="#{cc.attrs.value}"> </composite:implementation> The correct behavior (the behavior expected by the composite component author) is to resolve the #{cc} expression relative to where the expression is defined - not relative to where it happens to end up in the component tree. So, for example, I believe that these three uses of the #{cc.attrs.value} expression should all evaluate to the same value: <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> </composite:implementation> The fact that the #{cc.attrs.value} expression evaluates the same in cases #1 and #2 but not in case #3 is non-obvious and is going to be confusing for our users. The fact that Lincoln and I were confused about this is a good indication that others will be as well. I am not happy with the work around of using #cc.parent.attrs, since this means that: 1. The user must recognize that the component in question is a composite component and code the expression differently. While at the moment it is fairly easy to determine whether a particular component is a composite or not (by looking at the namespace declaration), I think that we should strive to blur these lines rather than reinforce them. For example, I would like to see the ability to define a single tag library that consists of both composite and non-composite components, making the choice of component implementation more transparent to the user. 2. Once the user has coded the expression in a composite component-specific way, this introduces a dependency on the fact that the component in question is a composite component - a dependency that shouldn't be necessary for this particular case. Such dependencies inhibit flexibility. If in the future the provider of the composite component decides to switch to a Java-based component, this will break any code (or EL expression) that assumes that the component is a composite. We should keep such dependencies to a minimum. 3. This also introduces a subtle dependency on the composite component's implementation. What if the composite component implementation passes the expression along to yet another nested composite component? Does the user now need to specify an expression that pops out multiple levels of parents? While it is certainly trickier to deal with from an implementation perspective, I believe that it is very important that we re-consider the current behavior and consider spec'ing that #{cc} expressions always resolve relative to the context in which they are defined. 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). Leaving aside questions of how we might implement my preferred behavior for the moment... Does anyone have comments on which behavior makes sense from a spec/end user perspective? Andy