[
https://issues.apache.org/jira/browse/MYFACES-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297055#comment-16297055
]
Leonardo Uribe commented on MYFACES-4176:
-----------------------------------------
I have checked the problem and it seems to be a case not covered by the spec.
So, the algorithm works as expected, it makes a relative search from a
component, but only looks in the surroundings of the component, or the closest
NamingContainer. The algorithm tries to find a base naming container and start
the search from that point.
Now, the default implementation of invokeOnComponent always start from
UIViewRoot, and since we are trying to replace the old behavior the algorithm
fails to take a look from the component to the top if the passed expression is
not a keyword.
The algorithm is recursive by nature, but we should avoid call
UIViewRoot.invokeOnComponent, because that's not what's supposed to do, it is
brute force and the recursion becomes out of control. Instead, we should use
UIComponent.findComponent but from the closest NamingContainer to UIViewRoot
going backwards. This only applies if there is no ':' in the expression and
there is no keywords or the base component has been set.
I'll try to fix it, let's see what happens.
> Search expression fails to resolve component outside of form
> ------------------------------------------------------------
>
> Key: MYFACES-4176
> URL: https://issues.apache.org/jira/browse/MYFACES-4176
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.3.0-beta
> Reporter: Jay Sartoris
> Assignee: Thomas Andraschko
> Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSF23AjaxTest.war
>
>
> There seems to be a bug in the
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl class when a
> client id is specified in the render attribute that is outside of the form
> that the f:ajax component resides.
> For example:
> {noformat}
> <h:body>
> <h:form id="form1">
> <h:commandButton id="testButton1" value="GetResult"
> action="#{testBean.test()}">
> <f:ajax listener="#{testBean.ajaxListener}" render="testOutput1"/>
> </h:commandButton>
> </h:form>
> <br/>
> <h:outputText id="testOutput1" value="#{testBean.result}"/>
> </h:body>
> {noformat}
> You can see that the commandButton and ajax components are within the form
> but the render attribute specified is outside of it.
> When the Ajax code is generated for the button, you can see that render
> section is pointing to the commandButton id instead of the specified
> 'testOutput1' id that is actually specified in the f:ajax render attribute.
> {panel:title=JSF 2.3}
> onclick="jsf.util.chain(this,
> event,'jsf.ajax.request(this,event,{*render:\'form1:testButton1
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> When this same scenario is tested on JSF 2.2, the render section is
> correct...pointing to the testOutput1 id.
> {panel:title=JSF 2.2}
> onclick="jsf.util.chain(document.getElementById('form1:testButton1'),
> event,'jsf.ajax.request(\'form1:testButton1\',event,{*render:\'testOutput1
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> This scenario also works on Mojarra JSF 2.3.
> I debugged the issue and it seems
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.invokeOnComponent
> method, the "expression" variable has the correct value that we want to
> render ("testOutput1") but it is unable to find this component because it
> only searches within the form. My thought is that the code should try to
> iterate through the parent.getParent to try to find the id it's looking for.
> The code looks as though it's doing that (around line 163). However, in this
> scenario the code path never drops in to that block of code. What ends up
> happening is the client id of the commandButton is returned. Therefore, the
> testOutput1 component is not updated when the button is clicked.
> I've attached a testcase to easily reproduce the scenario. This could
> potentially be a high impact issue since partial request aren't updating
> components outside of their immediate parent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
