You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by joe panico <jo...@panmachine.biz> on 2003/03/21 00:44:31 UTC
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)
RE: file upload
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
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
>
>
RE: file upload
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
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
>
>