On Mon, 3 Dec 2001, Incze Lajos wrote:
> Date: Mon, 3 Dec 2001 22:18:53 +0100
> From: Incze Lajos <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: FW: Opinion on design ideas???
>
> 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.
>
(Coming in late on this thread, but a couple of comments)
I would characterize Struts controller servlet as being preferring to use
a RequestDispatcher to access the view component, rather than preferring
JSP as the view component. (There are other synergies that the custom tag
library provides, but the controller servlet itself is agnostic.)
You should note, however, that it is also possible for an Action to create
the view directly, if you want to:
public ActionForward perform(...) ... {
...
PrintWriter writer = response.getWriter();
writer.println(...);
...
return (null);
}
Returning null, instead of an ActionForward instance, tells the controller
servlet that the response has already been created. Of course, you could
do other things (like call a Velocity template) instead of writing the
response directly, as well.
Thus, anything for rendering the view layer that is accessible only
through API calls is also usable in Struts.
> incze
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
