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.
>
>
> 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.
Marek
>
> i.e.
>
> UriBuilder builder = UriBuilder.fromTemplate("/{x}/{y}/{z}");
> builder.buildTemplateFromMap( "x" : "foo").toTemplate() ---> "/foo/{y}/{z}")
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com