Session ChangeManager should not apply attribute customizations for cases when
it is not needed
-----------------------------------------------------------------------------------------------
Key: TRINIDAD-1784
URL: https://issues.apache.org/jira/browse/TRINIDAD-1784
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Environment: Generic
Reporter: Prakash Udupa N
For every request, SessionChangeManager today applies all the attribute based
customizations (AttributeComponentChanges) that it gathers in session scope for
the view in request.
This application happens during tag execution, and just before rendering
response, which means that any restored state (due to state saving) and any
component binding resolution is all overlayed / masked by the customization
applied for the target component.
This is undesirable in most of the cases, one simple usecase being:
1. Page A has dynamic number of tabs, and the tab to be disclosed is chosen due
to the component binding in every request. Let us assume for this request there
were 5 tabs, and tab #1 is the default chosen/disclosed.
2. User is on Page A, selects/discloses tab 3, the tab component wants to treat
this gesture as end user personalization and constructs and adds an
AttributeComponentChange to set 'disclosed = true' on tab #3.
3. User navigates to Page B, then navigates back to Page A
4. Due to the dynamic nature noted in step #1, the state manager restores the
default selection to tab #1, then the component binding decides to add a couple
more tabs (now total number of tabs is 7) and also decides that tab #6 should
be disclosed, so due to component binding 'disclosed = true' on tab #6 now, and
it is false on all other tabs. Now SessionChangeManager during tag execution
re-applies the customization and sets the disclosed tab to be tab #3, thereby
messing up with what the application intended.
Solution:
SessionChangeManager should apply attribute changes only in cases where:
1. The request is not a postback
2. We do not have state saved/applied for the view by the JSF state manager
implementation.
3. The target component of the change is not a component that was
relocated/added earlier due to other types of ComponentChanges (eg.
MoveChildComponentChange/AddChildComponentChange)
Note that the SessionChangeManager should continue to apply the non-attribute
changes (eg. AddChildComponentChange/SetFacetChildComponentChange) regardless
of whether it is postback. This is to take care of the situation where JSF
runtime tries to normalize the tree structure, and customizations involving
structural changes to the component tree applied previously are lost.]
This proposal is all implementation fix, and no API changes involved.
This solution also leads to performance improvement, given that the attribute
based customizations could be very huge due to a lot of user gestures on
various interactive components resulting in customizations.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
