On 9/6/2012 1:21 PM, Marek Potociar wrote:
>
> On Sep 6, 2012, at 6:10 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>>
>>
>> On 9/6/2012 10:09 AM, Marek Potociar wrote:
>>> client.target("{a}/{b}").pathParam("a", "x").getUriBuilder()
>>>
>>> In this case a few answers are possible for the internal state of the
>>> returned UriBuilder:
>>>
>>> 1. URI template: "{a}/{b}", internal template values: N/A
>>> 2. URI template: "{a}/{b}", internal template values: "a" -> "x"
>>> 3. URI template: "x/{b}", internal template values: N/A
>>>
>>>
>>> Now after a careful consideration, I'd argue that we should take
>>> approach that corresponds to the answer #3 (even though it may not seem
>>> to be the most intuitive answer).
>>
>> #3 was already the most intuitive and I thought that's how pathParam() was supposed to work.
>>
>>> This proposal should make things consistent. Please provide your
>>> feedback ASAP. I'd like to make this change before the PR release
>>> planned for next Monday.
>>>
>>
>> I agree with irreversibly resolving the template values. That's how I thought it was supposed to work anyways. I don't agree with the name-change. I think pathParam() makes perfect sense as you think of @PathParam.
>
> No, it doesn't. See the example with the query parameter template value. The new name will better represent the actual functionality provided by the methods.
>
Yeah, you're right.
>>
>>
>> I would like to add buildTemplate(Map) methods to UriBuilder. Basically works the same as buildFromMap() methods except it returns another UriBuilder
>
> That's what resolveTemplates(Map) will do. Except it will not return another builder. But one can do the cloning easily.
>
Ah, missed that...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com