10:52 a.m.
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@gmail.com>>
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/indexhtml).
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>