[jsr-314-open] cc.parent mystery

[Ed Burns]

>>>>> On Thu, 04 Feb 2010 11:00:31 -0500, David Geary <clarity.training at gmail.com> said:

DG> Does anyone know whether cc.parent is supposed to work for composite
DG> components? 

It absolutely should work.

>>>>> On Thu, 04 Feb 2010 11:52:17 -0500, Andy Schwartz <andy.schwartz at oracle.com> said:

AS> I can't remember what our resolution was on this issue. My concern was 
AS> that #{cc.parent} should not be given any special/non-obvious meaning. 
AS> #{cc} resolves to the composite component instance, which is a 
AS> UIComponent. Dereferencing the "parent" property on a UIComponent, 
AS> whether accessed via #{cc.parent}, "#{component.parent} or any other 
AS> expression that resolves to a UIComponent, should do the 
AS> obvious/consistent thing and actually call UIComponent.getParent(). 

This is correct.  But you must bear in mind that it is the parent of the
*current* composite component. This gets complicated when nesting
composite components.  Just remember that it's the parent relative to
the <cc:implementation> section of the xhtml page in which the #{cc}
expression appears.

AS> Okay, this seems like an oversight to me.  I have logged the following 
AS> issue to request that we remove this from the spec:

AS> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=741

AS> Any objections to making this change in the MR?

I'm not sure about removing this statement.  The section you quote is
for the special composite component ELResolver, the thing that makes the
#{cc.attrs} magic work.  If we remove this statement, then the
following, currently supported, code will cease to work.

I have removed the corresponding code in my local workarea and am
currently re-running the automated tests.  

Index: jsf-ri/src/com/sun/faces/el/CompositeComponentAttributesELResolver.java
===================================================================
--- jsf-ri/src/com/sun/faces/el/CompositeComponentAttributesELResolver.java	(revision 8307)
+++ jsf-ri/src/com/sun/faces/el/CompositeComponentAttributesELResolver.java	(working copy)
 -131,23 +131,6 @@
                 return getEvalMapFor(c, ctx);
             }
 
-            if (COMPOSITE_COMPONENT_PARENT_NAME.equals(propertyName)) {
-                UIComponent c = (UIComponent) base;
-                context.setPropertyResolved(true);
-                FacesContext ctx = (FacesContext)
-                      context.getContext(FacesContext.class);
-                CompositeComponentStackManager m =
-                      CompositeComponentStackManager.getManager(ctx);
-                UIComponent ccp = m.getParentCompositeComponent(TreeCreation,
-                                                                ctx,
-                                                                c);
-                if (ccp == null) {
-                    ccp = m.getParentCompositeComponent(Evaluation,
-                                                        ctx,
-                                                        c);
-                }
-                return ccp;
-            }
         }
 
         return null;

I will share the scenarios in which the tests fail and we can discuss if
they are valid or not.  However, I feel that since these scenarios work
in the current spec, it is unacceptable simply to make them not work any
more.

Ed


-- 
| ed.burns at sun.com  | office: 408 884 9519 OR x31640
| homepage:         | http://ridingthecrest.com/