Bill,
> Yeah, I know we're rehashing old arguments...but...Your logic is flawed
> because '/' is a legal URI path character.
>
> UriBuilder.fromResource().build(dataFromDatabase);
>
> In the above case you mentioned, there is just as high a probability
> that the application developer may not want '/' encoded. IMO, it is
> intuitive that '/' would never be encoded within a URI path because,
> well, it is a legal URI path character, thus '/' should generally *not*
> be encoded and the encoded case should be treated as an extreme edge
> case.
Again, please, why not just reading the already discussed arguments...?
@Path("{a}/{b}/{c}")
...
UriBuilder.fromResource().build(tvShowFromDatabase.getSeriesTitle(),
tvShowFromDatabase.getSeason(), tvShowFromDatabase.getVolume());
Think what happens if you want to load Volume 1 of Season 1 of "Nip/Tuck",
compared to loading Volume 1 of Season "Tuck" of a hypothetical series
"Nip".
Solve that without adding more complexity! It is not possible. Whatever you
do, it will be more code to write, and it will be more potential source of
hard to find failure.
The slash is enforced by the RFC as the separator between path segments, so
in the above code lines you will notice that @Path obviously makes up a path
of two segments, and each of the segments is filled with APPLICATION DATA,
so the slashes MUST be encoded by default.
What the heck do you not understand with this simple and typical use case?
*That is not a very narrow edge case, that is a most typical default case in
enterprise JAX-RS use.*
I did notbody force to add four methods. I originally asked for a working
solution. If you ask me, I would simply write "build must always encode" but
that is not wanted by the other EG members.
Regards
Markus
>
>
> I find it disconcerting that for a very narrow edge case we have added
> 4 additional methods. Adding a static encodeSegment() method will
> allow us to remove multiple methods from UriBuilder, specifically:
>
> URI build(Object[] values, boolean encodeSlashInPath) URI
> buildFromMap(Map<String, ?> values, boolean encodeSlashInPath)
> UriBuilder resolveTemplates(Map<String, Object> templateValues, boolean
> encodeSlashInPath)
> UriBuilder resolveTemplate(String name, Object value, boolean
>
> Anyways, I'm fine keeping stuff the way it is, just wanted to argue one
> last time...
>
> Cheers
>
> On 10/23/2012 1:50 PM, Markus KARG wrote:
> > If you are not too disappointed I'd like to follow Marek and ask you
> > to check the discussion in the mail archive.
> >
> > In short, I do not want any special rules but instead want a stable
> > working API for this scenario:
> >
> > @Path("{a}")
> > ...
> > UriBuilder.fromResource().build(dataFromDatabase)
> >
> > does simply not work otherwise. As Marek just said, it is the only
> > correctly working and stable solution. Adding another method wrapping
> > "dataFromDatabase" is simply ridiculous and overly complex, as there
> > already are exactly two methods, one that MUST encode (build) and one
> > that MUST NOT encode (buildFromEncoded) and there is absolute no
> *need* for anything more.
> > Forcing a need to wrap all database calls is ridiculous as those are
> > the majority of cases.
> >
> > If you want people to not get encoded slashes, either make them write
> > the slashes not into build() but into path(), or make them add a
> > boolean to build().
> >
> > Thanks
> > Markus
> >
> >> Markus, I personally find it very weird that '/' would ever be
> >> automatically encoded in a path template variable as it is a valid
> >> path character as per the URI RFC. IMO, if you want special
> encoding
> >> rules that are different than what is specified in the URI RFC's,
> >> then, IMO, you should have to manually encode them, or have us
> >> provide a method that encodes a string for you.
> >
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com