Steve Raeburn said: > I would prefer going with simpler, specialised classes than a monolithic > DispatchAction but if there is a consensus to combine them then I accept > your point. > > A combined action may perhaps offer more flexibility. A concrete subclass > might be able to resolve the method in different ways depending on what was > present at runtime. (request parameter, parameter, key).
i never liked the separate dispatch actions. so, i ended up writing one of these "combined" ones of my own. i think it's a good way to go. the flexibility allows me to extend all my actions from the one class and later worry about how the dispatch method is specified (via things that don't have to be re-compiled: struts-config, velocity templates, etc). > However, I'm not sure that flexibility justifies the increased complexity of > the class or of understanding how to use it. Potential areas for user > confusion would be misunderstanding the order of preference for resolving > the method names or not recognizing conflicts that could arise between them. yes, the order of precedence/preference would need to discussed and well documented/exampled. > Also, what happens if we need to resolve by other means? Add more weight to > the super class or add another specialized sub class? ... i don't think there's really that many reasonable ways to specify a dispatch, and you're just talking here about combining the various dispatch actions, right? Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
