[
https://issues.apache.org/jira/browse/MYFACES-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2924:
------------------------------------
Status: Patch Available (was: Open)
> Component bindings are not reset when explicit navigation to the same page is
> derived from action
> -------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2924
> URL: https://issues.apache.org/jira/browse/MYFACES-2924
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.1
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Attachments: MYFACES-2924-1.patch
>
>
> It is possible to cause a duplicate id exception doing the following steps:
> - Render one page (let's call mypage.xhtml) with a component that has a
> binding to a request scope managed bean
> - Click the button
> mypage.xhtml
> ....
> <x:component binding="#{bean.component}/>
> <f:facet name="header">
> /*.... some components here with non generated id ....*/
> </f:facet name="header">
> </x:component>
> <h:commandButton action="#{bean.someMethod}">
> ....
> bean
> public String someMethod()
> {
> return "mypage";
> }
> That example should work without problem. The problem is raised by an
> optimization done in myfaces:
> UIInstructionHandler
> if (mctx.isRefreshingTransientBuild())
> {
> c = ComponentSupport.findChildByTagId(parent, id);
> /*......*/
> If we are not refreshing the current view, it does not have sense to try to
> find a component that will not be found, right?
> The spec is clear about the effect of the previous example:
> JSF 2.0 section 7.4.2 : "...A rule match always causes a new view to be
> created, losing the state of the old view. This includes clearing out the
> view map....."
> but if you have component bindings on the page, all components inside the
> component with the binding will preserve the state. There is one simple
> solution from the user point of view (and this is what everyone usually does
> in this case):
> public String someMethod()
> {
> return null;
> }
> no rule match means no navigation, the view state is preserved and finally no
> duplicate id exception.
> If we disable the optimization code, the code will work, but there is still
> one problem with the spec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira