Ted Husted wrote:
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 many Struts projects I worked on we deliberately modified the
functionality to use methods off the same class, and it was one of the
reasons that I liked webwork so much. I think it is elegant that you
can use one action class for all/most of the CRUD calls, and the
interceptors allow for applying / disallowing validation based on the
standard method names being used.
The reasons you list above would make sense for having some "best
practices" for when to use each method, but I wouldn't go as far as
saying that it is "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?
In a large project there are usually several large divisions, these can
then be split into many sub-divisions. Sometimes even further divisions
can be made. This is much the same way I use class hierarchies - not
too flat, not too deep. Additionally, I find it sometimes useful to add
sub-packages for actions that return responses from AJAX calls. I guess
this could be called syntactic sugar, but it is good to isolate the
URL's and sometimes I want to keep them together rather than have a
generic "all-ajax" package.
Wildcards would definitely assist, but I think we should still account
for nested packages.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
