[jira] Updated: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed
[ https://issues.apache.org/jira/browse/TRINIDAD-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1784: - Status: Resolved (was: Patch Available) Fix Version/s: 2.0.0.3-core Resolution: Fixed 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 Fix For: 2.0.0.3-core Attachments: Avoid_Session_Change_When_Not_Required.patch 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 does a postback from inside of 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.
[jira] Updated: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed
[ 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.
