I tend to agree we should not bake the form builder support directly into the client fluent API. But do you see a
problem with Form having it's own very simple fluent API?
E.g.:
import static javax.ws.rs.client.Entity.*;
...
Form form = Form.param("a", 1).param("b", 2); // Using Form fluent API to add parameters
client.target(...).request().post(entity(form)); // using overloaded Entity.entity(Form) static method
Or more simply:
client.target(...).request().post(entity(Form.param("a", 1).param("b", 2)));
The above seems OK to me.
Marek
On 08/30/2011 10:36 AM, Sergey Beryozkin wrote:
> Form submission is just a payload, so having a dedicated support in the fluent API seems wrong to me,
> if we support forms explicitly then we should support
>
> tag("bar").simple("foo").endTag("bar")
>
> which would cover <bar><foo/></bar>, which is a payload, exactly the same way the "a=1&b=2" is
>
> Sergey
>
> On 29/08/11 21:13, Marek Potociar wrote:
>>
>>
>> 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
>>
>>
>
>