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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
