[jsr-314-open] cc.parent mystery

[Dan Allen]

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/20100204/fe725804/attachment.html