[
https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907065#action_12907065
]
Phil Steitz commented on CHAIN-51:
----------------------------------
This looks like an interesting enhancement to Commons Chain. The setup looks
reasonable. We can talk about the names and even the structure, but for now I
would like to start playing with the setup as you have described it. So that
we can all work with your proposed extension, we need to take what you have
proposed in the rar attachment above and turn it into a patch against the trunk
version of chain. Don't hesitate to ask on commons-dev if you need help
getting the Commons Chain build to work or creating a patch including your
proposed enhancements. (See http://commons.apache.org/patches.html for general
info). A couple of quick comments:
1. As you point out, we want existing chains to work the same as they do now.
2. Chain is currently very easy to learn and use, another feature we want to
keep. Good documentation and minimal complexity in the new APIs (looks pretty
good as you have it, but think carefully about this) are what is needed here.
3. Make sure everything builds and is tested as part of the main chain build
4. Make sure to include ASF license headers with each new file
If you don't mind, it would also be a good thing to submit a contributor
license agreement (http://www.apache.org/licenses/icla.txt - scan and email to
the address in the form).
Welcome to Commons!
> 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
>
> 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.
