On Jul 23, 2008, at 4:09 PM, Marc Hadley wrote:
> On Jul 23, 2008, at 3:34 PM, Stephan Koops wrote:
>>> If you want to work with pct-encoded data the builder methods will
>>> ignore the escaped octets anyway and if you work with decoded data
>>> the methods will automatically encode stuff for you.
>> For path segments I agree, but not for matrix parameters and the
>> query. If I want to build an URI with a string, where all
>> characters could be in, e.g. "20%20" and the second "20" should not
>> be treated as part of a precent encoded space, so that it should be
>> decoded to "20%2520", than you need the boilerplate code. And this
>> is always the case, where a '%' sign is allowed (perhaps not for
>> daily use, but allowed).
>
>> What about add build methods, where you could give an encode state?
>> But UriBuilder.buildFromMap(Map, boolean) is no problem, but
>> UriBuilder.build(Object..., boolean) won't work. What about
>> UriBuilder.buildEncode(Object...), which encode all characters, and
>> UriBuilder.build(Object...) only the characters that must be
>> converted?
>>
>> What's the problem with adding a third state for the encode
>> attribute, and let all other as it is?
>>
> I've done the exercise of switching to a single state and the result
> is significantly simpler. Adding a third state makes things more
> complex than the status quo. Adding additional build methods that
> force encoding of % chars in parameter values would be preferable.
>
BTW, we could have:
build(boolean, Object...) and buildFromMap(boolean, Map<String, ?
extends Object>)
I think these would negate the need for the static encode method.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.