You will still point to an action. I think a filter (or a possible servlet) should direct to the correct action using some rules and mappings.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 03, 2002 5:33 PM 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? You don't link to the filter. I think Kevin's suggestion was that the JSP is the endpoint. I think I prefer to point to the controller and let him tell me what page to forward to. But, Craig brings up some really good points. I like these ideas a lot. They make Struts a lot more pluggable and flexible. > -----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]>
