[
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
