Hi,
> I think the current approach with the encode attribute is very easy to
> use. Your proposal will produce boilerplate code, because you have to
> manually call the encode methods.
I like the JAX-RS API, because no boilerplate code is needed.
> This will not improve the readability of resource method code,
> especially if you get data from somewhere (databse e.g.) and want to
> use it for building URIs.
>
> So I think -1,
>
> best regards
> Stephan
>
> Marc Hadley schrieb:
>> OK, I'm convinced. Here's what I propose we do:
>>
>> (a) Remove the encode and isEncode methods, all methods that add URI
>> components will perform contextual encoding of characters that are
>> not allowed in the relevant URI component with the following
>> exceptions: { and }. % chars followed by two hex digits (the rfc
>> pct-encoded production) will not be encoded, other % chars will.
>>
>> (b) Add a static method that will encode any characters not part of
>> the rfc 3986 unreserved production.
>>
>> (c) Similar to (a), the build method will encode characters that are
>> not allowed in the relevant URI components. I.e. any embedded { or }
>> will be encoded unlike when adding URI components in (a).
>>
>> The above will allow creation of any valid URI. The only case that
>> developers will have to be careful with is when an input string
>> contains a literal % character coincidentally followed by two hex
>> digits. The method added by (b) can be used to fix this although it
>> won't work if the same string also contains pct-encoded chars - I
>> don't think this a big issue since any string obtained from @*Param
>> is either encoded or not, you won't get a mixture.
>>
>> Marc.