Or, instead, simply
WebDav dav = new WebDav(client);
or
WebDavRequest request = new WebDavRequest(client.request);
Or, if you are a JAX-RS implementor, just have your request
implementations implement a custom interface then typecast the request:
WebDavRequest req = (WebDavRequest)client.request();
No need to get fancy-nancy.
On 7/5/11 2:42 PM, Guilherme Silveira wrote:
> #StringOrientedProgramming rant again
>
> .method(Method) instead of .method(String)
>
> Where Method has a applyTo(request) method. After invoking .method(x),
> x can apply itself to the request, either as a filter or right as its
> applied.
>
> Again, String--, Objects++.
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Tue, Jul 5, 2011 at 3:16 PM, Markus KARG<markus_at_headcrashing.eu> wrote:
>> Can you please outline how a WebDAV extension ontop of JAX-RS would be able
>> to provide a .propfind() or .search() method (not .method("PROPFIND")) to
>> prevent WebDAV users from typing Strings?
>>
>>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke_at_redhat.com]
>>> Sent: Dienstag, 5. Juli 2011 17:30
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> Subject: [jsr339-experts] client revisions
>>>
>>> I made some changes to client API to simplifiy it a little.
>>>
>>> https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals-rev2
>>>
>>> * removed queue from Invocation interface
>>> * Added an AsyncInvocation interface
>>> * Added get/post/delete/etc. methods to AsyncInvocation and Invocation
>>> * removed invoke/queue methods from Client as they are redundant and I
>>> don't get why they are there.
>>> * removed HttpRequest.Builder as its not needed anymore
>>> * Link no longer extends HttpRequest.Builder
>>> * added request/async methods to Link
>>> * Gutted and simplified ClientFactory. No need for all those extra
>>> abstractions.
>>>
>>> You now are forced to put a get(), Post() or whatever at end of method
>>> call unless you are doing a custom HTTP method like PATCH. It now
>>> looks
>>> like:
>>>
>>> Client c = ...;
>>>
>>> Invocation invocation = c.request();
>>> HttpResponse response = invocation.header("foo", "bar").get();
>>> String str = invocation.header("foo", "bar").get(String.class);
>>>
>>> AsyncInvocation async = c.async();
>>> Future<HttpResponse> f = async.header("foo", "bar").get();
>>> Future<String> f = async.header("foo", "bar").get(String.class);
>>>
>>> Generic invocations are:
>>>
>>> Invocation invocation = c.request();
>>> HttpResponse response = invocation.header("foo",
>>> "bar").method("PATCH").invoke();
>>>
>>>
>>> Alternatively, you could combine Invocation/AsyncInvocation, but you'd
>>> have to rename get() to getAsync(), etc. I think originally it wasn't
>>> done this way because of the explosion of methods within Invocation.
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com