On 08/29/2011 09:29 PM, Bill Burke wrote:
>
>
> On 8/29/11 3:08 PM, 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.
>>
>> 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 3 above options break the "flow" of the invocation as you'd have to create the message body outside the request
> block, i.e.:
>
> Form form = new Form();
> form.add("foo", "bar");
> target.request().post(Entity.form(myForm));
I thought that's OK, since it's just yet another data content, strictly speaking. In fact there are many representations
that could be marshaled as form-encoded data, including most of arbitrary java bean hierarchies (param names being e.g.
dot-separated field names) - that's btw. one of the reasons why I am slightly hesitant we really need the Form class.
>
> I would prefer something like:
>
> target.request().post(Entity.formParam("foo", "bar").formParam("bar", "foo"));
>
> or
>
> target.request().post(Entity.form().param("foo, "bar").param("bar", "foo"));
Provided we truly need the fluent Form API as part of the client API, the two above look good. Another option might be
to extend the core.Form to provide fluent param mutator and combine it with my option #1:
target.request().post(Entity.form(Form.param("foo, "bar").param("bar", "foo")));
This one having an advantage of not introducing yet another type. Further, if we combined the fluency with my option #2
we could get:
target.request().post(Form.param("foo, "bar").param("bar", "foo").entity());
...still without introducing another type.
Marek