<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
A4J is for JSF 1.1, not 1.2 though. Docs say 1.2 is not required.
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.
We USE findConponent(), but not clone it.
I put a link to the latest from:
This is for JSF 1.1_01:
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.
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.