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
http://jakarta.apache.org/proposals/tapestry



> -----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
> 
> 


Mime
View raw message