You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (Resolved) (JIRA)" <de...@myfaces.apache.org> on 2011/10/15 00:26:12 UTC

[jira] [Resolved] (MYFACES-3360) DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener can now register changes on the view when refreshing occur

     [ https://issues.apache.org/jira/browse/MYFACES-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leonardo Uribe resolved MYFACES-3360.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.1.4
                   2.0.10
    
> DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener can now register changes on the view when refreshing occur
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MYFACES-3360
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3360
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>             Fix For: 2.0.10, 2.1.4
>
>
> With the fix done in MYFACES-3329, the code in DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener no longer needs to prevent save changes triggered when refreshing algorithm occur.
> The code affected looks like this:
>         public void processEvent(SystemEvent event)
>         {
>             UIComponent component = (UIComponent) event.getSource();
>             
>             if (component.isTransient())
>             {
>                 return;
>             }
>             
>             FacesContext facesContext = FacesContext.getCurrentInstance();
>             if (FaceletViewDeclarationLanguage.isRefreshingTransientBuild(facesContext))
>             {
>                 return;
>             }
> Since the "dynamic" parts of the tree was not stable, save any related state produce exceptions on the state. With the param org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE, since the parent component is marked to save/restore, everything worked as expected.
> But the new algorithm make such parts stable, so we no longer require the check for FaceletViewDeclarationLanguage.isRefreshingTransientBuild(facesContext).
> The effect of these lines was that state get lost in this example:
> <h:form id="mainForm">
> <ui:include src="#{testManagedBean.page}"/>
> <h:commandButton id="page1" value="Go to 1" actionListener="#{testManagedBean.page1}"/>
> <h:commandButton id="page2" value="Go to 2" actionListener="#{testManagedBean.page2}"/>
> </h:form>
> page1.xhtml
> <ui:composition
>     xmlns:h="http://java.sun.com/jsf/html"
>     xmlns:f="http://java.sun.com/jsf/core"
>     xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:outputText id="component1" value="Page 1"/>
> </ui:composition>
> page2.xhtml
> <ui:composition
>     xmlns:h="http://java.sun.com/jsf/html"
>     xmlns:f="http://java.sun.com/jsf/core"
>     xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:outputText id="component2" value="Page 2"/>
> </ui:composition>
> click on Go to 2 button twice and then check if component2 was created on refresh, which means the component was not restored and the other one from the previous page was not removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira