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