"Craig R.
McClanahan"
<craigmcc@apa
che.org>
04/09/2002 To: Struts Developers List
<[EMAIL PROTECTED]>
10:27 AM cc:
Please
respond to
"Struts
Developers Subject: Re: Servlet 2.3 filter
List"
Caterpillar: Confidential Green Retain Until: 05/09/2002
Retention Category: G90 -
Information and Reports
I do appreciate your response and have a couple follow up questions.
> How do you set up the data the *first* time you want to
> access a particular page (the way you'd use a setup action
> in a Struts based app)?
Not sure I can comment on this issue since we're very new to the Struts
world but I would like to hear a scenario in which "setup actions" would be
applied.
> What happens when a particular form submit should be handled
> differently (and trigger different output) depending on the
> contents of the included fields?
I believe that filters can exercise the option to handle the
request/response themselves or to forward the request/response to the next
filter in the chain. I would think that should it be the case that if a
filter chose to evaluate request parameters and handle the response in a
different fashion (e.g. dispatch to a different jsp) dependent upon
parameter values it would have that perogative.
> What happens when you successfully complete a transaction and
> want to go on to the next one (you can't just forward to the
> "new" page because filters won't get invoked again)?
Could you give me some further insight into this comment, particularly with
regard to the phrase "complete a transaction"? I'm no doubt looking at
this filter concept from too simplistic a perspective. Could you describe
a transaction scenario? I suppose I was looking at a filter chain that
might include a security filter, followed by a business logic filter,
followed finally by a view dispatching filter. In other words a
"transaction" would include authentication/authorization, action and
response generation. I don't think in this simple example I would
want/need filters to be invoked again before the jsp is dispatched to. I
suppose if I did I would include filters in the above mentioned chain that
would to additional view related manipulation of my business logic filter's
output before the jsp filter.
Thanks
On Tue, 9 Apr 2002, Steven D. Monday wrote:
> Date: Tue, 9 Apr 2002 10:05:00 -0500
> From: Steven D. Monday <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Servlet 2.3 filter
>
>
> 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.
That's why I made the remark partly in jest.
> 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.
That's pretty true of the "typical" Model 1 designs we've all seen in the
past. Each page submits back to itself, so the business logic is embedded
directly.
The proposed filter design is *similar* to this (but not identical), in
that you still submit back to the page itself. The difference this time
is that the business logic is abstracted out of the page, and into the
filter (or a class delegated to by the filter). But it still seems to
suffer from the same design issues of a typical Model 1 design (such as):
- How do you set up the data the *first* time you want to
access a particular page (the way you'd use a setup action
in a Struts based app)?
- What happens when a particular form submit should be handled
differently (and trigger different output) depending on the
contents of the included fields?
- What happens when you successfully complete a transaction and
want to go on to the next one (you can't just forward to the
"new" page because filters won't get invoked again)?
> 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.
You could make a pretty good case that the existing controller servlet
does exactly this -- gives a "logical name" like "/displayUser.do" to a
business logic function, rather than requiring the physical name of the
servlet or JSP page that is processing that request. The same thing can
happen with filters (and the page author would never know the difference),
but you get the additional capabilities of composability (versus a
monolithic controller) and interception of *all* requests (even links
directly to a JSP page).
>
> Steve Monday
>
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]>
