struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Evans <dsev...@berndtgroup.net>
Subject Re: How to execute code in an Action when ActionForm validation fails?
Date Thu, 20 Apr 2006 00:53:28 GMT
On Tue, 2006-04-18 at 13:23 -0500, Eric Rank wrote:
> Thanks Rick,
<snipped>
> Thanks for your feedback! I'm curious about this chaining and
> interceptor business too. What's it all about?
> 
> Eric Rank

I'm just getting started with Webwork and so am no expert, but here's a brief description
of the interceptor business. :)

So in struts a requests workflow is controlled by the
RequestProcessor.process() method. And simplified it does something like
this:
1. get path
2. get mapping from path
3. populate form bean
4. validate form bean
5. call execute method on action
6. process forward result

Because struts has this all in a single method, hard coded in the above
order, the workflow for struts is more or less predetermined. And so to
get around it you had the two choices of extending RequestProcessor and
overriding the calls in the process method, or just turning off the
validation part of the flow and handling it yourself. 

In Webwork, the action config has a subelement that points to a
interceptor reference, which may be a single interceptor, or collection
of them called a "stack".  The interceptor is a class that wraps itself
around the actions execution, like a filter, only it has access to the
action itself. It can have functionality both before and after the
action execute. So the populate and validate functionality of the
RequestProcessor is implemented in Webwork as two interceptors, called
params and workflow. For any particular action you can, in the main
config file, configure which interceptors will be called and in what
order.  Webwork also uses a set of flagging interfaces that when
implemented mark an action as having special functionality that an
interceptor can make use of. In the case of the workflow interceptor, it
looks to see if the action implements a Validateable interface, which
contains a single method, "validate". If so, it calls that method. It
also looks to see if the action implements a second interface
ValidationAware. If so, and there were errors in validation, the
workflow interceptor shortcircuits the execution and forwards to the
input. So this behaves just like struts, except that you have more fine
grained control on a action by action basis. There is another
interface/interceptor pair called Preparable/prepare. This one lets you
run a prepare method in your action, and in the default interceptor
stack, this one comes before the params and workflow interceptors. So
all of the setup that you need for the elements of the form can be
placed in the prepare method, so that even if validation fails, the form
still has its elements correctly setup. 

So thats an overview from a Webwork newbie. I'm halfway through Webwork
in Action, and am starting my first Webwork application, and i have to
say, I'm really excited, and i think using Webwork is going to make life
much easier. And the book is very well written.

Dave

On Tue, 2006-04-18 at 13:23 -0500, Eric Rank wrote:
> Thanks Rick,
<snipped>
> Thanks for your feedback! I'm curious about this chaining and
> interceptor business too. What's it all about?
> 
> Eric Rank
> 
> 
> 
> On 4/18/06, Rick Reumann <rickcr@gmail.com> wrote:
> > On 4/18/06, Eric Rank <flakie@gmail.com> wrote:
> >
> > > From reading a bit on Rick Reumann's site
> > > (http://www.learntechnology.net/validate-manually.do)
> > > a simple way to handle this is to call the validate method within the
> > > execute method of the Action. There's a bit of logic that has to be
> > > processed in order to capture errors, but it works pretty well.
> > > However, I personally feel like it could lead to some sloppy "execute"
> > > code.
> >
> > Just curious what you think might be sloppy? One of struts biggest
> > weaknesses is in the validation side of things. I just happen to
> > prefer a consistent approach that is easy to understand, easy to
> > debug, and easy to code - hence I call validation manually from my
> > Action and don't ever use validate="true" in my action mapping.
> >
> > Extending the request processor in my opinion is a bad idea. One of
> > the main reasons is it becomes very difficult for someone coming on to
> > your project to figure out what is going on, since it's not typical to
> > have to mess with that class. Obviously you have a lot of power if you
> > want to start messing with that class, but I avoid it.
> >
> > I haven't been following the latest Struts 1.3 stuff as closely as I'd
> > like so maybe someone else has some ideas that could help since I
> > think they've introduced more interceptor/chain types of things that
> > could aid in what you want. (Then again, I'm still not convinced all
> > this injection stuff is all it's cracked up to be. The trend seems to
> > be to make things so loosely coupled to the point that it's confusing
> > to often figure out 'what is causing' what to occur. It gets annoying
> > in my opinion to have to keep searching through different xml files to
> > figure out what is going on </rant>).
> >
> > --
> > Rick
> > http://www.learntechnology.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message