Hello, On Wed, 2006-04-19 at 18:22 -0700, Michael Jouravlev wrote: > 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.
The urls are mapped to the Action classes via the action mapping in the xwork.xml config file, as you noted. but webwork's action tag has a "method" attribute that will call any method you'd like on the Action instance. So you could call the same Action from two different mappings, each mapping calling a different method, which could describe a different work flow. > 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. You can do this in webwork if you want, i think the advantage to the interceptor concept is that if you use a couple of different work flows in an application, by defining a interceptor stack you can avoid the hassle of rewriting the plumbing in each action that uses that work flow. > 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? Same as above, you can call them if you want, but the interceptor stacks allow you to define and reuse work flows. To restate, I am just learning all this, but i have rewritten several of my existing struts apps in my head, and it all seems much cleaner so far. Dave > [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
