SessionChangeManager performance and behavior improvements
----------------------------------------------------------
Key: TRINIDAD-1899
URL: https://issues.apache.org/jira/browse/TRINIDAD-1899
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 1.2.14-core , 2.0.0.3-core
Reporter: Blake Sullivan
Assignee: Blake Sullivan
Currently the SessionChangeManager when working with JSPs maintains a single
list of changes to be applied and applies them in order. While the list does
support collapsing attribute changes even across component moves, this approach
has some performance limitations in and of itself and decreases our ability to
make other performance improvements:
1) Because some changes affect multiple components, we wait to the end of the
document tag to apply the changes (so that all components exist).
Unfortunately this means that when the tags are executing, they don't actually
have any values that were modified by a change available to them. This
prevents us from applying optimizations where we don't even execute the tags
that are subtrees that won't be visited by the lifecycle (for example
undisclosed tabs).
2) Because the changes are not applied at the time of tag execution, we need to
do a separate findComponent() for each change that we want to apply. This can
get expensive for large numbers of changes.
The solution is to group changes into
1) Changes that apply to a single component
a) Collapsible single changes
2) Cross component changes
a) Cross component changes that can change the identity of a component
1) Changes that are applied to a single component are saved under the
component's original scoped identifier. The collapsible changes are collapsed.
2) Cross component changes are maintained in a single page wide list
3) Cross component changes that change the identify of a component update a
mapping from the new (current scoped identifier) for the component to the
original scoped identifier so that as new changes are applied, they are applied
to the correct entry in 1)
4) For efficiency, the serialized form of the changes is a single list of
changes with all collapsible entries collapsed, even across changes that change
the identity. The rename maps and a single component changes can be rebuilt on
demand from this list.
The upshot of these changes are that:
1) We can apply all of the single component changes to a component at tag
execution time, even if that component had a change that moved it. This opens
up optimizations where we don't execute child tags
2) Since all collapsible changes, like attribute changes are collapsed, we have
fewer changes to apply
3) Only the rare, cross-component changes need to be applied using separate
findComponent calls
To apply the changes at tag execution time, we need a new api on ChangeManager:
/**
* Apply non-cross-component changes to a component in its original location.
This is typically
* only called by tags that need to ensure that a newly created component
instance is
* as up-to-date as possible.
* @param context
* @param component Component to apply the simple changes to
*/
public void applySimpleComponentChanges(FacesContext context, UIComponent
component)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.