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