commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <ted.hus...@gmail.com>
Subject Re: [chain] [nag] Please commit stuff for DispatchChain
Date Sun, 03 Apr 2005 11:31:18 GMT
I do see the need to do dispatch-like things in my own applications
(although I don't take this approach). But, I would agree that a
DispatchCommand is out of scope for the core package.

As to LookUpCommand, I would favor moving config, generics, and web
into a  "Chain-Extras" distribution, so that the Chain Core
distribution is just the interfaces and base implementations.

I very much like the original idea of implemenating the CoR pattern
and nothing else. This is not to say we can't build other
distributions on top of the CoR Core. I'm just saying this might be a
good time to draw a line in the sand between the Core and the CoR
Extras.

-Ted.

On Mar 30, 2005 2:36 PM, Sean Schofield <sean.schofield@gmail.com> wrote:
> I know its been a while since we discussed this ... but I would like
> to bring up the issue of DispatchChain again.  I have a pressing need
> for something like this in my current application.  I need to go ahead
> and move it into our project codebase or have it added to
> commons-chain.  No hard feelings if I cannot convince you that this is
> useful.
> 
> I will briefly summarize my arguments again.  The dispatch chain
> allows you to compose a chain of commands where the command method can
> be something other than execute.  It will always have the same
> arguments and it will always be the same for every command in the
> chain.  I think the fact that it is always the same method for every
> command in the chain is a key point here.  Its still the CoR pattern.
> There is nothing special about the name of the execute method, the
> pattern just requires a consistent method.
> 
> If you do not accept this line of reasoning then I would suggest that
> DispatchLookupCommand be removed from the codebase as well.  I don't
> think you can justify one and not the other.  Finally, its in the
> generic package so its entirely optional if you don't want to use it.
> 
> I'd like to resolve this ASAP so I can go forward on my project here
> at work.  Please give some thought to my arguments.  As I said
> earlier, I will accept the decision of the group if the group cannot
> be persuaded.
> 
> Regards,
> sean

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message