Re: [Bodington-developers] email attach prob

[Antony C. <an...@sm...>]

ok Jon thanks for that we didn't want to hack the code just incase  
there was a very good reason for the way it was!

On 24 Mar 2006, at 14:02, Jon Maber wrote:

> I think I have a very simple fix;
>
> In readMultiPart...
>
> -data.put( parameter_name, readPart() );
> +addFormField( data, parameter_name, readPart() );
>
> -data.put( parameter_name, file.getPath() );
> +addFormField( data, parameter_name, file.getPath() );
>
> In getParameterValues...
>
> -    String[] v = new String[1];
> -    v[0] = (String)data.get( name );
> -    if ( v[0]==null )
> -        return null;
> -    return v;
> +    return (String[])data.get( name );
>
>
> In getParameter....
>
> -    return (String)data.get( name );
>
> +        String[] plist = (String[])data.get( name );
> +        if ( plist!=null )
> +        return plist[0];
> +        return null;
>
>
> Jon
>
> Antony Corfield wrote:
>
>> req params are held in 2 hastables data and formdata, the former  
>> holds  String whilst the latter holds String[]
>> When content_type.startsWith( "multipart/form-data" ) readMultiPart   
>> method is used to populate data hashtable not formdata
>> The implementation of getParameterValues(name) checks if data is null  
>>  and then returns the String value for the named key as single  
>> element  array
>>
>>
>>
>> On 24 Mar 2006, at 13:35, Jon Maber wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting   
>>> language
>>> that extends applications into web and mobile media. Attend the live  
>>>  webcast
>>> and join the prime developer group breaking into this new coding   
>>> territory!
>>> http://sel.as-us.falkag.net/sel?  
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Bodington-developers mailing list
>>> Bod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the live  
>> webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Bodington-developers mailing list
>> Bod...@li...
>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers