tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Egyhazy <mw...@virginia.edu>
Subject Re: RequestDispatcher.forward() and filters
Date Sun, 11 Nov 2001 03:57:26 GMT
i agree, too many people act like jsp forces you to write bad,
spaghetti-like code and its difficult to use properly.  i dont think i have
had that problem with it but i have seen very, very, very bad code written
for applications that use jsp.

matt
----- Original Message -----
From: "Micael Padraig Og mac Grene" <caraunltd@harbornet.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Sent: Saturday, November 10, 2001 10:45 PM
Subject: Re: RequestDispatcher.forward() and filters


> Heh, taglibs are not only JSP stuff, they are the best JSP stuff.  JSP
gets
> too many detractors.  JSP is great, if you don't abuse it.
>
>
> -----Original Message-----
> From: Dr. Evil <drevil@sidereal.kz>
> To: tomcat-user@jakarta.apache.org <tomcat-user@jakarta.apache.org>
> Date: Saturday, November 10, 2001 4:40 PM
> Subject: Re: RequestDispatcher.forward() and filters
>
>
> >
> >Thanks Craig.  That decisively answers the question for me.  It looks
> >like, in my application, filters are more useful than servlets.  The
> >problem with servlets is that if I want to catch all requests, and I
> >put in a /* mapping, then if I get a RequestDispatcher to anything
> >else, it will loop back to the original servlet, over and over.
> >Filters avoid this problem.  Filters are a very powerful thing, more
> >powerful than servlets, I think.
> >
> >Here's my current thought on how to design my project:
> >
> >Create some object (or objects) which live in the ServletContext.
> >These will hold all the data which the application will need.
> >
> >Create some filters to generate per-request objects from the object in
> >the ServletContext, and then install these objects into the Request
> >object.
> >
> >Use taglibs to display things as necessary.
> >
> >This all uses filters; servlets are hardly used in this.
> >
> >This way there is absolutely no JSP stuff used in the display, and the
> >model is held in the objects which are in the ServletContext.  Is this
> >a good design to take advantage of API 2.3?
> >
> >Thanks
> >
> >Craig wrote:
> >> There are a couple of questions here that are worth answering
> >> specifically, based on the final version of the 2.3 spec:
> >>
> >> * Can a Filter call a RequestDispatcher?  Yes -- for example,
> >>   you could implement an MVC-style controller (similar to the
> >>   Struts ActionServlet) as a Filter that used individual servlets
> >>   as Actions.
> >>
> >> * If a Filter calls a RequestDispatcher, does that stop the
> >>   current Filter chain?  Only if you don't call chain.doFilter()
> >>   after the RequestDispatcher.forward() or RequestDispatcher.include()
> >>   call returns.  It's up to you to decide whether to continue the
> >>   chain or not.
> >>
> >> * On a RequestDispatcher call, does the newly selected servlet get
> >>   its own filter chain?  No -- filter chains are only constructed based
> >>   on the original request URI.  Servlets that are selected via a
> >>   RequestDispatcher are invoked directly, with no further filters
> >>   involved.  (This is also true for RequestDispatcher calls from
> >>   servlets.)
> >
> >--
> >To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> >For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> >Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message