> If I had to choose using a string "PATCH" over writing your extension, I'd
> pick the string every day.
As I mentioned, if type safe is not important, go for Strings.
On the same way of thinking, If hypermedia is not important, the
client api will be a nice wrapper for Apache Commons... yet another
http library.
I expect it to innovate, not to be yet another one. But if we are
going to do it the same way it is usually done, it is good to know.
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Wed, Jul 6, 2011 at 1:50 PM, Bill Burke <bburke_at_redhat.com> wrote:
> 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
>
>