While I agree that multiple aliases is a good approach, chaining is not.
Chaining has the unfortunate effect of spreading business logic over
many configuration files which is a Bad Thing(tm).  It also puts some of
the core business logic into configuration files rather than the
actions.  It also makes it difficult to use other people's packages if
we happen to share common names that mean different things.

Ok, you've worn me down.  I don't agree that shoehorning is the right
approach, but I'll relent and simply agree to disagree.

--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/


> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Jason Carreira
> Sent: Saturday, February 22, 2003 7:04 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] XWork: calling Actions from Actions
> 
> Your example is better handled by different alias's with action
chaining
> as the result.
> 
> > -----Original Message-----
> > From: Matt Ho [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, February 22, 2003 3:57 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [OS-webwork] XWork: calling Actions from Actions
> >
> >
> > Here's a specific case:
> >
> > A reservation system has the following actions, create,
> > modify, cancel, and lookup a reservation.  All of which
> > reasonably have views.  The modify view, however, can be
> > created as a composite using the other three views.
> >
> > Just like WW1.x allows me to embed actions within a page
> > (even if they have views defined), so do I think that WW2.x
> > should allow actions to be called from actions without
> > additional configurations.
> >
> > My proposal is this:
> >
> > * add a scope="..." to the interceptor where ... may be
> > either request or action.
> > * by default all interceptors are scoped action (essentially
> > the current
> > behavior)
> > * actions scoped as "request" are only executed on the outer
> > action call
> >
> > If there's agreement, I'm more than happy to write this.
> >
> > --
> > Matt Ho
> > Principal
> > Indigo Egg, Inc.
> > http://www.indigoegg.com/
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]
> > On Behalf Of
> > > Jason Carreira
> > > Sent: Friday, February 21, 2003 9:37 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [OS-webwork] XWork: calling Actions from Actions
> > >
> > > Or just one without the ResultInterceptor
> > >
> > > > -----Original Message-----
> > > > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]
> > > > Sent: Saturday, February 22, 2003 12:34 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [OS-webwork] XWork: calling Actions from Actions
> > > >
> > > >
> > > > My answer to this is, rather than complicate xwork, why not just
> > > > recommend that "actions-within-actions" not utilize actions that
> > > > have views associated with them?
> > > >
> > > > If you want to re-use two action _classes_, just make two
aliases
> > > > for the same class, one that has the view and one that is used
> > > > internally.
> > > >
> > > > -Pat
> > > >
> > > > ----- Original Message -----
> > > > From: "Matt Ho" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Friday, February 21, 2003 9:07 PM
> > > > Subject: RE: [OS-webwork] XWork: calling Actions from Actions
> > > >
> > > >
> > > > > There's another issue too to consider that Patrick just
> > > > pointed out.
> > > > > Because the page is rendered by the ResultInterceptor,
> > calling an
> > > > > action from an action means that if the inner action has a
> > > > view, that
> > > > > view will be rendered first and then the outer view will be
> > render.
> > > > >
> > > > > We may want to consider giving Interceptors scope.  A logic
> > > > set would
> > > > > be action scope and request scope so that 1 request may
> > > > have multiple
> > > > > actions.  The ResultInterceptor could then be placed in
> > the result
> > > > > scope.
> > > > >
> > > > > Having the ResultInterceptor in the action scope is
> > going to make
> > > > > creating actions via composition difficult.
> > > > >
> > > > > --
> > > > > Matt Ho
> > > > > Principal
> > > > > Indigo Egg, Inc.
> > > > > http://www.indigoegg.com/
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [EMAIL PROTECTED]
> > > > > > [mailto:[EMAIL PROTECTED]
> > > > On Behalf
> > > > > > Of Jason Carreira
> > > > > > Sent: Friday, February 21, 2003 8:43 PM
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: RE: [OS-webwork] XWork: calling Actions from
Actions
> > > > > >
> > > > > > You do this:
> > > > > >
> > > > > > ActionInvocation.java
> > > > > >
> > > > > > private ActionContext parentContext;
> > > > > >
> > > > > > ...
> > > > > >
> > > > > >     private void init() throws Exception {
> > > > > >         ...
> > > > > >
> > > > > >   parentContext = ActionContext.getContext();
> > > > > >         ActionContext context = new
ActionContext(contextMap);
> > > > > >         ActionContext.setContext(context);
> > > > > >
> > > > > >         ...
> > > > > >     }
> > > > > >
> > > > > >     public String invoke() throws Exception {
> > > > > >         ...
> > > > > >
> > > > > >         if (parentContext != null) {
> > > > > >             ActionContext.setContext(parentContext);
> > > > > >         }
> > > > > >
> > > > > >         return result;
> > > > > >     }
> > > > > >
> > > > > > Which should reset the ActionContext if it was nested.
> > > > > >
> > > > > > My only question here is, which Servlet containers
> > > > pooling threads,
> > > > > will
> > > > > > we get phantom ThreadLocals left over that get reset
> > after the
> > > > > > Action
> > > > > is
> > > > > > invoked? Also, if how can we reset the ActionContext at the
> > right
> > > > > spot?
> > > > > > If we do it right after the Action is executed, then the
> > > > > > Interceptors, on the way back out, in their after() methods,
> > will
> > > > > > have the wrong ActionContext.
> > > > > >
> > > > > > Jason
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Matt Ho [mailto:[EMAIL PROTECTED]
> > > > > > > Sent: Friday, February 21, 2003 11:12 PM
> > > > > > > To: [EMAIL PROTECTED]
> > > > > > > Subject: RE: [OS-webwork] XWork: calling Actions
> > from Actions
> > > > > > >
> > > > > > >
> > > > > > > Without a lock or other reference, how do you know
> > that you're
> > > > > > > executing the inner action rather than the outer action?
> > > > > > >
> > > > > > > --
> > > > > > > Matt Ho
> > > > > > > Principal
> > > > > > > Indigo Egg, Inc.
> > > > > > > http://www.indigoegg.com/
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [EMAIL PROTECTED]
> > > > > > > >
[mailto:[EMAIL PROTECTED]
> > > > > > > On Behalf Of
> > > > > > > > Patrick Lightbody
> > > > > > > > Sent: Friday, February 21, 2003 8:01 PM
> > > > > > > > To: [EMAIL PROTECTED]
> > > > > > > > Subject: Re: [OS-webwork] XWork: calling Actions from
> > Actions
> > > > > > > >
> > > > > > > > We don't need locks, we just need ActionInvocation to
> > > > keep track
> > > > > of
> > > > > > > the
> > > > > > > > old
> > > > > > > > ActionContext associated with the thread, and when an
> > > > action is
> > > > > done
> > > > > > > being
> > > > > > > > executed, re-set it. I'll make sure that
> > > > Actions-within-Actions
> > > > > > > > is supported properly.
> > > > > > > >
> > > > > > > > -Pat
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Matt Ho" <[EMAIL PROTECTED]>
> > > > > > > > To: <[EMAIL PROTECTED]>
> > > > > > > > Sent: Friday, February 21, 2003 7:53 PM
> > > > > > > > Subject: RE: [OS-webwork] XWork: calling Actions from
> > Actions
> > > > > > > >
> > > > > > > >
> > > > > > > > > Here's a simple sequence diagram to help illustrate
> > > > the issue:
> > > > > > > > >
> > > > > > > > >         MyAction     AnotherAction
> > > > > > > > >             |              |
> > > > > > > > >             |              |
> > > > > > > > > exectute -->O              |  --- A
> > > > > > > > >             O              |
> > > > > > > > >             O-- execute -->O  --- B
> > > > > > > > >             O              O
> > > > > > > > >             O              O
> > > > > > > > >             O<-------------O  --- C
> > > > > > > > >             O              |
> > > > > > > > >             O              |  --- D
> > > > > > > > >             |              |
> > > > > > > > >             |              |
> > > > > > > > >
> > > > > > > > > With the current implementation of ActionContext as a
> > > > > ThreadLocal,
> > > > > > > if
> > > > > > > > > you attempt to call an action from within an
> > action, life
> > > > > > > works well
> > > > > > > > > until step C.  Because step B sets the ActionContext,
> > > > > > > when control
> > > > > > > > > returns to MyAction at point C, the ActionContext
> > > > is not what
> > > > > you
> > > > > > > > > expect.
> > > > > > > > >
> > > > > > > > > Setting up the ActionContext during the invoke() could
> > work:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >     private static ThreadLocal lock ;
> > > > > > > > >
> > > > > > > > >     static {
> > > > > > > > >         lock = new ThreadLocal() ;
> > > > > > > > >         lock.set(new Lock()) ;
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > >     public static class Lock {
> > > > > > > > >         private boolean locked = false;
> > > > > > > > >
> > > > > > > > >         private boolean acquired() {
> > > > > > > > >             if( !locked ) {
> > > > > > > > >                 return true;
> > > > > > > > >             } else {
> > > > > > > > >                 return false;
> > > > > > > > >             }
> > > > > > > > >         }
> > > > > > > > >
> > > > > > > > >         private void release() {
> > > > > > > > >             locked = false;
> > > > > > > > >
> > > > > > > > >         }
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > >     public void invoke() throws Exception {
> > > > > > > > >         Lock lock = (Lock)lock.get() ;
> > > > > > > > >         boolean haveLock = lock.acquire() ;
> > > > > > > > >
> > > > > > > > >         if( haveLock ) {
> > > > > > > > >           // nest storage
> > > > > > > > >         }
> > > > > > > > >
> > > > > > > > >         try {
> > > > > > > > >            ... execute my action
> > > > > > > > >         } finally {
> > > > > > > > >            lock.release() ;
> > > > > > > > >         }
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Matt Ho
> > > > > > > > > Principal
> > > > > > > > > Indigo Egg, Inc.
> > > > > > > > > http://www.indigoegg.com/
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From:
[EMAIL PROTECTED]
> > > > > > > > > >
> > > > [mailto:[EMAIL PROTECTED] On
> > > > > > > Behalf Of
> > > > > > > > > > Jason Carreira
> > > > > > > > > > Sent: Friday, February 21, 2003 7:18 PM
> > > > > > > > > > To: [EMAIL PROTECTED]
> > > > > > > > > > Subject: RE: [OS-webwork] XWork: calling Actions
from
> > > > > > > > > > Actions
> > > > > > > > > >
> > > > > > > > > > So it would nest it during init and unnest at
> > the end of
> > > > > invoke,
> > > > > > > or
> > > > > > > > > > when?
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Patrick Lightbody
[mailto:[EMAIL PROTECTED]
> > > > > > > > > > > Sent: Friday, February 21, 2003 8:05 PM
> > > > > > > > > > > To: [EMAIL PROTECTED]
> > > > > > > > > > > Subject: Re: [OS-webwork] XWork: calling
> > Actions from
> > > > > Actions
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Couldn't ActionInvocation just do nested storage
of
> > the
> > > > > > > > > > > ActionContext, just like GenericDispatcher did?
> > > > > > > > > > >
> > > > > > > > > > > -Pat
> > > > > > > > > > >
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Jason Carreira" <[EMAIL PROTECTED]>
> > > > > > > > > > > To: <[EMAIL PROTECTED]>
> > > > > > > > > > > Sent: Thursday, February 20, 2003 12:20 PM
> > > > > > > > > > > Subject: RE: [OS-webwork] XWork: calling
> > Actions from
> > > > > Actions
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Patrick, this came up while you were gone.
> > > > Did you have
> > > > > any
> > > > > > > > > > > thoughts
> > > > > > > > > > > > on this? In order to be able to do this
> > easily, we'd
> > > > > > > > > > > > need
> > > > > > > > > > > to pull the
> > > > > > > > > > > > ActionContext initialization out of the
> > > > ActionInvocation
> > > > > > > > > > > > initialization, so you can use one ActionContext
> > > > > > > for multiple
> > > > > > > > > > > > invocations. Matt didn't like the option where
you
> > do:
> > > > > > > > > > > >
> > > > > > > > > > > > ActionContext myContext =
> > ActionContext.getContext();
> > > > > > > > > > > ActionInvocation
> > > > > > > > > > > > anotherInvocation = new
> > > > > > > > > > > >
ActionInvocation("someNamespace","anotherAction");
> > > > > > > > > > > > String otherResult = anotherInvocation.invoke();
> > > > > > > > > > > > ActionContext.setContext(myContext);
> > > > > > > > > > > >
> > > > > > > > > > > > Which would be needed to save the current
context,
> > > > > > > then re-set
> > > > > > > it
> > > > > > > > > > > > after invoking the other action... This is not
> > really
> > > > > > > > > > > pretty, but as
> > > > > > > > > > > > I'm thinking about it, it could be a helper
method
> > in
> > > > > > > > > > > ActionSupport...
> > > > > > > > > > > >
> > > > > > > > > > > > Jason
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > -------------------------------------------------------
> > > > > > > > > > > This SF.net email is sponsored by: SlickEdit
> > > > Inc. Develop
> > > > > > > > > > > an edge. The most comprehensive and flexible
> > > > code editor
> > > > > > > > > > > you
> > > > > can
> > > > > > > > > > > use. Code faster. C/C++, C#, Java, HTML, XML, many
> > more.
> > > > > FREE
> > > > > > > > > > > 30-Day Trial. www.slickedit.com/sourceforge
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Opensymphony-webwork mailing list
> > > > > > > > > > > [EMAIL PROTECTED]
> > > > > > > > > > >
> > > > > > >
> > > >
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > -------------------------------------------------------
> > > > > > > > > > This SF.net email is sponsored by: SlickEdit Inc.
> > > > > > > Develop an edge.
> > > > > > > > > > The most comprehensive and flexible code
> > editor you can
> > > > > > > use. Code
> > > > > > > > > > faster. C/C++, C#, Java, HTML, XML, many more. FREE
> > 30-Day
> > > > > > > Trial.
> > > > > > > > > > www.slickedit.com/sourceforge
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Opensymphony-webwork mailing list
> > > > > > > > > > [EMAIL PROTECTED]
> > > > > > > > > >
> > > > > > > https://lists.sourceforge.net/lists/listinfo/o>
> > > > > > > pensymphony-webwork
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
-------------------------------------------------------
> > > > > > > > > This SF.net email is sponsored by: SlickEdit
> > Inc. Develop
> > > > > > > an edge.
> > > > > > > > > The most comprehensive and flexible code editor you
can
> > use.
> > > > > Code
> > > > > > > > > faster. C/C++, C#, Java, HTML, XML, many more.
> > FREE 30-Day
> > > > > > > Trial.
> > > > > > > > > www.slickedit.com/sourceforge
> > > > > > > > > _______________________________________________
> > > > > > > > > Opensymphony-webwork mailing list
> > > > > > > > > [EMAIL PROTECTED]
> > > > > > > > >
> > > > >
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------
> > > > > > > > This SF.net email is sponsored by: SlickEdit Inc.
Develop
> > > > > > > an edge. The
> > > > > > > > most comprehensive and flexible code editor you can use.
> > > > > > > Code faster.
> > > > > > > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day
Trial.
> > > > > > > > www.slickedit.com/sourceforge
> > > > > > > > _______________________________________________
> > > > > > > > Opensymphony-webwork mailing list
> > > > > > > > [EMAIL PROTECTED]
> > > > > > > >
> > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwor
> > > > > > > > k
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------
> > > > > > > This SF.net email is sponsored by: SlickEdit Inc.
> > > > Develop an edge.
> > > > > > > The most comprehensive and flexible code editor you can
> > > > use. Code
> > > > > > > faster. C/C++, C#, Java, HTML, XML, many more. FREE
> > > > 30-Day Trial.
> > > > > > > www.slickedit.com/sourceforge
> > > > > > > _______________________________________________
> > > > > > > Opensymphony-webwork mailing list
> > > > > > > [EMAIL PROTECTED]
> > > > > > >
> > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webw
> > > ork
> > > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.net email is sponsored by: SlickEdit Inc.
> > Develop an edge.
> > > > > The most comprehensive and flexible code editor you can
> > use. Code
> > > > > faster. C/C++, C#, Java, HTML, XML, many more. FREE
> > 30-Day Trial.
> > > > > www.slickedit.com/sourceforge
> > > > > _______________________________________________
> > > > > Opensymphony-webwork mailing list
> > > > > [EMAIL PROTECTED]
> > > > >
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: SlickEdit Inc. Develop an
edge.
> > The
> > >
> > > > most comprehensive and flexible code editor you can use. Code
> > faster.
> > > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > > > www.slickedit.com/sourceforge
> > > > _______________________________________________
> > > > Opensymphony-webwork mailing list
> > > > [EMAIL PROTECTED]
> > > >
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SlickEdit Inc. Develop
> > an edge. The
> > > most comprehensive and flexible code editor you can use.
> > Code faster.
> > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > > www.slickedit.com/sourceforge
> > > _______________________________________________
> > > Opensymphony-webwork mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SlickEdit Inc. Develop
> > an edge. The
> > > most comprehensive and flexible code editor you can use.
> > Code faster.
> > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > > www.slickedit.com/sourceforge
> > > _______________________________________________
> > > Opensymphony-webwork mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc. Develop an
> > edge. The most comprehensive and flexible code editor you can
> > use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE
> > 30-Day Trial. www.slickedit.com/sourceforge
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork




-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to