commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lane, Brad" <Brad.L...@pearson.com>
Subject {--Don't read, just testing my Outlook filter--} RE: FileUpload P arameter Handling
Date Fri, 08 Oct 2004 18:05:17 GMT
 

-----Original Message-----
From: Michael McGrady [mailto:mike@michaelmcgrady.com] 
Sent: Thursday, October 07, 2004 10:59 PM
To: Jakarta Commons Users List
Subject: Re: FileUpload Parameter Handling

My pleasure, Adam.  I don't know who wrote the commons upload stuff, but I
think they did one hell of a job.  You have to study it a bit, however,
because it is not entirely intuitive at first.  I will tell you this,
however, it really provides a wonderful base for working with multipart
issues.  I have a hugely efficient file upload application built on top of
this functionality.  Anyway, glad you are on track.  
These things can bedevil us.

Michael McGrady

Adam Pelletier wrote:

> I fixed my problem.  My problem is that I had a Servlet that would 
> serve up any number of Pages.  The way the navigation was wired was 
> through keys/values pairs in the parameter list (i.e.
> req.getParameter("ID)).  So the HttpServletRequest itself would get 
> passed down to a couple of different delgation layers.  Well in 
> DiskFileUpload the parameters are stored differently in the Parts list 
> and then have to be iterated over.  So all my code depended upon:
>
>    // block 1
>    req.getParameter("foo");
>
> as opposed to
>
>   // block 2
>   Iterator iter = m_req_parts.iterator();
>   while (iter.hasNext()) {
>    FileItem fi = (FileItem) iter.next();
>    if (fi.isFormField() && fi.getFieldName().equals("foo")) {
>     return fi.getString();
>    }
>   }
>
> So what I did is write an HttpServletRequestWrapper so when my code 
> calls black 1 above, what really happens is block 2 above executes.
>
> Thanks all for the help,
> Adam
>
> ----- Original Message ----- From: "Michael McGrady" 
> <mike@michaelmcgrady.com>
> To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
> Sent: Thursday, October 07, 2004 3:29 PM
> Subject: Re: FileUpload Parameter Handling
>
>
>> I cannot see how a servlet stepping through parameter values could 
>> break an architecture.  What do you mean by that?  If the parameter 
>> is there, then the servlet can read it.  How that could affect 
>> architecture is not clear to me.  Can you guys explain what you mean?
>>
>> Michael McGrady
>>
>> Paul DeCoursey wrote:
>>
>>> I know what you are saying about it breaking your architecture... i 
>>> use a servlet that calls scripts based on a parameter, I found that 
>>> using the multipart-encoding broke that.  I later discovered that if 
>>> I post the multipart but have my parameter on the querystring it 
>>> works fine.
>>>
>>> Paul
>>>
>>>
>>>
>>>> No, this is just a plain servlet.  Another guy wrote that regular 
>>>> form params show up in in the DiskFileUpload.
>>>>
>>>> When you iterate through the values, you can test to see if they 
>>>> are form fields with "isFormField"
>>>>
>>>>
>>>> Example:......................................
>>>> DiskFileUpload upload = new DiskFileUpload();
>>>> List           files  = upload.parseRequest(request);
>>>> Iterator       it             = files.iterator();
>>>>
>>>> while(it.hasNext()){
>>>>   FileItem item = (FileItem)it.next();
>>>>   if(item.isFormField()){....
>>>>
>>>>
>>>> But that still breaks my architecture - although I can get to that 
>>>> architecture if I have to.
>>>>
>>>> Adam
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: 
>>> commons-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: 
>>> commons-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
>



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

**************************************************************************** 
This email may contain confidential material. 
If you were not an intended recipient, 
Please notify the sender and delete all copies. 
We may monitor email to and from our network. 
****************************************************************************

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


Mime
View raw message