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