struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: [s2] Validation
Date Thu, 03 Aug 2006 15:00:17 GMT
On 8/3/06, Ian Roughley <> 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?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message