commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [fileiupload] Remodeling of parseRequest?
Date Thu, 05 Jun 2003 05:31:17 GMT

On Wed, 4 Jun 2003, Will Stranathan wrote:

> I REALLY like the FileUpload tool - have had great success with RC1, and
> look forward to a production release.

Glad you like it!

> However, I'm curious if the possibility of making the API model more
> consistent with the Request model of the Servlet API.  There are a couple of
> things that I think would be handy in this regard:

These are some interesting ideas. Would you mind adding this as an enhancement
request in Bugzilla?

That will ensure that your ideas don't get lost/forgotten when we start
looking at the next release.

Thanks for your feedback!

Martin Cooper

> 1) For FileUpload to have getParemeter(String name) or
> getParameterValues(String name) - I think this can be implemented on top of
> the current API so that there are no backward-compatibility issues.
> 2) At LEAST working out a kink (IMHO) where multi-valued parameters actually
> appear as separate FileItems with the same value returned by getFieldName().
> I suppose what I propose would look something like this:
> DiskFileUpload upload = new DiskFileUpload();
> // Now, rather than applying an Iterator to parseRequest,
> // we still call the same method,
> // but pull the individual items from the
> // DiskFileUpload object itself
> upload.parseRequest(request);
> FileItem myfile = (FileItem)upload.getParameter("myfile");
> // And this looks ALMOST like ServletRequest.getParameter(String name)
> String lastname = (String)upload.getParameter("lastname");
> String[] favoriteColours = upload.getParameterValues("favoritecolours");
> Alternately, a getFileItem(String name) method could be added in order to
> shield the user from having to cast the result of getParameter(String name)
> to a FileItem - and this same method could wrap ordinary field values in
> FileItems similarly to the way they are returned in the Iterator.
> I don't know if this possibility has been discussed or sounds useful to
> anybody else.  I'll be happy to contribute where I can if there is any other
> interest in this change.
> Regards,
> Will Stranathan
> _________________________________________________________________
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message