[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
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
