Hi
I have been thinking about this and it seems the missing part has to
be with UIComponent.findComponent(String expr).
In theory, findComponent allow us to find a "real" component instance
using a expression, but when the component is inside a datatable or
other "iteration" component, the state is bound in some way with the
generated clientId, which can only be found when the call is put in
context, that means "we are in a valid row".
But there is no method to get a findComponent expression based on a
component instance (getFindComponentExpression), or a way to traverse
the component tree just like with invokeOnComponent or visitTree, but
passing a "find component expression" as param, instead the clientId.
Maybe it is possible to create a custom VisitContext based on "find
component expression", but I have not checked it yet.
Also there is no method to start a findComponent search but only try
to locate child or facets inside an specific node (for example
UIComponent findComponentChildOrFacetFrom(FacesContext facesContext,
UIComponent parent, String expr) ).
In practice, I have found some use cases where those methods are useful:
https://issues.apache.org/jira/browse/MYFACES-3289 Allow f:event
listener="#{cc.preRenderViewCallback}" work
https://issues.apache.org/jira/browse/MYFACES-3287 h:outputStylesheet
and h:outputScript with inner markup and references to #{cc} cannot
found the parent component.
https://issues.apache.org/jira/browse/MYFACES-3281 cc:attribute
"targets" and cc attached object "targets" should follow strictly the
spec
I think it is possible to prevent this problem, doing some
implementation specific tweaks, but from the user point of view, only
an alternative like a visitTree receiving a findComponent expression
is reasonable. It could be good to find some use cases where this
improvement is useful, to support its addition to the spec.
regards,
Leonardo Uribe
2011/8/17 Kito Mann <kito.mann_at_virtua.com>:
> Hello everyone,
>
> I just ran into an issue where #{cc.attrs.property} expressions don't work
> when referenced via properties of child components if they're not referenced
> inside of a tree traversal. More information here:
> https://issues.apache.org/jira/browse/MYFACES-3283 (happens in both MyFaces
> and Mojarra).
>
> Section 5.6.2.1 (Implicit Object ELResolver for Facelets and Programmatic
> Access) of the spec states the following:
>
> cc -> the current composite component relative to
> the declaring page in which the expression appears.
>
> Since "current composite component" usually means the current composite
> being processed during a tree traversal, "cc" can return null when it's
> referenced elsewhere (i.e. in an action listener);.
>
> I'm thinking that the "cc" implicit variable should return the parent
> composite component in cases where no "current composite component" is
> available.
>
> Thoughts?
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
> jsfcentral
> +1 203-404-4848 x3
>
> * Listen to the latest headlines in the JSF and Java EE
> newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> * Keep up with the aftermath of the Oracle/Sun merger:
> http://www.mergerspeak.com
>
>