First, let me say that I did not create the current MultipartRequestHandler interface, and have never liked it, for a variety of reasons. However, by the time I got involved with it, we were pretty much stuck with it for backwards compatibility reasons. In order to retain backwards compatibility in Struts 1.3, we unfortunately need to continue to live with it. However, that doesn't preclude the provision of an alternative; it just requires that the two can coexist.
I would say, though, that even though the current interface is rather less than ideal, the fact that I've personally written three dramatically different implementations of it (the current Struts default, one that uses Resin to do the work, and one that uses a database for file storage) is at least some testament to its flexibility. As far as the need for wrapping the request, others have mentioned this already, but the most basic reason is that, without a wrapper, calls to request.getParameter() would just plain fail for multipart requests. Hence any code that accesses parameters would need to be cognisant of whether the request was multipart or not. That's not something anyone should have to deal with in their applications, and it makes sense for a framework to provide this support. What I would like to do is to move the multipart parsing out into a servlet filter that would sit in front of ActionServlet, passing on a wrapped request, and unwrapping on the way out. This is much cleaner than what we have today. The reason that we do not use such a mechanism already is that filters only showed up in Servlets 2.3, and up to now we have said we were Servlets 2.2 compatible. Also, the reason the current code is always messing around with wrapping and unwrapping is that Servlets 2.2 did not permit wrapping a request. That meant that any time we were passing the request object back to the container, we needed to unwrap it, while we wanted to pass the wrapped request to actions, for example, so that calls to request.getParameter() worked as expected. Once a filter is in place, it then becomes a question of how the application obtains any uploaded files. The code I have in the works as part of Commons FileUpload has methods over and above the standard request methods that provide access to these through the wrapper. We can then plug those into FormFile fields in an action form as part of the population process. We can also look at alternative ways of providing access to them, if necessary / desirable. -- Martin Cooper On Wed, 23 Feb 2005 23:09:11 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Joe, > > I have rethought recent discussions on multipart requests and have a > different proposal. What I would suggest would be to take the whole > multipart business out of the framework altogether and to treat it as > I think it should be treated, as just another Action. > > There is nothing about a multipart request that indicates that it > should be take care of in any special manner, especially one that > curtails differing solutions unnecessarily, by the framework. There > is probably good reason to provide a default solution with an Action > in the actions directory and an associated ActionForm so that those > who don't quite know how to do these things will have the present > solution. This is like providing the DispatchAction, etc. But there > is, so far as I know, no good reason to have any solution be part of > the web framework itself. That just becomes a stumbling block rather > than any help at all. > > What do you think? I know that no solution has to be part of the > framework and this would leave the Action and ActionForm open for > whatever solutions, including the default solution. I think we have > been "overcoding" this. Any thoughts on this? > > I cannot think of one reason why the default solution has to be > hardwired into the framework. Maybe Martin has some reason that I > don't know about. > > Jack > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
