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