On Mar 20, 2009, at 11:01 AM, Imran M Yousuf wrote:
> On Fri, Mar 20, 2009 at 3:35 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> On Mar 20, 2009, at 5:12 AM, Imran M Yousuf wrote:
>>
>>> Thanks a lot, I have got the Forms to get working as I want :) and
>>> it
>>> seems to work quite fine and as expected. You can find the detail
>>> code
>>> at the end of the mail. Also I made some comments in line.
>>>
>>
>> Great. I am nearly finished with the forms and @FormDataParam. TODO:
>>
>> - Tweak @FormDataParam to properly support default values
>>
>> - JavaDoc @FormDataParam
>>
>> - Add sample
>>
>
> Once you are done let me know and I will gladly add the sample :), doc
> pointers would be great.
>
OK.
>>
>>> On Thu, Mar 19, 2009 at 10:44 PM, Paul Sandoz
>>> <Paul.Sandoz_at_sun.com> wrote:
>>>>
>>>> On Mar 19, 2009, at 11:20 AM, Imran M Yousuf wrote:
>>>>
>>>>> File file = new File("src/test/resources/Splash-
>>>>> resized.jpg");
>>>>> MediaType imageType = new MediaType("image", "jpeg");
>>>>> FormDataMultiPart part = new FormDataMultiPart();
>>>>> FormDataMultiPart bodyPart = part.field("file", file,
>>>>> imageType);
>>>>> resource.type(MediaType.MULTIPART_FORM_DATA_TYPE).post(
>>>>> part);
>>>>
>>>> Note you can already do the above as follows:
>>>>
>>>> FormDataMultiPart multiPart = new FormDataMultiPart().
>>>> field(
>>>> "file",
>>>> new File("src/test/resources/Splash-resized.jpg"),
>>>> MediaType.valueOf("image/jpg")).
>>>> build();
>>>>
>>>> resource.type(MediaType.MULTIPART_FORM_DATA_TYPE).post(multiPart);
>>>>
>>>> I have just committed the following to the trunk so you can do:
>>>>
>>>> FormDataMultiPart multiPart = new FormDataMultiPart().
>>>> field(
>>>>
>>>>
>>>> FormDataContentDisposition
>>>> .name("file").fileName("userfile").build(),
>>>> new File("src/test/resources/Splash-resized.jpg"),
>>>> MediaType.valueOf("image/jpg")).
>>>> build();
>>>>
>>>> I might tweak the builder pattern of FormDataContentDisposition
>>>> because
>>>> it
>>>> is possible to convert one of the other builder methods in to a
>>>> terminated
>>>> builder method, but the principle will remain the same.
>>>
>>> The only thing that I wanted to avoid is creating disposition
>>> manually. So basically what I would like to see is some like -
>>>
>>> new FileDataBodyPart(String formParamName, java.io.File attachment,
>>> MediaType mediaType);
>>> new FileDataBodyPart(String formParamName, java.io.File attachment);
>>> //Will add media type from file name
>>>
>>
>> OK. Can you please log an issue?
>>
>
> I can log the issue and also contribute to it since it will be fairly
> straight forward implementation, I will work on it this weelend and
> will submit a patch on Monday, if all goes well.
>
>>
>>> This would basically save a lot of effort. Another think I would
>>> like
>>> see is the FileDataContentDisposition should respect "Content-Type"
>>> header as its "getType"; what do you think?
>>>
>>
>> The ContentDisposition.getType is not related to the Content-Type
>> it is
>> related to the type of the disposition. And Content-Disposition is
>> orthogonal to Content-Type.
>>
>
> hmm, interesting, then how can the server receive the MIME-type of
> the content?
>
Using:
BodyPart.getMediaType()
>>
>>> Also what do you think about adding a detailed example of file
>>> attachment? like the one I implemented that would explain how to
>>> submit forms using jersey-client and use Jersey on the server side?
>>>
>>
>> Yes, a sample is important.
>>
>
> As mentioned earlier Almighty willing I will try to contribute it :).
>
Great. The best way to do that is to log an issue and add a patch,
>>
>>> Also another thing I just noticed is, if FormDataContentDisposition
>>> had been a part of JAX-RS then my resource would not have to
>>> depend on Jersey at all and I think such portability would be
>>> appreciated by the community, what do you think?
>>>
>>
>> Unfortunately it is not so simple. There are other additional
>> details too.
>> JAX-RS does not specify support for @FormParam with "multipart/form-
>> data".
>> One reason i am moving over to @FormDataParam is to avoid confusion
>> when
>> overloading.
>>
>> I agree this is an area that should be considered to standardization.
>>
>
> Should I log an issue and if yes where?
>
jsr311.dev.java.net
Paul.