[jsr-314-open] cc.parent mystery

[Cay Horstmann]

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 at horstmann.com