On Mon, Dec 03, 2001 at 03:29:26PM -0500, Ted Husted wrote:
> The standard ActionForward and ActionInclude Actions create a
> RequestDispather in the Action, and do call another servlet directly,
> without going back to the container.
>
> http://jakarta.apache.org/struts/api-1.0/org/apache/struts/actions/ForwardAction.html
>
> I recently suggested some additional methods for ActionServlet which
> would allow one Action to call another, in case there was a centralized
> Action that was rendering a view. I'm just waiting for someone to offer
> to test it, since this is not something I need to do myself.
>
> To support JavaServer pages, we do eventually have to forward back to
> the container, so the JSP can be rendered. AFAIK, there is not a
> portable way that the ActionServlet could "call" a JSP directly. So
> forwarding is the default because it should be able to get you anyplace
> you want to go.
>
> But nearly anything that is possible in a servlet, is possible in an
> Action, if you want to do it.
What Donnie Hall wrote seems to be a symmetric solution, all the others
are just workarounds.
You would have Action - to raise user events to the model
and ActionForward - to render a view choosen by the action
The Controler only knows that the Action "performs" and the ActionForward
"renders" (or "processes" or "forwards" or whatever). Then you can have
ForwarderActionForward, IncludeActionForward, CallerActionForward,
BuilderActionForward etc. Just: the Forwarder... gets a dispatcher and forwards,
the Caller... just calls something, the Builder... works from custom properties
etc. If you do this you can use the _very_same_action_ to raise an event
and give back a logically defined ActionForwarder and don't have to bother
in the event branch of the processing what _technical_ mechanism for the
view was choosen. I think that the processActionForward() code in the
ActionServlet should be the very same like the ProcessActionPerform.
Why not the Actio? Because it should be separate from the rendering
mechanism.
incze
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
