Wow - this would make life so much easier - I want this stuff! :) -mike
On 30/12/02 7:31 PM, "Rickard Öberg" ([EMAIL PROTECTED]) penned the words: > Patrick Lightbody wrote: >> In your last email you talked about changes in the context and pre/post >> processing. I think I know what you are hinting at (simply the ActionFactory >> and move the work in the Action implementation itself), but maybe you can go >> in to more detail here? Also, how could it be an alternative way of >> chaining? > > As I've been working a LOT with AOP lately some of the ideas could be > easily applied here too. One of the ideas is the generic "interceptor > chain", i.e. to chain a bunch of proxies together and start it by simply > invoking the first. > > For example: > Action myAction = ActionFactory.getAction("foo"); > myAction.execute(); > --- > Action getAction(String name) > { > return new SecureAction(new ChainAction(new FooAction())); > } > --- > public class SecureAction > extends ActionProxy > { > public SecureAction(Action nextAction) > { > this.next = nextAction; > } > > public String execute() > throws Exception > { > // Do security check > > // Delegate to next > return next.execute(); > } > } > --- > I hope the basic idea is obvious. Some chaining could be done by simply > having proxies do stuff either before or after the execute() invocation. > Having such things be proxies instead of actions separates them from > real actions as they should typically not influence the result string > (i.e. they have side-effects but don't effect the flow). Of course, just > as servlet filters *can* return immediately instead of delegating to the > next servlet, proxies can shortcut the flow here too (the SecureAction > would be one example, which would return "unauthorized" if the executor > is not allowed to call the action. > > The ChainAction would be used to transfer parameters when a chain is > executing. Like so: > ThreadLocal previousAction = new ThreadLocal(); > public String execute() > throws Exception > { > Object previous = previousAction.get(); > if (previous != null) > // Copy parameters from previous to current > > previousAction.set(<currentTargetAction>); > > try > { > return next.execute(); > } finally > { > if (previous != null) > previousAction.set(previous); > } > } > --- > This would allow the action itself to call other actions in its > execute() method and have parameters be transferred transparently: > public String execute() > throws Exception > { > Action myAction1 = ActionFactory.getAction("foo1"); > Action myAction2 = ActionFactory.getAction("foo2"); > myAction1.execute(); > myAction2.execute(); > > return SUCCESS; > } > -- > Both the above actions would have secured execution (thanks to > SecureAction) and copied parameters from the "parent", and with very > little work. The action can then also decide whether to ignore what they > return, or to return SUCCESS iff all actions succeed. A helper can > easily run them in parallel. Etc. There are LOTS of possibilities here, > but the main point is that the code would be very clean. > > And, the "old way" to do "augmented actions" was to do a subclass and > override execute(), do stuff (e.g. security checks), then do > super.execute() which in turn could do things, and finally call > doExecute(). That is (obviously?) a rather cumbersome, static, and > generally boring way to do things, and I think using action proxy chains > would be both easier and more dynamic. Plus, they could be configured in > XML instead of specified explicitly through inheritance. > > And, once you get into runtime attributes (which I have, courtesy of the > AOP framework I'm fiddling with) it gets even cooler, because then you > can configure the chain by using attributes. Like so: > /** > * @attributes > * filters=secure,chain,validation > * success=blah.vm > * error=failure.vm > */ > --- > And if you feel like the above is providing too much info in code then > simply introduce pre-packaged stacks: > <config> > <filters name="standard"> > <filter name="secure"/> > <filter name="chain"/> > <filter name="validation"/> > </filters> > </config> > along with the runtime attribute definition: > /** > * @attributes > * filters=standard > */ > > (BTW, I can *guarantee* you that before long we're going to see runtime > attributes being pushed into IDE's rather than having them as Javadoc, > so it's going to be really truly awesome) > > and if you want to go really funky then redefine stacks like so: > <config> > <filters name="standard"> > <filter name="mycustomfilter"/> > <filters name="defaultstandard"/> > </filters> > > <filters name="defaultstandard"> > <filter name="secure"/> > <filter name="chain"/> > <filter name="validation"/> > </filters> > </config> > > and without changing any code/javadoc you just changed the way all > actions that use the "standard" filter stack works. Pretty neat. > >> Have you had a chance to look at the code in sandbox, especially >> the ActionFactory stuff as well as the chaining/view stuff? > > I've had trouble checking it out (SF has barfed all the time), but I > *just* got it. Will look through today (I have the day off). > >> (I started a new thread on this just so that we can keep track of the >> various topics) > > (Good idea) > > /Rickard > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork