I can see why it's better for every command in the chain to be executed rather than executing a "sub-chain" based on some condition. I can see the correlation of the sub-chain idea to the goto notion.
But this leaves some baggage that I'm still not comfortable with. Now every command after ValidateActionForm has to know about the "validKey" attribute. So far, that's ok. At least I can readily see the chain of execution and there's no variation in it. But, what if I introduce a command of my own that creates some conditions? Now do I have to customize *every* command in the chain after mine just to check for my condition? This also makes it difficult at best to change the order of execution if I so desired, but I don't know if that's necessarily a bad thing.
If this is the case, how are we any better off with this model than we were with a monolithic request processor? Why should the commands have so much inter-dependence now that they are separate objects? Are we better off with them as inter-dependent separate objects than we were as one monolithic object?
Now, is there any way to get the best of both worlds -- no gotos, and no "state baggage"? Is it possible that the command could just be responsible for executing and not ever be called unless all the conditions are in place for it to be executed? Something at a higher level than the command would have to determine whether it should be executed? So, you might have something between the chain and the command that determines that. I'm not sure if that's any better because then *that* component would have to know about all the commands as well.....
Anyway, I hope I'm making sense. I hate to ask a question and then leave the room, but I'll have to take answers in the morning :-)
Thanks, Greg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
