Gang -
I spent the last couple of hours testing out various composite
component/f:ajax/id-related use cases, using the ajax-switchlist demo
(switchlistAjaxComponent.xhtml) as my base test case. The
ajax-switchlist component hierarchy looks like this (simplified down to
significant parts):
<h:body>
<h:form id="form1">
<ez:switchlist id="switchlist"/>
<h:commandButton value="reload" type="submit"/>
</h:form>
</h:body>
And <ez:switchlist> composite component contains the following
(again, stripped down to interesting parts):
<cc:implementation>
<h:selectManyListbox id="list1"/>
<h:commandButton id="move1to2">
<f:ajax execute="@this #{cc.clientId}:list1"
render="#{cc.clientId}:list1 #{cc.clientId}:list2"/>
</h:commandButton>
<h:selectManyListbox id="list2"/>
</cc:implementation>
First thing to note... The execute/render ids are specified in an
overcomplicated manner. As I mentioned in email earlier today, the
f:ajax execute/render ids are spec'ed to adhere to findComponent() id
resolution semantics. Since the <f:ajax> behavior is attached to
a component that is in the same naming container as selectManyListbox
components that we are targeting, we can simplify from this:
<f:ajax execute="@this
#{cc.clientId}:list1" render="#{cc.clientId}:list1
#{cc.clientId}:list2"/>
To:
<f:ajax execute="@this list1"
render="list1 list2"/>
Ah, that feels much better. Actually, this isn't just a
simplification... this is correct solution. Unfortunately the original
code only happens to work due to non-spec compliant implementation
behavior. That is, when we specify:
render="#{cc.clientId}:list1"
This is the same as specifying:
render="form1:switchlist:list1"
Which should have the same behavior as calling:
move1to2ButtonComponent.findComponent("form1:switchlist:list1");
This will result in the search expression "form1:switchlist:list1"
being resolved relative to the nearest naming container, which in this
case is the switchlist composite component itself. Since there is no
"form1:switchlist:list1" component within the composite component
naming container, findComponent() would return null, and the
<f:ajax> tag should log a warning.
However, instead of failing/logging a warning, we've got some code in
AjaxBehaviorRenderer.findComponent() that does the following:
UIComponent resolvedComponent =
component.findComponent(expr);
if (resolvedComponent == null) {
// not found using a relative search, try an absolute search
resolvedComponent = component.findComponent(':' + expr);
}
The bonus absolute search is not part of the spec - ie. is not typical
findComponent() id resolution behavior. This code should be removed
and replaced by a warning. (We should be able to make the warning
clearer by identifying the naming container that provided the scope of
the search.
In any case, when switching over to:
<f:ajax execute="@this list1"
render="list1 list2"/>
Everything works as expected. We definitely should update this demo to
use this simpler, more spec-compliant solution.
In order to try to reproduce the problem that David was seeing, I
decided to see whether I could update the "reload" button on the main
page from within the composite component. So, first I gave the reload
button an id:
<h:commandButton value="reload"
type="submit" id="reload"/>
And then I added a new render target inside of our <f:ajax> tag
(inside of the composite component):
<f:ajax execute="@this list1"
render="list1 list2 :#{cc.parent.clientId}:reload"/>
Note that I used the leading ":" character to indicate that this is an
absolute id.
I was thinking that "#{cc.parent}" would resolve to the composite
component's immediate parent, which in this case happens to be the
"form1" component. As such, I figured that "#{cc.parent.clientId}"
would give me "form1", and ":#{cc.parent.clientId}:reload" would
produce the absolute id ":form1:reload", which should target the outer
reload button (leaving aside the question of whether this is a good
thing to do or not).
However, when I ran the test case, I hit the following error:
<f:ajax> contains an unknown id '::reload'
Okay, that's weird. So this means that "#{cc.parent.clientId}" is not
resolving to the parent component's client id, but instead to
null/empty string. Huh.
After poking around some more, I found my way to the
com.sun.faces.el.CompositeComponentAttributesELResolver, which provides
some special handling for certain properties on the "cc" object,
including the "parent" property:
if
(COMPOSITE_COMPONENT_PARENT_NAME.equals(propertyName)) {
UIComponent c = (UIComponent) base;
context.setPropertyResolved(true);
UIComponent ccParent =
UIComponent.getCompositeComponentParent(c);
return ccParent;
}
And, of course, UIComponent.getCompositeComponentParent() does not
return the composite component's parent, but instead returns the
nearest ancestor composite component. Which, in this particular demo,
is... null. Yuck. Okay, in retrospect, rather than re-defining the
meaning of "parent" here, we should have introduced a new derived
property, eg. "compositeParent", or something along those lines.
(Unfortunately the current behavior is defined by the spec - section
5.6.2.2, so too late to do anything about this for 2.0.)
I thought I might be able to work around this by avoiding the reference
to the "cc" implicit object - ie. thought I might be able to get this
to work by using the "component" implicit object instead of the "cc"
object, eg: ":#{component.parent.parent.clientId}:reload". But I ended
up running into the same problem.
So, David - it is possible that you are running into this as well.