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.
I would like to add buildTemplate(Map) methods to UriBuilder. Basically
works the same as buildFromMap() methods except it returns another
UriBuilder
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