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))
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.
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com