[jira] Updated: (TRINIDAD-1015) SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker

["Prakash Udupa N (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/TRINIDAD-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prakash Udupa N updated TRINIDAD-1015:
--------------------------------------

    Status: Patch Available  (was: Open)

> SessionChangeManager - Need support for applying changes to a different component than the immediate target, need for supporting ChangeMarker
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1015
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1015
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>         Environment: Not applicable
>            Reporter: Prakash Udupa N
>
> Component changes that are added to SessionChangeManager are applied while the components are being created by the tag handlers. Specifically UIXComponentELTag._applyChanges() and UIXComponentELTag.doEndTag() does this job. Changes are applied only if the component was created newly during tag execution. UIComponentELTag.getCreated() is consulted for this purpose.
> There are certain type of changes that are registered on a particular target component, but actually need to be applied on a different component to make the change effective.
> Consider example of a MoveComponentChange specialization that moves components within the view tree. There are three participants in this change:
> 1. The component that is to be moved.
> 2. The parent at the destination of the move.
> 3. The neighboring sibling at the destination to be able to position the component rightly after the move.
> At the outset this seems to be a change to be recorded against the component that is to be moved (i.e. #1). However, this change needs to be applied actually on the nearest common root parent of the tree that #1 and #2 belongs to.
> During tag execution (createview/restoreview), the component for #1 gets created, however the common root never gets created. UIXComponentELTag.getCreated() returns false for the common root, as a result, from the current behavior in UIXComponentELTag._applyChanges(), this type of change never gets applied correctly.
> Proposal is to:
> a) Provide a ChangeMarker interface that clients could register against the immediately apparent target component (In the above example it is component in #1).
> b) Improve UIXComponentELTag such that upon applying changes, if a ChangeMarker is encountered instead of a Change, do not apply any change, but ask the ChangeMarker for actual target. Subsequently mark the tag for the new target component as forcibly needing change. This ensures that the Change is correctly applied on the actual target at later point in time.
> c) UIXComponentELTag, will consult getCreated() as well as check if a change application is forced while applying change. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.