commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Santiago Basulto (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CHAIN-51) New Features for the project.
Date Wed, 15 Sep 2010 21:31:32 GMT

    [ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909896#action_12909896
] 

Santiago Basulto commented on CHAIN-51:
---------------------------------------

First of all. Thank you for helping with this. After that, i would like to say sorry for all
my ignorance.

Niall: Thanks very much for your interest. I'll make some comments to what you posted before.

About the Patch, name changing, ASF license and test, i'm already working on this. But i'm
new on this stuff, so it will take some time. I add that package names becouse didn't want
to people get confused with the actual Chain (commited) code. About the tests, i'm reading
about JUnit (never used it before!).

JDK: OK! perfectly reasonable! and good observation by the way.

Handlers (PaneHandler and StreamHandler): I just added those two becouse wanted to show what
i was thinking. May be deleted.

Java Listeners: Sincerely, i'd like to keep things as simple as it can be. Obviously, if it
can fit standars, that is great! So, if you think it's better to keep in mind the Java Listeners,
we can change it. The main idea of the new feature was to change it a little bit to address
the "control" needs, so the way it's done can change. (What do you think Phil????)

About the rest of your comment: Didn't understand entirely!!!!! Do you have a GMail account
so we can discuss it through chat? In my profile is published my email.


Phil:

Thanks, Thanks, Thanks for your support. Invaluable!

> 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.


Mime
View raw message