[
https://issues.apache.org/jira/browse/TRINIDAD-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595774#action_12595774
]
pudupa edited comment on TRINIDAD-1015 at 5/9/08 7:01 PM:
-------------------------------------------------------------------
The attached file ' TRINIDAD-1015-Patch-For-Branch_trunk_1.2.x.patch ' is the
patch for this Jira issue on trunk_1.2.x based off revision #654993.
was (Author: pudupa):
This is the patch for this Jira issue on trunk_1.2.x based off revision
#654993.
> 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
> Attachments: TRINIDAD-1015-Patch-For-Branch_1.2.7.1-branch.patch,
> TRINIDAD-1015-Patch-For-Branch_trunk_1.2.x.patch
>
>
> 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.
