[
https://issues.apache.org/jira/browse/TRINIDAD-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prakash Udupa N updated TRINIDAD-1784:
--------------------------------------
Status: Patch Available (was: Open)
> 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
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> 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.
-
You can reply to this email to add a comment to the issue online.
