myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (Updated) (JIRA)" <>
Subject [jira] [Updated] (MYFACES-3451) [core] Improve PSS algorithm when a dynamic view (use of c:if or ui:include src=#{...}) is used
Date Wed, 18 Jan 2012 15:36:40 GMT


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:
>             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
> - <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
> 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:!default.jspa
For more information on JIRA, see:


View raw message