On Jun 18, 2008, at 2:53 PM, Stephan Koops wrote:
>
> 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())
> See reason for the special handling below.
>> 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 this I proposed to use the parameter Map<String, Object>. If an
> value is a Collection (e.g. a List; that's the MultivaluedMap), than
> iterate over the values and not directly call toString() on the
> collection. And for analogy, I proposed this for the other methods.
> And if someone wants to put e.g. the String "[..., ...]" of an
> ArrayList into the paramsters (very rare usecase), he could use
> list.toString().
>
I wondered if that is what you intended. I'm not really keen on
methods that do one thing with one type of parameter and another with
a different type. Its complex to explain and document, liable to
confuse people and makes the API look and feel overly complex.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.