[
https://issues.apache.org/jira/browse/MYFACES-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3329:
------------------------------------
Status: Patch Available (was: Open)
> Fix PSS algorithm to ensure c:if and ui:include src="#{...}" related use
> cases will work without rely on
> org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-3329
> URL: https://issues.apache.org/jira/browse/MYFACES-3329
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Attachments: MYFACES-3329-2.0.x-1.patch, MYFACES-3329-2.1.x-1.patch
>
>
> There is a well known issue related to use c:if and ui:include src="#{...}".
> It has been described in different ways for a long time. For example see:
> MYFACES-3271 ui:include tag handler evaluates its bindings to soon during JSF
> lifecycle
> There is a lot of related issues but to keep things simple, PSS algorithm is
> based on the following conditions:
> 1. Each time the view is build by first time or when it is restored, the same
> initial state will be retrieved.
> 2. It is possible to calculate a delta state, based on that initial state.
> In practice, there are some use cases that breaks that:
> a. c:if tag
> b. c:choose, c:when and c:otherwise
> c. ui:include src="#{...}" (usually known as "dynamic include")
> d. ui:decorate template="#{...}"
> e. c:forEach
> The reason is they change the component tree dynamically. For example a c:if
> tag could be bound to a ValueExpression that in one moment could be true and
> then false, so the "initial state" calculated by PSS algorithm through a
> vdl.buildView() will be different each time, breaking condition 1.
> It is true there exists the workaround with
> org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE, which mark
> some parts of the tree to be restored fully, so it does not matter the
> initial state, at the end just we restore such parts fully and everything
> works as facelets 1.1.x. But even so, it is a workaround, and we need a
> better solution to that.
> In practice, points a., b., c. and d. are relevant. The case e. related to
> c:forEach is not because the iterated data has
> usually a life longer than the view (session, conversation or view scope), so
> we can exclude this case.
> The solution to this problem is store the result of the evaluated expressions
> within the view. It is the only that will work
> as good as org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE.
> To do that we need to generate an unique id per tag and make components and
> tags inside them generate unique tags too but the
> same ids should be generated each time the view is build no matter the
> conditions. For example:
> <h:outputText value="-A-"/>
> <c:if test="#{condition}">
> <h:outputText value="-B-"/>
> </c:if>
> <h:outputText value="-C-"/>
> -C- should have the same id each time, no matter what happen inside c:if.
> Since PSS algorithm uses clientIds to store the "delta" state of the
> components, ensure that is CRITICAL, otherwise the state will get mixed or
> lost.
> Additionally, we must restore that "facelet state" before the view is built
> to use it when the initial state is derived.
--
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
