Re: [Bodington-developers] email attach prob

[Jon M. <jo...@te...>]

For some reason the Servlet Specs. have never required servlet 
containers to support multipart/form-data.  (Can anyone comment on 
whether it is now supported by the latest spec?)  So servlet authors 
have had to write their own code for doing all the decoding.  Since 
Bodington wraps the containers Request in it's own that provides the 
opportunity to improve support - so the readMultiPart() and related 
methods were intended to make access to fields in mime multipart data 
work just like the ordinary encoding.

However, I think when it was written the servlet spec didn't support 
multiple fields with the same name. I suppose the solution is to not put 
field values into the Hashtable but Vectors that hold one or more fields 
values with the same name. Shouldn't be difficult to implement.

Jon

Naomi Miles wrote:

> Dear peeps
>
> I have a leedle problem with attachments in the email function that  
> I'm working on.  I think the problem arises from the bod specific  
> Request.  What's happening is that when the template <form> is of  
> ENCTYPE="multipart/form-data" then the rest of the template's  
> parameters are not returned correctly, although the attachment part  
> works like a wee sweetie.  Specifically, I am trying to return  
> checkboxes with the same name, which normally would be returned into  
> a String Array by the HttpRequest.getParameterValues method.  Using  
> the bod Request.getParameterValues() method only returns one of the  
> selected checkboxes.
>
> In Request.java it checks to see whether the form has enctype of  
> mutipart and then toddles off to a method called readMultiPart()  
> (nice naming).  I suspect that this is where the problem lies, as the  
> Hashtable 'data' has parameters put into it bsed on their names, and  
> obviously in this case there could potentially be more that one  
> parameter with the same name.
>
> Any ideas/opinions/potential solutions? - I don't wanna just hack at  
> it as I don't necessarily fully understand what's going on in the  
> method and I'll probably break something..
>
> Cheers,
> Naomi.