2010/1/29 Cay Horstmann <cay(a)horstmann.com&gt; I can't get cc.parent to work, and I stared at it for long enough that I am > pretty convinced that it is a bug. ( > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1529) > > What I am wondering in this forum is whether cc.parent is actually > intended to be supported. There was some use case in the olden days, when cc > was dynamically scoped, but around September 15, Andy Schwarz convinced you > all that it should be statically scoped. For all I know, that took away the > raison d'être for cc.parent. > > Or is there another use case? I only found one other example, David > Geary's developerWorks article ( > http://www.ibm.com/developerworks/java/library/j-jsf2fu2/index.html). He > has a map component inside a place component that retrieves the location > from the parent. I am not even sure that's good practice. It doesn't make > the map component reusable, but instead couples it with the parent. > It's true that the example may be a little contrived, but that does not mean there are no use cases for tightly coupling nested components to parent components, just as there are plenty of use cases in OO in general for tight coupling, even though in general, loose coupling is typically preferred. So IMO, cc.parent makes perfect sense. david > Thanks, > > Cay > > -- > > Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com >

David, Cay - I can't remember what our resolution was on this issue. (Fingers cross that the archives will be back in working order soon.) My concern was that #{cc.parent} should not be given any special/non-obvious meaning. #{cc} resolves to the composite component instance, which is a UIComponent. Dereferencing the "parent" property on a UIComponent, whether accessed via #{cc.parent}, "#{component.parent} or any other expression that resolves to a UIComponent, should do the obvious/consistent thing and actually call UIComponent.getParent(). We shouldn't introduce non-obvious behavior by replacing the meaning of the "parent" property to mean something different from what it normally means.

So, my take is that #{cc.parent} should "work", but should return the result of UIComponent.getParent() rather than UIComponent.getCompositeComponentParent(). If there are use cases where we do need to jump up all the way to the nearest ancestor composite component, I am fine with surfacing this, but would prefer to do so via a property other than "parent" - eg. #{cc.compositeParent}.

Of course, this might all be a moot point, since as David mentioned, section 5.6.2.2 currently specifies: If base is non-null, is an instance of UIComponent, is a composite > component, and property is non-null and is equal to the string “parent”, > call the static method UIComponent.getCompositeComponentParent() passing > base as the argument, returning the result. > Personally I would like to remove this sentence from the spec.

David, Cay - Do you guys have use cases where EL access to the ancestor composite component (as opposed to the immediate parent component) is required? I would guess that the need to reach out to an ancestor from a composite would be rare, but that accessing the immediate parent would be more common than accessing the nearest ancestor composite. As such, the fact that our currently specified behavior for #{cc.parent} prevents composite component authors from accessing the actual parent seems like a spec bug, or, at least, a design flaw to me.

Thoughts?

Andy David Geary wrote: > Does anyone know whether cc.parent is supposed to work for composite > components? Section 5.6.2.2 of the spec combined with the javadocs for > UIComponent.getCompositeComponentParent() seems to indicate that it should. > So it's either a spec or implementation bug. Either way, it should be fixed. > > It used to work with Mojarra 2.0, but it no longer works with Mojara > 2.0.2. > > > david > > 2010/2/2 David Geary <clarity.training(a)gmail.com <mailto: > clarity.training(a)gmail.com&gt;&gt; > > > > > 2010/1/29 Cay Horstmann <cay(a)horstmann.com > <mailto:cay@horstmann.com>> > > > I can't get cc.parent to work, and I stared at it for long > enough that I am pretty convinced that it is a bug. > (https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1529) > > What I am wondering in this forum is whether cc.parent is > actually intended to be supported. There was some use case in > the olden days, when cc was dynamically scoped, but around > September 15, Andy Schwarz convinced you all that it should be > statically scoped. For all I know, that took away the raison > d'être for cc.parent. > > Or is there another use case? I only found one other example, > David Geary's developerWorks article > ( > http://www.ibm.com/developerworks/java/library/j-jsf2fu2/index.html). > He has a map component inside a place component that retrieves > the location from the parent. I am not even sure that's good > practice. It doesn't make the map component reusable, but > instead couples it with the parent. > > > It's true that the example may be a little contrived, but that > does not mean there are no use cases for tightly coupling nested > components to parent components, just as there are plenty of use > cases in OO in general for tight coupling, even though in general, > loose coupling is typically preferred. So IMO, cc.parent makes > perfect sense. > > > david > > > Thanks, > > Cay > > -- > Cay S. Horstmann | http://horstmann.com | > mailto:cay@horstmann.com <mailto:cay@horstmann.com> > > > >

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,

but apparently nobody remembered to remove the special handling of cc.parent. It is in the spec and the implementation.

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

On Fri, Feb 5, 2010 at 10:24 AM, David Geary <clarity.training(a)gmail.com&gt;wrote: > I'm in favor of removing it, now that I have the big picture, even though > it makes my article somewhat obsolete. The other way to look at it was that your article served as a lesson ;) Might not have arrived at our conclusion without it ;)

-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