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.
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