> On 8/3/06, Jason Carreira > Ted didn't say deprecate. Ted said that it didn't > seem like a best > practice, in the same way that chaining actions is > not a best > practice. Mainly because it goes against the grain of > the "advanced" > features like type converters, localization, and > especially > validation. >
I think a lot of long-time WebWork users have said in this thread that we don't view it as a poor practice... In fact I think all of our best practices involved multiple action aliases for Action classes. It doesn't go against the grain of any of those, you just have to either customize your interceptor stack, or make it context aware like Patrick was talking about. > Yes, and that we've already deprecated the > bang-syntax. In the head, > it's only supported when a compatibility switch is > turned on, and I > expect it would be removed entirely in 2.1. > > The next question is whether there will be support > for the > ActionClass-method-validatation idiom. (Is there > still support?) > > * https://issues.apache.org/struts/browse/WW-1018 > > (After commenting here, I began to rethink how > strongly we should > support multiple aliases.) > You mean support for the "!" in validation file names? I agree that can go... As for context-specific validations, that needs to stay. It's one of my requirements for the framework, and one of the requirements I'm bringing with me to JSR-303. > > Me too. I think when we use multiple alaises, using > multiple stacks is > a sane approach. It dodges using "magic" names to > skip validation. > Though, it doesn't provide a way to validate a > specific method, unless > we use Java or the ActionClass-method-validator idiom > It doesn't have to do with the method, though... It has to do with the logical function that your endpoint is executing, whether it's for a web page or behind a XMLRPC front end, etc. I might map 3 different action aliases to an empty execute() method just to get different interceptor stacks applied. > This sort of special-case handling is why I'm leaning > toward > one-method per Action. All the commands have a full > array of extension > points, without any smoke or mirrors. > It leads to too many classes in practice, and removes a key functionality that WebWork users depend on. > In the end, the complexity has to live somewhere. > With > she-bang-magic-methods, it was living in the > framework, creating a lot > of special-case code, and creating security issues. > With > multiple-methods, the complexity moves to swapping > stacks and maybe > doing some validations outside for the framework. > With single-method, > the complexity moves to creating more classes. > Ok, so it's about managing complexity. The problem with the "!" notation was that the complexity was too much and we could never find all of the issues with it, so one would crop up now and again. With the multiple aliases, the complexity (right now) is on the user to manage their configuration, but that could be lessened with wildcards and conventions. With single method actions, you have to have lots of classes, and there's no opportunity for improvement. If you take out the "!" notation, you're left with the other 2 options, and users can choose whichever they like. Multiple method aliases doesn't preclude you from having a one-to-one mapping for actions -> action aliases. --------------------------------------------------------------------- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=78102#78102 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
