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"> ... </action> 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 populate(); validate(); prepare(); 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 actionbean? [1] http://www.opensymphony.com/webwork/wikidocs/Basic%20configuration%20and%20your%20first%20action%20-%20Hello%20WebWorld.html On 4/19/06, David Evans <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
