struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jouravlev" <>
Subject SAF2 interceptors/interfaces vs. explicit method calls (was: How to execute code in an Action when ActionForm validation fails?)
Date Thu, 20 Apr 2006 01:22:09 GMT
Dave, thanks for explanation. Now, can you explain this: how URLs are
mapped to actionbeans in WebWork? Looking at the example [1] on
OpenSymphony website, I see the same pattern as in SAF1:

<action name="helloWorld" class="example.helloworld.HelloWorld">

The above means, that http://somesite/helloWorld.action will be
dispatched to HelloWorld actionbean. The same as in SAF1. So, we have
a location that a user can type in the browser, and the endpoint.
One-to-one relationship, which theoretically can be changed, but I
believe is done as rarely as in SAF1 apps, that is, almost never.

Now, if I know exactly which action bean will be called in respond to
a certain URL, what is the point in all these interceptors and
interfaces? Is not it easier to call something like


from an action bean? Why should I go through pain of configuring
interfaces instead of having a simple one-liner? I will not break
apart from typing one or two or even five lines of code, but my code
will be readable by me or everyone else. Instead of checking what
Validatable interface does, one would see a call to validate() method.

I want to be able to call *all and every* lifecycle and service
methods directly instead of implementing interfaces (of course, they
lifecycle methods should be well documented). For example, instead of
autopopulation I would prefer to call bean.populate() explicitly when
I consider it appropriate.

Same with interceptors. If the endpoint is known, what is the benefit
in interceptors vs. explicit call of one-two-three methods from an


On 4/19/06, David Evans <> wrote:
> 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

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

View raw message