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


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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to