On Wed, 3 Apr 2002 [EMAIL PROTECTED] wrote:
> Date: Wed, 3 Apr 2002 14:33:02 -0600
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: Servlet 2.3 filter
>
> I too did not agree with some of Kevin's reasoning for using Filters in
> place of servlets. To me there's a conceptual problem: If there's no
> servlet what's the endpoint?
I expect we'd end up with a really simple servlet as the endpoint. It's
only responsibility would be the action dispatching.
Technically, though, filters do *not* require there to really be an
endpoint. It's perfectly feasible to execute the
RequestDispatcher.forward() call inside a filter, and return without ever
calling chain.doFilter() to continue the chain.
> You don't link to the filter. I think
> Kevin's suggestion was that the JSP is the endpoint.
As I said, I was unable to attend the session so I don't know how Kevin
described his approach in words. However, the impression I get from the
slides is that you are sort of correct -- that application flow is defined
in terms of the JSP pages themselves, and the job of the controller is to
ensure that the "right" business logic gets executed on the way. That is
somewhat different than the Struts philosophy that Actions are in charge.
> I think I prefer
> to point to the controller and let him tell me what page to forward to.
That's my preference as well. I see overall navigation management as
primarily a "controller" layer responsibility, not a "view" layer
responsibility. You can probably make a good case that handling
validation errors and redisplay of the input page as a view-layer
function, and we sort of do that too with the validate() method and the
"input" attribute. But I get really uncomfortable going any further than
that -- it reminds me of why I always hated programming GUI apps with
things like AWT or Swing, where pretty much *everything* is a reaction to
a UI event, and it is hard to see the forest for the trees.
> But, Craig brings up some really good points. I like these ideas a lot.
> They make Struts a lot more pluggable and flexible.
>
Well, it's likely that they *will* do this if we base the implementation
on filters :-).
Craig
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 03, 2002 11:39 AM
> > To: Struts Developers List
> > Subject: RE: Servlet 2.3 filter
> >
> >
> >
> >
> > 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]>
>
>
> --
> 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]>
