You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Prakash Udupa <pr...@oracle.com> on 2010/05/10 21:11:46 UTC

Apply patch [was: Re: [jira] Created: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed]

Please review this fix, and someone with commit privileges please apply 
my patch for this issue.

thanks,
Prakash

Prakash Udupa N (JIRA) wrote:
> 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 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.
>
>
>