This is the same as my ActionMultiplexer thing that I wrote.
Basically I have created a DefaultActionForm class with a `action' property.
Ditto created `AppBaseAction' and `AppActionServlet' and these two
know about each other.

The way Struts 1.0 is that the ActionForm bean is populated from 
request.getParameter().
Of course if you multiplex [ call an action from another action ] you can have problems
because the Java Servlet 2.2 specs does not have mutable reguest.,getParameters().
So I had to cheat in my AppActionServlet to make it look in the
`request.getAttributes( button_name )'
first if there is no value set then `request.getParameter( button_name )'.

This is how I got around the action form properly. It is the only way because Struts
is simply using the standard Java Servlet API for request.getRequestDispatcher()
when you call `return mapping.findForward( ... );'

I think you have two choices Ted:

1)  Go through the request.getRequestDispatcher() API
(This is more consistent with Suns API, so I choose this option)

2) Fake it, dont go throught the request dispatcher, call the action directly.
Therefore find the Action in the ActionMappings and then create the Bean
as a normal newInstance() and call processAction() directly. May be I am
not making a lot sense here.

In either case you may to do I have done prioritise bean population
request.getAttribute and request.getParameter().

Say if you want to override the action command before you forward to the sub action
you do as you would with the request dispatcher API.

request.setAttribute( "action",  "promptForm" );
mapping.findForward( "dispatch-dvd-order" );

Whatever action and action form "dispatch-dvd-order" invoke would cause
the action form bean, for sake of argument "DvdOrderForm", property "action" to be
set with "promptForm" (provided of course it has accessor/mutator

DVDActionForm extends DefaultActionForm {
String action="";
String getAction() { .... }
void setAction(String) { ... }
}

--
Peter Pilgrim                 ++44 (0)207-545-9923
                                                      //_\\
"Mathematics is essentially the study of islands of  =======
disparate subjects in a sea of ignorance."           || ! ||
Andrew Wiles _____________


---------------------------------------- Message History 
----------------------------------------


From: Ted Husted <[EMAIL PROTECTED]> on 06/12/2001 19:51 EST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Re: action chaining without resetting action forms


When you forward to a JSP, the original ActionForm and ActionMapping are
left alone.

As it stands, when you forward to another Action, the ActionServlet uses
the same processing cycle it used for the first Action. If an ActionForm
is specified by the mapping, the ActionServlet will try to populate it.
It will also put the mapping for the second Action into the request,
obliterating any trace of the original Action. As far as your
"ViewAction" knows, it is the one and only Action that has been called.

If your response-Action is using its own data structures, and is not
looking for the Struts ActionForm or ActionMapping in the request, or is
hiding them in delegates, then you are all set.

Of course, if it is not using the ActionForm or ActionMapping, why not
make it a standalone servlet? At which point it would be exactly the
same as forwarding to a JSP.

A current DEV idea is to provide for invoking the Action directly. This
would work better for you, and is an easy change to the ActionServlet.
This would also allow you to share ActionForms and ActionMappings
between Action objects.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/


"Cakalic, James P." wrote:
> Upshot is, if there are any problems forwarding between Actions that are
> essentially different than the semantics of forwarding from an Action to a
> JSP, I really need to know what they are and how they can be addressed.
>
> Best regards,
> Jim Cakalic

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>






--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to