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 <[EMAIL PROTECTED]> wrote: > > On 4/18/06, Eric Rank <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > 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]