You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Frank Kim <fk...@cysive.com> on 2000/09/19 16:43:12 UTC

RE: extending ActionServlet

Don't know if this will work for your situation but what about this:

In ActionBase provide an implementation of perform like
public ActionForward perform(...)
{
  // do some pre-processing here (like session validation)

  doPerform();

  // do some post-processing here
}

Your Action classes would then provide an implementation of the doPerform()
method.

> -----Original Message-----
> From: brian moseley [mailto:bcm@maz.org]
> Sent: Tuesday, September 19, 2000 1:03 PM
> To: struts-dev@jakarta.apache.org
> Subject: extending ActionServlet
>
>
>
> i'm trying to figure out the best way to extend
> ActionServlet. i have several processing steps i want to do
> both before ActionServlet.process() begins and after the
> response has been committed.
>
> i could certainly just subclass ActionServlet and override
> process(), but that doesn't give me any way to do
> post-request processing, since ActionServlet forwards or
> redirects to JSP after the action has been executed.
>
> i'd rather have some way of returning control to the
> ActionServlet after the view has been processed and the
> response committed. looking at ActionServlet.java, it seems
> like if these lines were moved into a protected method, my
> subclass could override it as well:
>
>   if (forward != null) {
>       String path = forward.getPath();
>       if (forward.getRedirect())
>           response.sendRedirect(path);
>       else {
>           RequestDispatcher rd =
> getServletContext().getRequestDispatcher(path);
>           rd.forward(request, response);
>       }
>   }
>
> seems like this mechanism would only work if there is a way
> to invoke JSP without dispatching a full-on request. i know
> how to do that in tomcat, but not portably.
>
> ideas? am i missing the forest for the trees?
>


RE: extending ActionServlet

Posted by brian moseley <bc...@maz.org>.
hm, it's /almost/ right.. but i want my post-request
processing to occur after the reqeust has been committed.
part of what i'm doing is timing request service, and
sending the response is part of that :)

On Tue, 19 Sep 2000, Frank Kim wrote:

> Don't know if this will work for your situation but what about this:
> 
> In ActionBase provide an implementation of perform like
> public ActionForward perform(...)
> {
>   // do some pre-processing here (like session validation)
> 
>   doPerform();
> 
>   // do some post-processing here
> }
> 
> Your Action classes would then provide an implementation of the doPerform()
> method.
> 
> > -----Original Message-----
> > From: brian moseley [mailto:bcm@maz.org]
> > Sent: Tuesday, September 19, 2000 1:03 PM
> > To: struts-dev@jakarta.apache.org
> > Subject: extending ActionServlet
> >
> >
> >
> > i'm trying to figure out the best way to extend
> > ActionServlet. i have several processing steps i want to do
> > both before ActionServlet.process() begins and after the
> > response has been committed.
> >
> > i could certainly just subclass ActionServlet and override
> > process(), but that doesn't give me any way to do
> > post-request processing, since ActionServlet forwards or
> > redirects to JSP after the action has been executed.
> >
> > i'd rather have some way of returning control to the
> > ActionServlet after the view has been processed and the
> > response committed. looking at ActionServlet.java, it seems
> > like if these lines were moved into a protected method, my
> > subclass could override it as well:
> >
> >   if (forward != null) {
> >       String path = forward.getPath();
> >       if (forward.getRedirect())
> >           response.sendRedirect(path);
> >       else {
> >           RequestDispatcher rd =
> > getServletContext().getRequestDispatcher(path);
> >           rd.forward(request, response);
> >       }
> >   }
> >
> > seems like this mechanism would only work if there is a way
> > to invoke JSP without dispatching a full-on request. i know
> > how to do that in tomcat, but not portably.
> >
> > ideas? am i missing the forest for the trees?
> >
>