[fileiupload] Remodeling of parseRequest?

[Will Stranathan <ws...@hotmail.com>]

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

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:

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [fileiupload] Remodeling of parseRequest?

[Martin Cooper <ma...@apache.org>]

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?

http://nagoya.apache.org/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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org