myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prakash Udupa <>
Subject Apply patch [was: Re: [jira] Created: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed]
Date Mon, 10 May 2010 19:11:46 GMT
Please review this fix, and someone with commit privileges please apply 
my patch for this issue.


Prakash Udupa N (JIRA) wrote:
> Session ChangeManager should not apply attribute customizations for cases when it is
not needed
> -----------------------------------------------------------------------------------------------
>                  Key: TRINIDAD-1784
>                  URL:
>              Project: MyFaces Trinidad
>           Issue Type: Bug
>           Components: Components
>     Affects Versions:
>          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
> 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.

View raw message