[
https://issues.apache.org/jira/browse/MYFACES-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3451:
------------------------------------
Status: Patch Available (was: Open)
> [core] Improve PSS algorithm when a dynamic view (use of c:if or ui:include
> src=#{...}) is used
> -----------------------------------------------------------------------------------------------
>
> Key: MYFACES-3451
> URL: https://issues.apache.org/jira/browse/MYFACES-3451
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Attachments: MYFACES-3451-1.patch
>
>
> Implement change according to mail sent about it to dev list under the name:
> [core] Improve PSS algorithm when a dynamic view (use of c:if or ui:include
> src=#{...}) is used
> In the last months I have been working on a solution to improve Partial State
> Saving (PSS) performance in cases where the view is updated dynamically by
> effect of a facelet tags like:
> - <c:if ...>
> - <c:when>
> - <ui:include src="#{...}">
> - <ui:decorate template="#{...}">
> In simple words, any use of the previous tags in a page causes all components
> inside them to be saved and restored fully. The side effect is the overall
> state gets bigger. With the introduction of PSS in JSF 2.0, instead save an
> array of properties, a key/value pairs are used, so usually this effect is
> difficult to notice, but it is relevant specially when <ui:include
> src="#{...}"> is used to update content dynamically. It is quite simple to
> find examples with a search engine on the internet.
> I'll explain in detail what's going on.
> Let's see what happen when c:if is used:
> <c:if test="#{condition}">
> <h:outputText value="Some text"/>
> </c:if>
> The first time the view is rendered, if the condition is false, the component
> is not added, but later in a postback if the condition changes from false to
> true, the component is added. Here the algorithm have two options:
> 1. Ignore it.
> 2. Mark the component or branch to be restored fully.
> Most of the time ignore (1) is ok, but in some complex cases the state synch
> is lost, because test="#{condition}" is evaluated every time the view is
> restored, with different results. The users usually have reported this as
> "state get lost" or ClassCastException problems. To deal with such cases, a
> special mode was added in MyFaces to implement (2) with a web config param
> called org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS.
> But what happen if the algorithm save c:if "condition" the first time the
> view is rendered? With that, PSS algorithm will always restore the initial
> view as expected. Recently in 2.0.10 / 2.1.4, this improvement (MYFACES-3329)
> was added so it is no longer necessary to enable the web config param. Great!
> But note this does not solve the "state gets bigger" problem.
> Now consider what happen if c:if "condition" is saved every time it change
> (before render response). If the condition is false and changes to true, the
> initial state will now be restored including the
> component, so if it is called markInitialState() over the component, and then
> the delta is saved, the state size will be smaller and finally it will be
> saved more efficently, because the initial state is the one who gets bigger,
> instead the part that is saved as delta.
> This solution can be applied to <c:if ...>, <c:when>, <ui:include
> src="#{...}"> and <ui:decorate template="#{...}">, which is enough because
> <c:forEach> can be replaced with <h:dataTable rowStatePreserved=true ...> or
> a similar component like the ones available in Tomahawk or any other variant.
> It is interesting to note the solution also fix the problem when <h:dataTable
> rowStatePreserved=true ...> is used inside a dynamic part.
> Fortunately, the spec doesn't say anything about how markInitialState() is
> called, and let it as an implementation detail. Also,
> javax.faces.IS_BUILDING_INITIAL_STATE description is so general that even
> with the change there is no need to change the javadoc. After considering all
> history behind PSS algorithm, it seems reasonable to activate
> markInitialState() call and set javax.faces.IS_BUILDING_INITIAL_STATE to true
> when a dynamic update in a component tree is done by a facelet tag, and
> deactivate it as soon as the code process the content.
> At the end, applications using the previous tags will have a really huge
> improvement into its state. But anyway, since it is a "extension" of the
> initial intention of the flag, I consider desirable to mention it. It is
> difficult to measure the impact, because it depends of the view structure
> itself, but it sounds like a very promising change.
> Suggestions, opinions and what you do want to say about this proposed change
> is welcome. If no objections, I'll commit the proposed change soon.
--
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
