This is effectively what I had been doing with action chaining in WebWork
1.3, but in a much more cumbersome and slower (lots of objects being
created). I'd have things like BeginTx and CommitTx being "wrapped" around
the meat of my actions. Very similar to AOP in concept, I suppose, since
they acted as interceptors. Only problem was I wasn't really intercepting, I
was specifically making each chain by hand :(
-Pat
----- Original Message -----
From: "matt baldree" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 30, 2002 2:09 AM
Subject: Re: [OS-webwork] context and pre/post processing
> FWIW, I like this idea. I would like to see XWork capture some of
Rickard's
> latest ideas especially AOP.
>
> -Matt
>
> ----- Original Message -----
> From: "Rickard Öberg" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 30, 2002 2:31 AM
> Subject: Re: [OS-webwork] context and pre/post processing
>
>
> > 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
-------------------------------------------------------
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
