If I had to choose using a string "PATCH" over writing your extension,
I'd pick the string every day.
On 7/6/11 12:00 PM, Guilherme Silveira wrote:
> I don't wanna get into the details of String x Objects, it should be
> quite clear what is the difference between type safe and not type
> safe.
> But just to extend on my suggestion (type safe features), here is an
> example that enforces the entity prior to posting:
>
> + HttpResponse response =
> client.request("http://www.google.com/").with(entity(myObject)).postChecked();
>
> "postChecked" cannot be invoked if no entity was set. It is compile
> time checked.
>
> Here is the sample commit:
> https://github.com/caelum/jaxrs2-caelum/commit/9cd26f59d74be356b6438b533a21755c11a94aa1#L0L28
>
> I strongly disagree that features should be strings. Instead, they
> should be type safe objects that enhance the library and allows
> compile time checking. If we don't want compile time type check, there
> is a huge set of languages to use on the JVM already.
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Wed, Jul 6, 2011 at 11:45 AM, Bill Burke<bburke_at_redhat.com> wrote:
>> I don't understand why you need this abstraction when you could just as
>> easily use the workarounds I suggested earlier. Over-engineering is an
>> anti-pattern too.
>>
>> On 7/6/11 10:41 AM, Guilherme Silveira wrote:
>>>>
>>>> So we aren't trying to define a client API that is generic enough for
>>>> extension methods? Anymore?
>>>
>>> +1
>>>
>>>> Well, then suggest something.
>>>
>>> + HttpResponse response =
>>> client.request("http://www.google.com/").with(webdav()).propfind();
>>>
>>> Here is the implementation:
>>> ::::
>>> https://github.com/guilhermesilveira/jaxrs2-caelum/commit/924ae87adc30625ba284e409723524ead1763e2b#L0L-1
>>>
>>> What has been done:
>>> :::: Just wrapping around, but already providing the delegator and the
>>> wrapping mechanism:
>>>
>>> Currently anyone can do typos:
>>> ::: request.method("PROP_FINDY")
>>>
>>> Using the solution I mentioned we can provide ".propFind" without the
>>> need to change the specification. So it's type safe and it allows
>>> evolution. Does it make sense to force the user to use type safe and
>>> avoid "string-based" programming? Its just a matter of removing the
>>> .method(String) from the Invocation interface (= a few move and
>>> extracts).
>>>
>>> Regards
>>>
>>> Guilherme Silveira
>>> Caelum | Ensino e Inovação
>>> http://www.caelum.com.br/
>>>
>>>
>>>
>>> On Wed, Jul 6, 2011 at 10:19 AM, Bill Burke<bburke_at_redhat.com> wrote:
>>>>
>>>>
>>>> On 7/6/11 8:16 AM, Julian Reschke wrote:
>>>>>
>>>>> On 2011-07-06 13:50, Bill Burke wrote:
>>>>>>
>>>>>> 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.
>>>>>> ...
>>>>>
>>>>> So we aren't trying to define a client API that is generic enough for
>>>>> extension methods? Anymore?
>>>>
>>>>
>>>> Well, then suggest something.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com