On Thu, Feb 4, 2010 at 6:16 PM, Andy Schwartz <andy.schwartz(a)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