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

[Ryan Lubke]

On 10/8/09 5:51 PM, Martin Marinschek wrote:
> I know I am way late with my post, but I (sure) also agree with Andy.
> Can we take this up as an issue against the implementation, and
> eventually a clarification to the spec?
>
> Ryan, what do you think?
>    
We've made the necessary changes to Mojarra to support Andy's suggestion 
and have
added a line item to the MR change log [1] (see C034).

[1] http://wiki.java.net/bin/view/Projects/Jsf2MR1ChangeLog


> Leonardo, can you do the same in MyFaces?
>
> regards,
>
> Martin
>
> On Thu, Sep 17, 2009 at 6:12 PM, Kito Mann<kito.mann at virtua.com>  wrote:
>    
>> +1
>> ---
>> Kito D. Mann -- Author, JavaServer Faces in Action
>> http://twitter.com/kito99  http://twitter.com/jsfcentral
>> JSF 2 Seminar Oct 6th: http://www.regonline.com/jsf2seminar
>> JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
>> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>> +1 203-404-4848 x3
>>
>>
>> On Tue, Sep 15, 2009 at 6:34 PM, Andy Schwartz<andy.schwartz at oracle.com>
>> wrote:
>>      
>>> 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
>>>
>>>        
>>
>>      
>
>
>    

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