On 8/3/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
Either way, you're still talking about multiple aliases for one class, which is what Ted was saying we should deprecate.
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.
For how it's done... Well, I hate the "!" notation... We've had to
jump through a lot of
hoops to support it and it still bites us every now and again. Plus,
it's just a security hole,
plain and simple.
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.)
I like the idea of wildcards, and I'd like to be able to specify certain wildcard patterns that can be used across many paths and specify interceptor stacks to go with them: /entity/*/list -> listStack /entity/*/edit -> editStack and then /entity/invoice/list would match the first wildcard and have the specific listStack applied.
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 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. 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. -Ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
