myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] [Commented] (MYFACES-2924) Component bindings are not reset when explicit navigation to the same page is derived from action
Date Thu, 05 May 2011 16:45:03 GMT


Leonardo Uribe commented on MYFACES-2924:

The bug is present in JSF 1.2 and 1.1. I haven't investigated too much if it is possible to
fix it there.

I theory, something should be done on the spec to solve this one, but after checking it more
carefully I realized we can fix in myfaces code without include it on the spec, and instead
consider it an implementation detail.

> Component bindings are not reset when explicit navigation to the same page is derived
from action
> -------------------------------------------------------------------------------------------------
>                 Key: MYFACES-2924
>                 URL:
>             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:

View raw message