[jira] [Reopened] (TRINIDAD-2239) Improve the ancestor based change filtering mechanism by introducing a formal ComponentChangeFilter

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

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

Prakash Udupa reopened TRINIDAD-2239:
-------------------------------------


Reopening because we have one API method pending on this issue to be implemented, see my previous comment.
                
> Improve the ancestor based change filtering mechanism by introducing a formal ComponentChangeFilter
> ---------------------------------------------------------------------------------------------------
>
>                 Key: TRINIDAD-2239
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2239
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Components
>    Affects Versions: 2.0.2-core
>            Reporter: Prakash Udupa
>            Assignee: Scott O'Bryan
>             Fix For: 2.0.2-core
>
>         Attachments: Change_Filter_TRINIDAD-2239_For_Trunk.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> TRINIDAD-2221 provided mechanism for ancestors to decide if ComponentChange targeting one of its descendants should be added to ChangeManager.
> This one is asking for further improvement to this mechanism, by formalizing the contract more. Proposal is to add the following API:
> 1. An abstract class 'org.apache.myfaces.trinidad.change.ComponentChangeFilter' that clients / listeners can implement specializations to accept / reject certain changes on certain components, and then add to the components.
> public abstract class ComponentChangeFilter
> {
>   public abstract Result accept(ComponentChange componentChange, UIComponent changeTargetComponent);
>   public enum Result
>   {
>      ACCEPT,
>      REJECT
>   }
> }
> 2. An abstract implementation 'org.apache.myfaces.trinidad.change.ComponentReferencingComponentChangeFilter' to solve usecases where such a filter needs to hold component reference. 
> One such usecase is where ComponentChanges belonging to certain component subtree is rejected, by keeping a reference to the subtree root component. We leverage on 'org.apache.myfaces.trinidad.util.ComponentReference' for this implementation.
> 3. The following methods on UIXComponentBase to be able to attach / detach ComponentChangeFilters to the components:
> public final void addComponentChangeFilter(ComponentChangeFilter componentChangeFilter)
> public final void removeComponentChangeFilter(ComponentChangeFilter componentChangeFilter)
> public final ComponentChangeFilter[] getComponentChangeFilters()
> ------------
> Implementation:
> In implementation of UIXComponentBase.addComponentChange(UIComponent component, ComponentChange change), we will not add a ComponentChange if any of the ComponentChangeFilters that is attached to the target component itself or any of its ancestors rejects the ComponentChange.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira