OK, I've been lurking on this list for some time, so nobody here knows me,
but I do want to weigh in on this issue on Jason's side. I'm relatively new
to WebWork, using it for a new Web application project started in March. I
was responsible for evaluating the various frameworks available, then
setting up the core design practices and training the rest of the team.
We have made extensive use of the CRUD Action pattern - easily the bulk of
the code for the app administration and configuration components. It made a
great deal of sense to me and the other developers - a common set of data
with a small number of closely-related operations on that data. Pretty much
the definition of an object. Seemed cleaner than extending that same class
two or three or four times just to override execute().
I realize this capability could be dangerous in the wrong hands. ;-) Our
standard is to only use this pattern when all the actions use the same
domain object(s) and back the same basic view. I think this still satisfies
the Single Responsibility Principle, because there is little or no risk of
breaking other app components if you have to update a method in this Action
class. More likely is that a feature change or bug fix will impact the
entire Action anyway.
We have thus far avoided the whole wild-card capability completely, both in
action definitions and in validation. Stars and bangs and brackets - oh my!
Had the feel of getting dangerously clever, at least for a newbie group just
learning its way around the framework. I can't speak to which parts of that
work and really make life easier (yet). Besides, it wasn't documented in
Jason & Patrick's book. :-) (Where, BTW, the CRUD action approach is
described in the chapter 'Best Practices,' so it's always been clear where
they stand on that. Maybe I've been brainwashed...)
We have run into a couple of validation cases where an
ActionClass-Method-validation.xml would get us into a bit of trouble, for
example when calling 'save()' on a new User vs. an existing User. In this
case, we defined two actions ('saveUser' and 'saveNewUser') that mapped to
the same method and used the ActionClass-actionName-validation.xml. True, it
wouldn't have been much harder to define two methods, one of which simply
delegated to the other. Seems like a basic Java vs. XML trade-off.
Still, I favor using the action name because the idea is that the validation
framework is externalized. If you have to make code changes - new no-op
methods or even new no-op class extensions - just to provide hooks for your
validation framework, then it really isn't very externalized, is it?
Defining a new action in XML is in many ways the equivalent of a code
change, but as Jason pointed out the action represents the logical app
operation and may include different interceptors and other decorations in
addition to validation. Mapping multiple actions to the same method is a
convenience in the case where new decorations are sufficient to handle all
needed functional changes. The whole point of decorations is to change the
behavior of a class without having to modify the class itself, right?
Not sure my opinion is yet worth a full $.02, but there it is. :-) BTW,
thank you all for your hard work. I was REALLY impressed that you committed
to merging Struts and WebWork back together. Resolving honest differences of
opinion and healing schisms is much harder than writing code. It is
appreciated.
Jay
--------
Jay H. Hartley, Ph.D.
Senior Software Engineer/Architect
Modius, Inc.
> -----Original Message-----
> From: Jason Carreira [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 04, 2006 6:38 AM
> To: dev@struts.apache.org
> Subject: Re: [s2] Validation
>
> > 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&mess
> ageID=78102#78102
>
>
> ---------------------------------------------------------------------
> 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]
