On Mar 13, 2009, at 11:13 AM, Sergey Beryozkin wrote:
>>>
>>> * first instance of the template parameter. e.g. the template
>>> "{a}/ {b}/{a}"
>>>
>>> * with values {"x", "y", "z"} will result in the the URI "x/y/x",
>>> <i>not</i>
>>>
>>> * "x/y/z".
>>>
>>>
>>> Can someone explain please the rationale behind it ?
>>>
>>
>> The rationale is that the template says that {a} is included twice.
>> It would be odd for two different values to be used.
>
> I think I can see where are you coming from but at the same time
> it's somewhat odd seeing a passed in value being ignored given that
> UriBuilder java docs also say that
>
> * Any UI templates parameters will be replaced with the supplied
> values in order.
>
Understood.
>>>
>>> So if we have
>>>
>>> @Path("{a}/{b}")
>>>
>>> class Resource {
>>>
>>> @Path("{a}") void method(@PathParam("a") String a);
>>>
>>> }
>>>
>>> then x/y/z with result in 'z' being bound to a path parameter,
>>>
>>
>> Right, the reason for this was to support recursive sub-resource
>> locators.
>
> Hmm...What is it to do with recursive sublocators ? AFAIK, root path
> annotations are not considered when locating methods on subresource
> locators ?
>
That's true but path parameters from root path annotations are
available to sub-resources so we needed to specify that if a sub-
resource somewhere down the chain uses the same name for a path
parameter as a parent then the value is the latest, not the first. If
you use recursive sub resource locators then you end up with multiple
values of the same path parameter and typically you want the final
value not the first.
Marc.
>>
>>> but if we have uriBuilder.path("{a}/{b}/{a}").build("x", "y",
>>> "z") then the result will be /x/y/x
>>>
>>> I think in the least it's problematic in the context of a client
>>> application creating a URI to send a given request to
>>>
>>
>> Possibly but if it causes problems its straightforward for the
>> developer of the service to choose different names for each path
>> component.
>
> We might disagree on the earlier points but I agree with this
> one :-). I'd appreciate though some more comments on the sublocators
> bit
>
> Cheers, Sergey
>
>>
>> Marc.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>