tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@attbi.com>
Subject RE: file upload
Date Fri, 21 Mar 2003 00:48:29 GMT
I've been thinking about an application extension to allow you to easily set
those parameters.  If you don't create the app extension, the default
implementation is provided.

Howard M. Lewis Ship
Creator, Tapestry: Java Web Components

> -----Original Message-----
> From: joe panico [mailto:joe@panmachine.biz] 
> Sent: Thursday, March 20, 2003 6:45 PM
> To: tapestry dev
> Subject: file upload
> I've tested the apache commons FileUpload with Tapestry. I 
> recommend that we adopt FileUpload in favor of the current 
> implementation.
> * It's fast
> * It has more features than the current implementation
> * Most importantly; no point in reinventing an already round wheel.
> I've integrated it with Tapestry 2.4-alpha-4 so that it 
> conforms to existing Tapestry Interfaces relevant to file 
> upload: IMultipartDecoder and IUploadFile.  This 
> implementation passes all JUnit tests, after I implemented a 
> little of the TBD header stuff in MockRequest.
> There's one outstanding design issue. FileUpload allows you 
> to set such things as the "max upload size" and the 
> "temporary upload directory". My implementation allows 
> setting these via static methods on DefaultMultipartDecoder, 
> so that the settings are global. Much nicer would be if these 
> could be parameters on the Upload Component. Unfortunately, I 
> don't see an easy way to communicate between  an Upload 
> Component and a MultipartDecoder. The basic problem is that 
> multipart decoding is done "up front" and "monolithically". 
> The request is multipart decoded in the RequestContext 
> constructor, which is pretty much the first thing that 
> happens in Tapestry. As a result, you don't know anything 
> about target components until the request is already decoded. 
> Also, the apache FileUpload currently only supports 
> monolithic decoding-- a single method decodes the entire 
> request, so to learn anything about a multipart request you 
> have to decode any uploads also. So it may be that to 
> parameterize the Upload component with user settings like 
> maxSize will require some restructuring of Tapestry and/or 
> FileUpload, which is why I punted for the time being and took 
> the static settor route.
> What is the process for having this reviewed and contributing 
> it to Tapestry?
> regards,
> joe
> --
> Open WebMail Project (http://openwebmail.org)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message