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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com