On 05/12/12 11:35, Marek Potociar wrote:
> FWIW, here's the comment I attached to the issue:
>
> -1 on the proposal.
>
> UriBuilder.resolveTemplate() causes the underlying URI builder template to change based on supplied value. The change is IMMEDIATE. If you decided to defer the change to the time when a toTemplate() is called, it's your implementation detail and you need to deal with it in your impl. As such we need a mechanism for controlling the encoding of resolution value(s) in the same way we do it when we use the template to build final URI in build() methods. The current API provides the mechanism. Also with the immediate change there should no confusion about mixing the encoding values in subsequent resolveTemplate invocation calls.
>
OK - I don't have counter-arguments at the moment, feel free to close th
JIRA
Cheers, Sergey
> Marek
>
> On Dec 4, 2012, at 11:56 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> 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
>>
>