[jsr-314-open] cc.parent mystery

[David Geary]

2010/2/4 Andy Schwartz <andy.schwartz at oracle.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.
>

I agree. It's confusing to redefine "parent" for composites.


> 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}.
>

Yes, agreed.


>
> 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.
>

I would like to leave it, but just change
UIComponent.getCompositeComponentParent() to UIComponent.getParent().


> 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.
>

I can't think of a use case, and I think it's perfectly acceptable to use
UIComponent.getParent() instead of
UIComponent.getCompositeComponentParent().


> Thoughts?
>

I agree that it's either a spec bug, implementation bug, or design flaw. One
way or another, we should come up with a final resolution.


david

>
> 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 at gmail.com <mailto:
>> clarity.training at gmail.com>>
>>
>>
>>
>>
>>    2010/1/29 Cay Horstmann <cay at horstmann.com
>>    <mailto:cay at 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 at horstmann.com <mailto:cay at horstmann.com>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100204/582ccbd8/attachment.html