On Tue, 2 Apr 2002 [EMAIL PROTECTED] wrote:
> Date: Tue, 2 Apr 2002 14:33:14 -0600
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: Servlet 2.3 filter
>
> Please forgive my ignorance if this is a well-known thing. I went to
> the Struts BOF and I went to the "Filters can replace Servlets in MVC"
> BOF. I see the concept, but I just don't see how filters are "better"
> than servlets for MVC. Is there documentation or discussion about this
> idea somewhere? I first heard of it at JavaOne. Is it "pre-supposed"
> that Struts will someday become filter-based or did I misunderstand
> that? I see how filters are a good frontend to MVC to make sure
> requests don't circumvent your controller, but it doesn't make sense to
> me that a filter would "be" the controller. What are the community's
> thoughts on that?
This is a really interesting question.
I finally had a chance to review the slides from Kevin Jones's session on
Filters (slides for all the sessions are now available in PDF from
http://java.sun.com/javaone -- this was session 1208).
I won't claim that I agree with everything Kevin proposes about using
Filters as a controller in an MVC environment. In particular, I would not
consider the "hard to track which servlet is associated with which JSP
page(s)" issue to be a problem in MVC. Rather, I consider that
separation to be (one of) the whole points of MVC -- making the business
logic and presentation logic as independent of each other as possible.
That being said, I can see the following general advantages for using a
Filter as the controller component of Struts:
* UNIVERSALITY - You can actually guarantee that *all* requests really
flow through the controller. Consider the following scenarios in
Struts 1.0 and 1.1:
- In the Struts example app, we want to ensure that the user is always
logged on, and redirect to the login page if not (a very common
requirement in apps that manage their own security). But, in order
to accomplish this guarantee, we've got ugly <app:checkLogon> tags
on all of the pages, because we can't guarantee that the user will
not link directly to a page.
- In the multiple application support of Struts 1.1, there is a current
restriction that all links *must* flow through the controller in order
for the sub-application selection logic to work correctly. We could
get around this by requiring a custom tag on every page again, but
that is clearly not optimal.
Both of these situations can be elegantly handled by mapping a
controller Filter to the "/*" URL pattern, so that it watches every
single request.
* COMPOSABILITY - The current Struts controller logic is very monolithic,
and it is hard to customize exactly what the controller does for you.
If, instead, we viewed the controller as a series of services that can
be included or not (based on application requirements), the application
architect has the option to pay for only the services they need.
Examples of current Struts services that might well be decomposed:
multipart request handling, path->Action mapping, locale selection,
role permissions checking, form population and validation, ... plus
the fact that it would be easy to add other (perhaps application
specific) services that integrate nicely with those provided by Struts.
* FLEXIBILITY - Another aspect of the monolithic nature of the current
controller is that all of it's processing is applied to every request.
While that is sort of the idea of MVC :-), there are many cases where
you might want different sets of services invoked in different parts of
the same app (or in different sub-applications). We went part-way in
this direction in 1.1, by letting you customize the RequestProcessor
instance used for each sub-app. It's much more powerful to allow the
application architect to compose the set of services to be applied
in a declarative fashion, in web.xml, without having to write any code
to manage the overall orchestration.
* INTEGRATION - Sometimes you want to be able to integrate existing web
application functionality, already provided by servlets and/or JSP
pages, into a Struts based web app. Today, you have to write "glue"
actions that do forwards to such resources -- with a Filter based
controller that front ends things, you can do this more elegantly
(even if you can't modify the apps being integrated).
* WRAPPING - A completely different sort of advantage in using a Filter
is the ability (using the Filter APIs) to wrap the request and/or
response before handing it on to the next filter (or the servlet that
ultimately gets invoked). This capability lets you do all sorts of
interesting things -- just a couple of ideas to whet your appetite:
- If you want to do application managed security, but like the idea
of role checking and user identification that Struts can use in its
decision making process, you could write a request wrapper that fakes
the values returned by getRemoteUser(), getUserPrincipal(), and
isUserInRole(). NOTE - whatever you do here won't affect security
decisions that the container itself makes (such as EJB access
permissions), so it's not a panacea.
- It's commonly necessary to generate slightly different HTML for
different user agents, to deal with the inevitable differences.
One approach is to build the knowledge of these differences into
every tag that renders HTML. A different approach would be to
generate some agent-neutral rendering of the output in XML, and then
apply an agent-specific transformation in a response wrapper.
Some of this can be done with a monolithic controller model, but it
tends to be easier if the controller is composed of separate filters
that you can order as needed.
The bottom line is that, while there has been no formal decision that a
future version of Struts would migrate to a Filter based controller, the
arguments I've listed above seem like fairly compelling advantages. As
always, we would strive to minimize any impacts on applications that just
*use* Struts (i.e. you've just implemented actions and form beans) -- but
the additional power that could be made available to developers is quite
impressive. What do you think?
> Greg
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
