[jsr-314-open] cc.parent mystery

[David Geary]

I'm in favor of removing it, now that I have the big picture, even though it
makes my article somewhat obsolete. Thanks for the thorough explanation,
Cay.


david

2010/2/4 Dan Allen <dan.j.allen at gmail.com>

> On Thu, Feb 4, 2010 at 6:16 PM, Andy Schwartz <andy.schwartz at oracle.com>wrote:
>
>> Cay Horstmann wrote:
>>
>>> Originally, cc meant "the current composite component" as opposed to "the
>>> composite component in this implementation section. For example, consider a
>>> login component
>>>
>>>  <composite:implementation>
>>>   <util:labeledInputField label="Username" value="#{cc.attrs.name}"/>
>>>   <util:labeledInputField label="Password" value="#{cc.attrs.password}"/>
>>>  </composite:implementation>
>>>
>>> Way back when, this wouldn't have worked IF util:labeledInputField was a
>>> composite component as well. In that case, cc would have been the
>>> labeledInputField, and it would have been necessary to use #{
>>> cc.parent.attrs.name} to get the login component's name attribute.
>>>
>>> That was fragile. It required the implementor to know which components
>>> are composite. Stuff would break if you changed the implementation of a
>>> utility component--e.g. from a regular util:labeledInputField to a composite
>>> one or the other way around.
>>>
>>> The EG then changed the definition of cc,
>>>
>>
>> I am really glad that we changed this. :-)
>>
>>
>>  but apparently nobody remembered to remove the special handling of
>>> cc.parent. It is in the spec and the implementation.
>>>
>>
>> Okay, this seems like an oversight to me.  I have logged the following
>> issue to request that we remove this from the spec:
>>
>>
>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=741
>>
>> Any objections to making this change in the MR?
>>
>> Cay - thanks so much for the detailed explanation.  Finally understand how
>> we ended up with the currently specified behavior!
>
>
> Indeed. Thanks to your careful analysis we can make an informed decision,
> rather than one from the hip.
>
> I pretty much had the same thought about cc.parent when I was reading
> David's article. It looked neat, but struck me as fragile. When the need
> arises to do that type of relative referencing, it probably indicates that
> you need a new aggregate composite component that is responsible for passing
> the information downwards (to nested components).
>
> I'm in favor of removing it based on this reasoning.
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100205/b33f84d2/attachment.html