jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: what about form parameters?

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 1 Sep 2011 13:52:30 +0100

Looks good to me. Yea, would've preferred with
post(new Form()), as opposed to post(form(new Form()))

but I'm wondering if I'm starting warming up again or not to it,
specifically to the fact I can save on avoiding setting CT explicitly...
Hmm...A bit more time is needed...

Sergey

On 30/08/11 18:30, Marek Potociar wrote:
> Please have a look at the latest changes in the Form support and review:
>
> http://java.net/projects/jax-rs-spec/sources/git/revision/30277892cfe7fd072a83526913482d9e8869183a
>
> Unfortunately, Form.param(...).param(...) does not compile (without an intermediary class, but this time intermediary
> seems like a true overhead)...
>
> To support static initialization we would need to come up with a good static/instance pair of method names. But I could
> not think of any that would read well when chained. If you have a good suggestion, let me know.
>
> Marek
>
> On 08/30/2011 11:37 AM, Marek Potociar wrote:
>> On 08/30/2011 11:18 AM, Sergey Beryozkin wrote:
>>> On 30/08/11 10:12, Marek Potociar wrote:
>>>>
>>>>
>>>> On 08/30/2011 10:32 AM, Sergey Beryozkin wrote:
>>>>>
>>>>> On 29/08/11 20:08, Marek Potociar wrote:
>>>>>> There is a javax.ws.rs.core.Form proposed to be introduced as part of JAX-RS 2.0 API as a general-purpose support for
>>>>>> form-encoded data. It's been there since HttpRequest/Response were introduced early in June. I just stripped it off the
>>>>>> annotation-support methods so right now it's (again) merely a typed extension of MultivaluedHashMap<String, String>
>>>>>> without any added value. It's perhaps questionable if we need the class, but I'd prefer we brainstorm for potential
>>>>>> value-add methods the class could host before we decide to drop it. We can drop it, if we can't find a good reason for
>>>>>> keeping the class in the API.
>>>>>
>>>>> I'd prefer to get a dedicated helper, but I'd also opt for a delegation as opposed to extension:
>>>>> Form()
>>>>> Form(MultivaluedMap)
>>>>> MultivaluedMap getData()
>>>>> Form set(String name, String value)
>>>>>
>>>>> this is how it'd done in CXF, but I personally like
>>>>> post(new Form().set("name", value))
>>>>
>>>> I think it can be useful to expose Form as a multivalued map. But it's true that we should probably not extend any
>>>> particular MultivaluedMap implementation. Would you be OK with such change?
>>>
>>> a form provider can check if it's Form and if yes then do form.getData() and proceed as usual, I've no strong preference
>>> re Form extending vs Form using MultivaluedMap, well, have a minor preference for the latter, but I'm easy on this one
>>
>> On a second thought, I cannot find a good reason that would justify Form implementing a multivalued map directly. Can
>> you please file a new JIRA issue that Form should wrap but not extend MultivaluedMap and assign it to me?
>>
>> Thanks,
>> Marek
>>>
>>> Sergey
>>>
>>>>
>>>> Marek
>>>>
>>>>>
>>>>> Sergey


-- 
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com