An attempt:
http://java.net/jira/browse/JAX_RS_SPEC-316
Marek - please don't close it immediately - give it a chance
Thanks, Sergey
On 03/12/12 16:15, Sergey Beryozkin wrote:
> Actually, not that is matters, but I'll type it anyway:
>
> if toTemplate() can act as a final builder method, then IMHO dropping
> two resolveTemplateFromEncoded and two resolveTemplate() accepting
> encodePathSlash will still make sense, with two new toTemplate added
> instead, we'd have 3 in total:
>
> toTemplate()
> toTemplate(boolean encodePathSlash)
> toTemplateFromEncoded()
>
> That would mean that the all the sequence of vars is either encoded or
> not, and the decision is made on how to treat some of the vars from the
> builder methods, build() and now also toTemplate()...
>
> I guess I'm alone on the above
>
> Sergey
>
> On 03/12/12 15:30, Sergey Beryozkin wrote:
>> On 03/12/12 14:57, Bill Burke wrote:
>>>
>>>
>>> On 12/3/2012 7:19 AM, Sergey Beryozkin wrote:
>>>> If it is agreed that UriBuilder.build() 'makes' the final and only
>>>> decision on what to do with encoding slashes in path vars, then the
>>>> same
>>>> applies to
>>>>
>>>> UriBuilder.resolverTemplateFromEncoded: it either build() or
>>>> buildFromEncoded() which 'decides'.
>>>>
>>>> I don't think a case for supporting a combination of encoded and
>>>> not-encoded vars was under the radar when resolveTemplate methods were
>>>> added. But at the moment one can resolveTemplate() and
>>>> resolveTemplateFromEncoded() and then call build() or
>>>> buildFromEncoded()
>>>> - this is possible to handle - but IMHO it will be much simpler if the
>>>> assumption is made, same as it was before, that it is a sequence of
>>>> only
>>>> already encoded or not-encoded vars that has to be dealt with.
>>>>
>>>> Thus I propose to drop resolverTemplateFromEncoded() methods
>>>>
>>>> This will leave two resolveTemplate methods, and the decision on how to
>>>> handle the template vars will be done by calling build() or
>>>> buildFromEncoded()
>>>>
>>>
>>> -1. You may be building a template, and buildXXXX() may never be called.
>>>
>>> UriBuilder builder =
>>> UriBuilder.fromUri("/album/{name}/customers/{custid}");
>>> String template = builder.resolveTemplate("name",
>>> "Thrash%20Band").toTemplate();
>>>
>> No problems. I saw this method, but it did not occur to me UriBuilder
>> can be not a URI builder after all...
>>
>> Irrespectively of whether toTemplate() is called or not, the possibility
>> of build() being called afterwards is still there.
>>
>> Whatever, let users figure out themselves what does it all mean
>>
>> Sergey