On 23/10/12 13:41, Bill Burke wrote:
>
>
> On 10/23/2012 6:06 AM, Sergey Beryozkin wrote:
>> On 16/10/12 14:06, Bill Burke wrote:
>>> Wouldn't changing resolveTempalte() and build() methods to state that
>>> '/' is not encoded and you must encode it manually work just as well? Or
>>> is it a backward compatibility issue?
>>>
>>> We have to provide a way for people to specify path params without
>>> encoding the '/', but it just seems silly to have a special method for
>>> this case.
>>>
>> Agreed the current solution is not ideal at all. Probably too late
>> though to revert. The real concern is, with "/" now getting a prominent
>> attention at the API level, what would happen if some other character in
>> say the query component will need another special treatment during the
>> substitution.
>>
>
> Is this true?
>
> assertEquals("a/b", UriBuilder.fromPath("{a}").buildFromEncoded("a/b");
>
> If so, maybe we can add a method that encodes everything in a String,
> but the '/'.
>
> // encodes any '%' not followed by hexadecimal. Does not encode any
> legal URI characters.
>
> static String encode(String string) {...}
>
> Then users that want to retain the '/' can do:
>
> String myString = "a/b";
> assertEquals("a/b",
> UriBuilder.fromPath("{a}").buildFromEncoded(UriBuilder.encode(myString));
>
> We add language to build() and buildFromMap methods that '/' is encoded.
>
>
>
Well, CXF uses buildFromEncoded and I do not want to come near build()
in my own code,
Cheers, Sergey