Tom Drake wrote:
It appears that what we have are different strategies for determining the method name. Given that, wouldn't it make more sense to have a single version of DispatchAction (perhaps called StrategyDispatchAction) which relies on a named strategy class to resolve the method name
That would be okay if three of the choices were not otiose. They are legacy and have to be accounted for, but essentially they are fatter, slower, more complicated, less decoupled etc., etc. The three together also just do aspects of what SimpleDispatchAction does, and they do these aspects in a way that is fatter, slower, more complicated, less decoupled, etc., etc. If it were not for the legacy code, SimpleDispatchAction, I think, should just replace the other three en toto. If you use SimpleDispatchActions methods, you don't ahve a use for the others and don't need this somewhat heavy overhead to take account of other people's legacy code. This is why, in part, why I am against putting this sort of thing in the Struts application and prefer to just suggest these things to people using Struts. It is easy to bloat with legacy app specific code that is outmoded.
Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
