Marc Hadley wrote:
>>>> Me too. :) decoded keys always.
>>>>
>>> I assumed and implemented encoded keys and values for
>>> UriInfo.get*Parameters(true) and UriInfo.getPathSegments(true).
>>> Namely that you if ask for something in encoded form you get
>>> everything in encoded form. This reduces possible sources of
>>> confusion and bugs and the main idea of encoded form was so that a
>>> more advanced developer could work consistently in encoded form for
>>> all such information extracted from the URI.
>>> UriBuilder.queryParam encodes the value and name if the encode
>>> property is set to true, otherwise validates the value and name if
>>> set to false. If query keys are decoded but query values are not then
>>> it is hard to use UriBuilder.queryParam consistently with
>>> UriInfo.getQueryParameters(false).
>>
>> Yeah, I guess you're right. My thought was, why would anybody ever
>> encode a key to access a specific value in the map? In general, I
>> don't see how these encoded maps would be very useful. Can you
>> provide a use case?
>>
> Having thought about this some more I agree with Paul, if a developer is
> working in encoded space its more natural to encode both keys and
> values. I'll update the javadoc to make this explicit.
>
>>> Looking more closely i found some issues because the *Param names are
>>> not specified to be in encoded or decoded form, and i did not assume
>>> either way when implementing.
>>> The JavaDoc does not define if @*Param names should be in encoded or
>>> decoded form. Same goes for @DefaultValue. Note that @Encoded does
>>> not apply to values of @Path, for example:
>>> @Path(value="x%20y", encode=false)
>>
> For consistency with @Path we need to add a:
>
> boolean encode() default true;
>
> property to each of @PathParam, @QueryParam, @MatrixParam and
> @DefaultValue.
>
Then @Encoded goes away? I rather like that annotation over an
annotation attribute.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com