Although I have no real authority here I'm going to vote an emphatic +1 on this suggestion :-)
The current Struts multipart handling mechanism has some major problems. Some are probably fixable in the current code, but the biggest one that could probably benefit most from a filter and request wrapping solution is the problem where a multipart-handling action is unable to forward to another action without forcing a client-side redirect. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 > -----Original Message----- > From: Heath Chiavettone [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 03, 2002 3:22 PM > To: 'Struts Developers List' > Subject: RE: Servlet 2.3 filter > > > Speaking of filtering, Our company is using a filter whose > job it is to handle a multi-part encoded request seamlessly > as if it were a regular request. What I mean by this is that > it reads the multipart stream, builds the appropriate request > parameter map, and handles the upload of files (sticking the > resulting file "object" references into the request as an > attribute with the name of the input element). Essentially > it handles all of the work of parsing the stream, and allows > the JSP page developer to not have to do anything special > when dealing with a multipart file. They simply need to ask > the request for an attribute to get the file object. > > Struts does this using a slightly different mechanism. I > guess my question is this: > > Does it make sense for Struts to adopt a similar mechanism in > place of (or along with) its current one? > > Hopefully this question doesn't sound to scatterbrained... > > Heath > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 03, 2002 9: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:struts-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:struts-dev-> [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]>
