You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org> on 2011/03/09 20:29:59 UTC
[jira] Created: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Introduce ChangeManager wrapper class
-------------------------------------
Key: TRINIDAD-2055
URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by Blake Sullivan <bl...@oracle.com>.
+1
-- Blake
On 3/9/11 12:32 PM, Pavitra Subramaniam wrote:
> +1
>
> Thanks
> Pavitra
>
> On 3/9/2011 11:29 AM, Andy Schwartz (JIRA) wrote:
>> Introduce ChangeManager wrapper class
>> -------------------------------------
>>
>> Key: TRINIDAD-2055
>> URL:
>> https://issues.apache.org/jira/browse/TRINIDAD-2055
>> Project: MyFaces Trinidad
>> Issue Type: Improvement
>> Affects Versions: 2.0.0-beta-2
>> Reporter: Andy Schwartz
>> Assignee: Andy Schwartz
>> Priority: Minor
>>
>>
>> One way that users might customize change management behavior is to
>> create a proxy ChangeManager that delegates through to an underlying
>> ChangeManager (eg. to SessionChangeManager) for most operations after
>> performing filtering of the incoming changes. It is possible to
>> implement such proxy ChangeManager classes today. However, without a
>> wrapper base class, these implementations are fragile - ie. they will
>> break if we ever introduce a new method to the ChangeManager API.
>>
>> A more robust solution would be to introduce a base wrapper class for
>> proxy ChangeManager implementations to extend. That way, in the
>> event that we do introduce new ChangeManager methods, the base
>> wrapper class can be updated in parallel, protecting subclasses from
>> the change.
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
Re: [jira] Created: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by Pavitra Subramaniam <pa...@oracle.com>.
+1
Thanks
Pavitra
On 3/9/2011 11:29 AM, Andy Schwartz (JIRA) wrote:
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
>
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005677#comment-13005677 ]
Andy Schwartz commented on TRINIDAD-2055:
-----------------------------------------
Committed fix to trunk:
http://svn.apache.org/viewvc?view=revision&revision=1080604
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by Blake Sullivan <bl...@oracle.com>.
If you don't provide a wrapper and the customers don't using it for
their wrappers then adding a new method onto the abstract class will
result in the default implementation being called rather than delegating
through to the wrapped class that may have overridden the default
implementation.
-- Blake Sullivan
On 3/9/11 3:40 PM, Prakash Udupa (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004875#comment-13004875 ]
>
> Prakash Udupa commented on TRINIDAD-2055:
> -----------------------------------------
>
> Andy,
>
> I'm trying to understand the benefit of this new wrapper API.
> If we introduce any new method to ChangeManager, we will need to provide a default implementation in the ChangeManager class so that we do not break the existing implementations. Does this not suffice to address the fragility issue here, how does the wrapper help any more ?.
>
>> Introduce ChangeManager wrapper class
>> -------------------------------------
>>
>> Key: TRINIDAD-2055
>> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
>> Project: MyFaces Trinidad
>> Issue Type: Improvement
>> Affects Versions: 2.0.0-beta-2
>> Reporter: Andy Schwartz
>> Assignee: Andy Schwartz
>> Priority: Minor
>> Attachments: ChangeManagerWrapper.java
>>
>>
>> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
>> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Prakash Udupa (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004875#comment-13004875 ]
Prakash Udupa commented on TRINIDAD-2055:
-----------------------------------------
Andy,
I'm trying to understand the benefit of this new wrapper API.
If we introduce any new method to ChangeManager, we will need to provide a default implementation in the ChangeManager class so that we do not break the existing implementations. Does this not suffice to address the fragility issue here, how does the wrapper help any more ?.
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011648#comment-13011648 ]
Jeanne Waldman commented on TRINIDAD-2055:
------------------------------------------
Answer from Andy to Prakash's question --
Let's take a closer look at the use case that I am hoping to address...
I want to write a ChangeManager implementation that:
1. Delegates all of the real work to some other ChangeManager.
2. Examines ComponentChanges as they are added and drops certain
changes that I do not want to save.
I can do this today by writing my own wrapper class that extends
ChangeManager directly and provides delegating implementations of all
of the ChangeManager methods.
However, if we later add some new method to the ChangeManager contract
(as we did with applySimpleComponentChanges()), my wrapper class would
need to be updated - ie. I would need to add yet another delegating
method implementation for the new API. This is annoying and fragile.
On the other hand, if we introduce a base wrapper class in Trinidad,
my concrete wrapper subclass is not impacted by new additions to the
ChangeManager API. Any time we add a new method to the ChangeManager,
we would add an equivalent implementation to the ChangeManagerWrapper
base class. In addition to reducing the amount of work to implement a
ChangeManager wrapper class (no longer need to re-implement every
ChangeManager method), we have significantly reduced the risk of
breaking such classes as the API evolves.
FWIW, this approach of providing a base wrapper class is a very common
pattern. (As Pavitra hinted at this, is used all over the place in
JSF.)
Andy
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Fix For: 2.0.0-beta-3
>
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Schwartz updated TRINIDAD-2055:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
Status: Resolved (was: Patch Available)
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Fix For: 2.0.0-beta-3
>
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005684#comment-13005684 ]
Andy Schwartz commented on TRINIDAD-2055:
-----------------------------------------
Committed to 1.2.12.5:
http://svn.apache.org/viewvc?view=revision&revision=1080622
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Fix For: 2.0.0-beta-3
>
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Schwartz updated TRINIDAD-2055:
------------------------------------
Status: Patch Available (was: Open)
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper
class
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005692#comment-13005692 ]
Andy Schwartz commented on TRINIDAD-2055:
-----------------------------------------
Committed to 1.2.x:
http://svn.apache.org/viewvc?view=revision&revision=1080631
> Introduce ChangeManager wrapper class
> -------------------------------------
>
> Key: TRINIDAD-2055
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-beta-2
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Priority: Minor
> Fix For: 2.0.0-beta-3
>
> Attachments: ChangeManagerWrapper.java
>
>
> One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API.
> A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira