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:50:03 GMT
Contributions are best as CVS patches uploaded into BugZilla.

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