How to reRender in a parent naming container?

[andrew.rw.robinson]

How can I re-render a component in a parent naming container without specifying a absolute path?

Crude example:
<a4j:form id="myform">
<h:outputText id="a" />
<f:subview id="b">
<a4j:commandLink id="c" reRender="a" />
</f:subview>
</a4j:form>

Client IDs:
myform:a
myform:b
myform:b:c

1) link is clicked
2) link calls AjaxContext.addRegionsFromComponent
3) AjaxContext internally calls convertId
4) convertId calls UIComponent.findComponent
5) find component gets the parent naming container ("myform:b")
6) find component sees no myform:b:a and returns null
7) "a" is not re-rendered

I would use "..:a" if it was supported, but it is not. I really want to avoid absolute IDs since our application is quite complex and there isn't a guarantee that we won't change parent naming containers later.

Is there any way to do this? If not can I propose an enhancement to AjaxContext:

 private String convertId(UIComponent component, String id) {
 if (id.charAt(0) == NamingContainer.SEPARATOR_CHAR) {
 return id;
 }
 if (null != component) {
 UIComponent target = null;
 for (UIComponent c = component; null != c && null == target; c = c.getParent())
 target = c.findComponent(id);

 if (null != target) {
 return AjaxRendererUtils.getAbsoluteId(target);
 }
 }
 return id;
 }

This code would allow the ability to surf up the component tree looking for components with the given ID.

[sergeysmirnov]

How about:

<a4j:form id="myform">
 <h:outputText id="a" />
<a4j:/form>
<a4j:form>
 <f:subview id="b">
 <a4j:commandLink id="c" reRender="a" />
 </f:subview>
</a4j:form>

this still is not cover by proposed code.

Currently we just reuse component.findComponent() that has the similar algorithm

http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/index.html

[andrew.rw.robinson]

A4J is for JSF 1.1, not 1.2 though. Docs say 1.2 is not required.

[andrew.rw.robinson]

Sorry it is not the same in 1.2 either

Otherwise, search up the parents of this component. If a NamingContainer is encountered, it will be the base.

As you can see, it never searches above the parent naming container, which is what I need. In my example, "a" is not in the same naming container as "c", and the specification specifically states that it will only search under the current "base" which in my example is "b".

My code sample searches *all* parents, not just up to the parent naming container.

[sergeysmirnov]

We USE findConponent(), but not clone it.
I put a link to the latest from:
http://java.sun.com/javaee/javaserverfaces/reference/api/

This is for JSF 1.1_01:
http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/index.html

and so on.

So... if we decide to migrate to the own code for finding components (for example, for the one you proposed) , we have to:
a) be sure, the new algorithm is more beneficial
b) have a backward compatibility with findComponent. (To keep the previous developer's code workable)

I do not understand why you are so irritated about my question. It is a normal practice to examine the algorithm against more possible use cases. That was I tried to do.

[andrew.rw.robinson]

I am not suggesting replacing UIComponent.findComponent, but allowing the AjaxContext to search up the tree, which UIComponent.findComponent will not do.

There are other 3rd party libraries that do this (Jenia4Faces for example), where if the component isn't found in the current NamingContainer, it checks the parent NamingContainer until it is found or the code runs out of NamingContainers to check.

I think this is a short-comming in the JSF spec (the inability to designate the parent naming container in a relative manner using UIComponent.findComponent)

My suggestion is not to make a new algorithm, but to enhance the functionality that is gained when using UIComponent.findComponent().

Since my proposal still includes calling findComponent, there is no reason for backward compatibility checks.

To answer "a)", since there is no way to say find a component in the naming container above the current one, I'd say that is reason enough to have it be more beneficial.

[sergeysmirnov]

http://jira.jboss.com/jira/browse/AJSF-46