On 8/3/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
This is actually a feature that I like in WW/SAF, granted som times is makes more sense to use it than others, but that is always going to be a design decision. Can you further explain why you have come to the conclusion that they are not good practice?
The "advanced" (but indispensible) features of the framework are designed to follow the class hierarchy. We've put in (a lot of) special-case handling to accomodate multiple alaises, but the architectural grain is that a logical action is mapped to a Java class with a single entry point, and the validations, messaging, and type converters are all designed to attach to the class. The first thing that happens when we start using multiple aliases is that we want different validations, messages, or type converters for this alias or that alias. For example, we have special-case handling for several magic aliases to keep validation from firing on "input" and "cancel", and so forth. The cannonical approach would be to have an Input class and a Cancel class, so that they do not inherit validators from some other action. With modern IDEs and modern JDKs, maintaining a class for each action does not seem so great a burden. Maintaining a set of very similiar and largely redundant mappings is a burden, but given wildcards and other features, we can "normalize" the mappings so that we can program-by-difference within the configuration, just as we do with Java classes. I'm not suggesting that try to make it impossible to use multiple alaises. But I am suggesting that the Struts 2 group should recognize that multiple aliases are not a recommended practice, in the same way that chaining actions are not a recommended practice.
In webwork I make use of nested packages.
Could you explain a bit more about why this is a good practice? Is it synantic sugar, or is the practice providing utility that is not feasible with unnested packages? -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
