> On 10/23/2012 1:01 PM, Markus KARG wrote:
> >> Is this true?
> >>
> >> assertEquals("a/b",
> >> UriBuilder.fromPath("{a}").buildFromEncoded("a/b");
> >
> > Yes. "buildFromEncoded" prevents any kind of encoding, hence {a} is
> > simply replaced by the String "a/b" as is.
> >
> >> 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(myStrin
> >> g)
> >> );
> >>
> >> We add language to build() and buildFromMap methods that '/' is
> >> encoded.
> >
> > What actual problem do you solve with this added complexity? This was
> > all discussed before. Please provide *actual* problems instead of
> > posting hypothetical solutions so we can talk about it. At the moment
> > I do not see what you try to reach.
> >
>
> If you follow the above you can remove the
> build/resolveTemplateXXX(..., boolean encodePathCharacter) methods.
> And i'm not introducing complexity, but removing some of it. The fact
> is that different users may or may not want to encode the '/' and you
> have to be sure to support both.
Maybe it's too late in the evening or I am simply too blind to see, but I
still do not see the *problem* but still only see a proposed *solution*. Did
anybody say that we must remove build(..., boolean)? Did I miss something
(what might be the case)?