[
https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917270#action_12917270
]
Phil Steitz commented on CHAIN-51:
----------------------------------
Sorry it has taken me a while to get back to this. I concur with Niall's
suggestions. Santiago - does Niall's patch provide a workable framework for
you?
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar,
> CHAIN-51-Alternative-Listener-proposal.patch
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in
> the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and
> documenting, but i'd like to comment the main idea behind it, so you can give
> your opinion. I have faced some problems with names. I did not want to rename
> commons.chain classes, as a matter of respect, so some names can seem weird,
> it can change.
> First of all, i needed more "control" over my commands. I like to have
> everything logged, and several commands were used in GUI apps, so i needed
> more User interaction. Then, i decide to provide the main Interface (Command)
> some other methods, just to can track what is it doing. I made a new
> interface called Action (i use the other name given to this pattern). I
> extend it from Command, just becouse i didn't want to change everything, and
> can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was
> present, false otherwise
> The main idea behind this was to have a Handler object that can track the
> "moves and states" of the Action (or Command) class. It's something similar
> to the Observer Pattern. An action "can" (optionally, if doesn't want to
> register a handler, it's a simple Command) register a Handler, and comunicate
> things about itself. So, i have an Interface called ActionHandler. It has
> three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to
> comunicate it that has started executing. It's really simple, but helped me
> big time.
> Something great about the Action Interface, is that it only sais that you can
> register a handler, not the number of handlers. So, a Class implementing
> Action can register a number of handlers (file logger handler, GUI tool for
> comunicating the user, console logger, etc) and inform about the progress to
> all of them. If it's not needed to comunicate, this class can just execute
> silently.
> So, this is the main change, but with this little change i needed to do
> something with the chain. So i just made the Chain interface extend the
> Action interface. Of course, can be another class, something like ActionChain
> that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic
> classes and a package for test it. I've developed some other classes, for
> example, Action implementations that register several ActionHandlers. I'm
> currently working on a "BlockingQueueChain", it's a chain that can execute
> all its Commands (or Actions) in parallel. Obviusly, there are not so many
> cases when this Chain can be used. If someone is interested i will can send
> the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not.
> Or simply, whether i should start a new "branch" of the project to no
> interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
