Re: [jsr-314-open] cc.parent mystery
On 02/04/2010 08:52 AM, Andy Schwartz wrote:
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.
+1.
Do you guys have use cases where EL access to the ancestor composite
component (as opposed to the immediate parent component) is required?
No.
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.
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. Ryan Lubke just fixed the bug that I
noticed--see
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1529.
There is no sense in keeping cc.parent around--it is just as fragile as
the original definition of cc.
Consider David Geary's developerWorks example where he has a "map"
component inside a "place" component and calls cc.parent.location in the
map implementation. If anyone ever modifies any of the components in the
tree path between the place and the map, reimplementing them as a
composite component, then stuff breaks.
The upcoming spec maintenance is probably your last chance to remove
this, before people start using it in their code. In hindsight, I
shouldn't have filed a bug report--people won't use what doesn't work.
Cheers,
Cay
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com