commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33006] - [chain] Proposal: DispatchChain
Date Tue, 18 Jan 2005 00:19:50 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33006>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33006


slough@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slough@gmail.com




------- Additional Comments From slough@gmail.com  2005-01-18 01:19 -------
(In reply to comment #10)
I can definatly see how a command clustering system would be useful, especially
where you could run a chain of related commands over many independent clusters.

What bothers me is that DispatchAction seems to move away from the idea of the
execute method always "doing the work" of the command.  Commands are no longer
interchangable because the one method you know is there in every command
(execute) may not be doing any work at all.  In such a case it makes no sense to
even implement Command: we may not using the execute method, or a context, so
why bother?  Just allow the chain to take any arbitrary class and call that
class's method as an argument.

With that in mind, I'm wondering if it would be possible to use member classes
instead of methods?  

Using your example, one would have a container class relating to a peticular
area of a document.  It would contain different member classes that do work on
its coorisponding area.  Each member class implements command and therefor has
an execute method.  Each of these member classes could share methods both from
within their container class and from some universal parent class that extends
all commands in the project (just never externally).  The container class itself
could contain an execute method (maybe to prepare for the instance of a member,
since containers have to be invoked first) if it implemented Command, or maybe a
special "DispatchChainable" interface.

In such a case there would be no reason for a DispatchAction since every member
would be a command and thus could be added to a regular chain.  Your
DispatchChain would be very useful, however, and could be called to execute
commands within a chain of containers, instead of methods within a chain of
commands.  

Just an idea.  Perhaps the clutter of inner classes or the implementation would
overly complicate the issue.  Let me know what you think.

> In response to William's earlier comments ...
> 
> Having a method implement two or more "command" methods is still in keeping 
> with the spirit of the Command pattern (IMO).  I would tend to agree with some 
> of your points when it comes to the use of a single DispatchCommand 
> (especially about the method being arbitrary.)  But I think it becomes much 
> more powerful when you consider a chain of dispatch commands.
> 
> Consider you have a group of commands with a foo() and bar() method.  Now you 
> can group these together into a single chain.  Then whatever code is calling 
> the chain can execute either the foo() "sequence" or the bar() sequence ( or 
> both - one at a time obviously).  
> 
> You've effectively established the common "command" method to execute 
> dynamically but its definitely not arbitrary in this case.  I definitely have 
> some uses for this in my code right now.  There are cases where I could have a 
> command related to each section of a document that is managed by my app.  
> These commands can inherit from a common abstract command that defines the 
> dispatch methods that need to be provided.  Each time you add a new section to 
> a document, you just create a new command that extends the abstract one and 
> add it to the catalog.  You have a single catalog to maintain and the rest of 
> the code that knows what method in the chain to call and when remains 
> untouched.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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