tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Micael Padraig Og mac Grene" <caraun...@harbornet.com>
Subject Re: RequestDispatcher.forward() and filters
Date Sun, 11 Nov 2001 05:02:30 GMT
You the man, Matt!

-----Original Message-----
From: Matt Egyhazy <mwe7w@virginia.edu>
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
Date: Saturday, November 10, 2001 7:52 PM
Subject: Re: RequestDispatcher.forward() and filters


>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>
>
>


--
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