I logged the following spec issue to request that we clarify the
execute/render id behavior:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=567
This is easy enough to fix, and since this is already a source of
confusion, we should definitely fix this in the next spec draft.
Andy
Andy Schwartz wrote On 5/25/2009 8:06 AM ET:
Gang -
There is one obviously critical piece of information missing here that
clearly needs to be described more explicitly within the spec/pdldocs.
The format for the execute/render ids in the f:ajax tag matches the
format for ids that are passed to findComponent(). That is... ids that
do not start with the naming container separator character are treated
as relative to the current naming container. Ids that do start with
the separator character are treated as absolute ids - ie. are resolved
relative to the UIViewRoot.
So, for example, let's say we have the following component tree where
we use f:subview to introduce a naming contianer
<f:view>
<f:subview id="namingContainer">
<h:commandButton id="insideButton"/>
<h:graphicImage id="insideImage"/>
</f:subview>
<h:graphicImage id="outsideImage"/>
</f:view>
If we want to Ajax-enable the "insideButton" to target the
"insideImage, we would use the following f:ajax tag:
<f:ajax render="insideImage"/>
If, on the other hand, we want to target the "outerImage", which is
outside of the naming container, then we must use an "absolute id", eg:
<f:ajax render=":outsideImage"/>
(Note the leading ":" character.) This is similar to calling
insideButtonComponent.findComponent(":outsideImage") - ie. this will
start the search for the "outsideImage" id up at the root naming
container.
The fact that the pdldocs do not describe the format for
execute/render ids is clearly a spec bug that needs to be addressed. I
will open a bug to track this in a moment. This behavior is defined in
the actual spec document itself in section 10.4.1.1 under the title
'Specifying “execute”/”render” Identifiers'. But even that section
could use some clarification (eg. could use an example like the one
above to illustrate the behavior).
David Geary wrote On 5/24/2009 11:39 PM ET:
> Notice the <f:ajax> tag. I think I'm accessing the image from the
> parent component (map.xhtml) correctly. However, when I load the page
> I get this:
>
> <f:ajax> contains an unknown id
>
'form:j_id1186681689_16ef8569:0:j_id1186681689_16ef8513:j_id-1105909415_41ead6fe:image'
>
If I had to guess (haven't looked at the implementation yet), the
issue is that we are searching for this id relative to the composite
component's naming container. Since this particular id is not present
under the composite component, we do not find the target component. We
should make this error message more explicit - ie. we should include
the id of the naming container within which we searched for the id.
>
> If I remove the f:ajax tag, load the page, and check the source, I
> see an <img> tag:
>
> <img
>
id="form:j_id1186681689_16ef8569:0:j_id1186681689_16ef8513:j_id-1105909415_41ead6fe:image"
> src="..."/>
>
> And that id is *exactly* what <f:ajax> says it cannot find. It's in
> the page, but <f:ajax> cannot find it?!?
>
> My guess is that <f:ajax> is evaluating the id before the page is
> completely constructed, and therefore, it doesn't find it, but that's
> just a WAG on my part.
You'll need to use the ":" prefix within your render id to indicate
that you are specifying an absolute id. If that does not work, then my
guess is that there is an implementation bug here.
Andy