myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prakash Udupa N (JIRA)" <...@myfaces.apache.org>
Subject [jira] Updated: (TRINIDAD-1784) Session ChangeManager should not apply attribute customizations for cases when it is not needed
Date Fri, 07 May 2010 06:41:48 GMT

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


Mime
View raw message