On 7/3/12 9:33 AM, Sergey Beryozkin wrote:
> On 03/07/12 14:27, Bill Burke wrote:
>>
>>
>> On 7/3/12 8:31 AM, Sergey Beryozkin wrote:
>>> On 03/07/12 13:22, Marek Potociar wrote:
>>>>
>>>> On Jul 3, 2012, at 2:08 PM, Sergey Beryozkin wrote:
>>>>
>>>>> On 03/07/12 13:04, Marek Potociar wrote:
>>>>>>
>>>>>> On Jul 3, 2012, at 11:04 AM, Sergey Beryozkin wrote:
>>>>>>
>>>>>>> On 02/07/12 17:57, Marek Potociar wrote:
>>>>>>>> On Jul 2, 2012, at 5:49 PM, Bill Burke wrote:
>>>>>>>>
>>>>>>>>> Sorry, catching up after a mini-vacation with family.
>>>>>>>>
>>>>>>>> No problem. Hope you had fun.
>>>>>>>>
>>>>>>>>> We have a toString(...) for client side. Use both in our
>>>>>>>>> low-level, jax-rs-2.0-like client API and also within our proxy
>>>>>>>>> framework. Would still be useful for JAX-RS 2.0 when passing
>>>>>>>>> objects to WebTarget.pathParam and Webtarget.queryParam as well
>>>>>>>>> as when creating forms.
>>>>>>>>
>>>>>>>> Ah, seems so obvious now :) Thanks!
>>>>>>>
>>>>>>> So why would one prefer implementing StringConverter as opposed to
>>>>>>> overriding toString() ? I do not understand the case
>>>>>>
>>>>>> Perhaps because you can't override toString as the class is out of
>>>>>> your control (JDK classes, 3rd party modules...)
>>>>>
>>>>> Sure - this means we want to introduce a wrapper around such classes.
>>>>> However why can't this wrapper offer a custom toString() ?
>>>>
>>>> I think the converter approach is more consistent with JAX-RS entity
>>>> providers where serialization is separated from the Java object model.
>>>
>>> OK
>>>
>>>> Also don't think that wrappers would make the code look cleaner or
>>>> more readable in general.
>>>
>>> ServiceConverter implementations are the wrappers around those classes
>>> you've referred to earlier.
>>>
>>> Anyway, if we have StringConverter introduced and utilized for the
>>> parameter conversion on the client side then one has to support them for
>>> converting Strings on the server side to custom types representing URI
>>> or form parameters, in addition to the default fromString()/etc.
>>>
>>>
>>
>> FWIW, I didn't personally decide to add this feature to Resteasy. It was
>> proposed by and implemented by a contributor to fit his specific need.
>> Then a bunch of other users had the need for it as well. The fact that
>> Jersey has something similar tells you that its a feature developers
>> need.
>>
> I see Jersey and RestEasy references in nearly every post now :-).
> FYI, in CXF we have something called ParameterHandler for converting
> String to typed objects, which as a side note, reflects the 'scope'
> better, IMHO.
>
> The goal of the previous message was to suggest that if we have an
> additional utility for converting Objects to Strings (specifically for
> supporting the parameter conversion) then there has to be a symmetric
> support for converting such String back to the custom Objects
>
Oh, I"m sorry, read too fast. Sorry if I misinterpreted your response.
I don't like the name ServiceConverter, as this could be used on the
client side as well. (the back to custom object thang).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com