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?
Marek
>
> Sergey
>>
>> In any case, whether we decide to keep the Form or if we opt for going with a generic MultvaluedMap<String, String> as a
>> representation of form-encoded parameters, I can see few options we should consider:
>>
>> 1. Provide a static Entity method:
>> Entity.form(Form formData) or Entity.form(MultivaluedMap<String, String> formData)
>>
>> 2. Introduce public Entity Form.asEntity(); method. This one would require we move Entity into core package to avoid the
>> dependency from core to client.
>>
>> 3. Provide another post() overload:
>> SyncInvoker.post(Form formData); ...I wouldn't agree with the generic Map-based version in this case
>>
>> The order above also shows my preference. Option #1 seems to be most consistent extension to the current API. Option #2
>> is almost as good, but it still feels like we would be moving some client-side concern to the core Form API. Option #3
>> would be our acknowledgement that post(Form) is by far most expected use case scenario, but it's not consistent with the
>> current approach of encapsulating entity-specific topic in the Entity class.
>>
>> Let me know if any of the above looks good or if you see another option(s).
>>
>> Marek
>>
>>
>> On 08/29/2011 04:53 PM, Bill Burke wrote:
>>> No matter whose proposal you look at, everybody pretty much ignores form parameters. IMO, form parameters will be
>>> typical usecase with POST invocations.
>>>
>>> Something like this would be really ugly:
>>>
>>> target.request().post(Form.param("foo", "bar").param("bar", "foo));
>>>
>>> It starts to look like LISP. What sucks is, I just know I've encouraged you to add *at least* one more interface to
>>> this ridiculous hierarchy.
>
>