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.2010/2/2 David Geary <clarity.training@gmail.com <mailto:clarity.training@gmail.com>> <mailto:cay@horstmann.com>>
It used to work with Mojarra 2.0, but it no longer works with Mojara 2.0.2.
david
mailto:cay@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 |