Please pardon me for replying to this message in an incorrect manner (if in fact I do) it is my first forray into your community. I'm not sure I see how Kevin was suggesting a model 1 architecture. Model 1 as I understand it, would suggest that a request is made from a browser to a jsp that in turn might instantiate some kind of bean that would access database resources (for example) directly. In an earlier comment in this thread Craig mentioned the fact that using filters the request can be made to a resource that doesn't even exist. In other words the request could be made to a logical name (e.g. displayUser) rather than to a physical name (e.g. DisplayUser.jsp). Filters could be defined that would intercept the request for the logical name displayUser performing business logic in filter1 while generating a response in filter2. In this case it seems to me that the declarative nature of filters are in fact allowing for the configurating of controlling logic prior to the generation of a response.
Steve Monday "Martin Cooper" <martin.cooper@tumbl eweed.com> 04/09/2002 12:07 AM Please respond to To: "Struts Developers List" <[EMAIL PROTECTED]> "Struts Developers cc: List" Subject: Re: Servlet 2.3 filter Caterpillar: Confidential Green Retain Until: 05/09/2002 Retention Category: G90 - Information and Reports ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Monday, April 08, 2002 9:21 AM Subject: Re: Servlet 2.3 filter > > > On Sun, 7 Apr 2002, Martin Cooper wrote: > > > Date: Sun, 7 Apr 2002 21:34:37 -0700 > > From: Martin Cooper <[EMAIL PROTECTED]> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > To: Struts Developers List <[EMAIL PROTECTED]> > > Subject: Re: Servlet 2.3 filter > > > > [snip] > > I attended Kevin's session, and chatted with him afterwards. The model he > > described is one where the request URL points directly to the JSP page > > itself, and the controller does the preparation necessary to display that > > page. > > > > However, this model really only works for simple applications. One example > > in which this breaks is where some action needs to be taken in addition to > > displaying the JSP page, and there is no one-to-one relationship between the > > action and the page. (In Struts-land, this is the equivalent of having > > multiple actions which may forward to the same JSP page.) > > > > <ducking-for-cover> > In other words, Kevin pitched a Model 1 design with the business logic in > a filter instead of inside the page? :-) > </ducking-for-cover> Yup, I guess that's actually a pretty good way of summarising it, although I'm sure he wouldn't be too happy with that description... ;-) -- Martin Cooper > > > Kevin realises now that this is a problem with the approach he presented. > > I'm sure he'll be giving it more thought, though. ;-) > > > > -- > > Martin Cooper > > > > Craig > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED] > For additional commands, e-mail: <mailto:[EMAIL PROTECTED] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>