Hi Marc
> On Jul 23, 2008, at 3:06 PM, Stephan Koops wrote:
>> 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. 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.
> I don't think it will introduce additional boiler plate code since all
> methods will always do encoding. The main change is how we deal with
> pct-encoded chars in values passed to builder methods. Before in
> encode=true mode we treated % as a char that needed to be encoded, now
> we will be smarter and only encode it if its not part of a pct-encoded
> value.
I agree, that we should support this.
> 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?
best regards
Stephan