On Jun 18, 2008, at 8:41 PM, Marc Hadley wrote:
> On Jun 18, 2008, at 10:11 AM, Stephan Koops wrote:
>> IMO the UriBuilder could be improved for better useability, by
>> adding some methods:
>> • UriBuilder.replaceQueryParam(String, Object) // replace only
>> one parameter
>> • UriBuilder.replaceQueryParams(Map<String, Object>) // replace
>> all parameters
>> • UriBuilder.queryParams(Map<String, Object>) // adds the
>> parameters to the current avaible params.
>> and change one signature to
>> • queryParam(String, Object)
>> where - if the value for a key is a Collection, there are multiple
>> parameters for the same key.
>> The same methods should de added for matrix parameters.
>>
> How about just changing the existing method to
>
> queryParam(String, Object...)
>
> Each value Object gets converted to a String with toString. If you
> have a collection you can write queryParam(name, values.toArray())
>
> To address the substitution use case we could add:
>
> replaceQueryParam(String, Object...)
>
> Given that replaceQueryParams(null) removes any existing query
> parameter I don't see the need to specify additional methods that
> combine that functionality with the existing append functionality.
>
> Maps are OK but what you really need is MultivaluedMap. However, I
> don't want to make that a concrete API class.
>
>> For the MultivaluedMap it seems useful to me to add:
>> • public <A> A getFirst(K key, Class<A> convertTo)
>> • public <A> A getFirst(K key, Class<A> convertTo, A defaultValue)
>> • public <A> A getFirst(K key, A defaultValue); // if the
>> defaultValue is directly the class to convert to (e.g. no
>> subclass) it would work without the class parameter, I think.
>> • public <A> List<A> get(K key, Class<A> convertTo)
>
> We had this kind of generic method in our initial sketch of the API
> but we removed them - I can't recall why now - Paul ?
>
I don't fully recall. Such methods are still in the Jersey
implementation. Perhaps we removed them from the iface for two reasons:
- it added some complexity and we wanted to keep things simple.
- from an implementation perspective we may have thought these
methods would be reused when mapping to @*Param but it is not a very
efficient solution so they ended up with less value.
Paul.