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

[Andy Schwartz]

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:
> On 9/7/09 6:06 PM, Andy Schwartz wrote:
>> Thanks Lincoln.  I haven't had time to debug this, but I have a 
>> theory about what might be happening.  In your sample:
>>
>>> <a:editText value="#{cc.attrs.task.text}" 
>>> rendered="#{!cc.attrs.disabled}">
>>> *<f:actionListener for="submit" 
>>> action="#{taskController.saveTaskAjax(cc.attrs.story, 
>>> cc.attrs.task)}" /> *
>>> </a:editText>
>>
>> We expect "cc" to resolve to the containing composite component (ie. 
>> to the <socialpm:taskBlock> component).  I wouldn't be surprised if 
>> what is actually happening is that "cc" is  being resolved to the 
>> <a:editText> composite component instead.
> Yep, that's what is happening.
>> One reason why I suspect this might be happening is that I know that 
>> Ryan has investigated/resolved similar problems not too long ago.
> The problem we resolved was the passing of #{cc.attrs} attributes 
> between nested composite components.
> For this case, the spec recommends using cc.parent.attrs.story and 
> cc.parent.attrs.task, where parent resolves
> to the nearest composite component parent of the current composite 
> component.

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