Re: [jsr-314-open] cc.parent mystery

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