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