On 22/10/12 16:37, Marek Potociar wrote:
>
> On Oct 22, 2012, at 5:13 PM, Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
>
>> On 22/10/12 16:07, Sergey Beryozkin wrote:
>>> On 22/10/12 13:43, Marek Potociar wrote:
>>>>
>>>> On Oct 22, 2012, at 1:26 PM, Sergey Beryozkin<sberyozkin_at_talend.com
>>>> <mailto:sberyozkin_at_talend.com>>
>>>> wrote:
>>>>
>>>>> I know that I'm the last one who still does not get it :-).
>>>>>
>>>>> Consider the following:
>>>>>
>>>>> uriBuilder.fromPath("http://localhost").segment("{a}").build("a/b",
>>>>> false);
>>>>>
>>>>> UriBuilder.segment() states that "/" have to be encoded.
>>>>
>>>> The javadoc of segment() applies to the value passed to the segment().
>>>> Not to a template that was added via segment(). IOW, if you passed
>>>> "a/b" into segment() directly, it would be encoded.
>>>
>>> So, to be absolutely clear.
>>>
>>> By default, irrespectively of whether a given template var was
>>> introduced as part of path() or segment() call, the "/" (inside of this
>>> var's content) is never supposed to be encoded.
>>>
>>> The only way to override it, when working with build(), is to use a new
>>> flag.
>>>
>>
>> Ouch, it is the other way around,
>>
>> "NOTE: By default all '/' characters in the stringified values will be
>> encoded in path templates, i.e. the result is identical to invoking
>> build(Object[], boolean) build(values, true)}. To override this
>> behavior use build(values, false) instead."
>>
>> Why it is a default, I'm not sure, that definitely breaks one of my
>> tests - but whatever...
>>
>> Just need a confirmation please that this rule applies irrespectively
>> of the "origin" (ex, a var came from path() or segment())
>
> Now, I'm not sure what do you want to confirm? I did confirm that "/"
> encoding in segment(...) does not apply to template variables and does
> apply to string literals in my previous reply, didn't I? Also you quote
> javadoc that IMO clearly states the behavior of build(...) method.
> Additionally, the build(...) method javadoc also states that:
>
> "/Values are converted to {_at_code String} using their {_at_code toString()}
> method and are then encoded to match the rules of the URI component to
> which they pertain/"
>
> So if you have the same template variable use in different URI
> components, it's value will be encoded separately for each component
> using the encoding rules of the respective URI components.
Stay with with me please on this one.
First, I assume this was basically "yes" to my question regarding the
origin of the template variable - I've always thought that the rule of
the method (ex, that of segment() further qualifies the rules of the
encoding of "/").
So that is not the case, that is fine,
Now given your quote re the rules of the URI component, tell me please
(and I'm sorry if that was conveyed earlier):
- why the note above states that by default "/" is supposed to be
encoded where as the rules of URI Path component let "/" stay as is.
Thanks, Sergey
>
> Marek
>
>>
>> Sergey
>>>
>>>>
>>>>> So one possible output is:
>>>>>
>>>>> "http://localhost/a%2Fb"
>>>>>
>>>>> While build() requires this slash to be left as is.
>>>>
>>>>>
>>>>> So the result is then:
>>>>>
>>>>> "http://localhost/a/b"
>>>>>
>>>>> If the last output is the right one (has to be really), then I guess
>>>>>
>>>>> UriBuilder.segment() docs can be improved a bit to state that only
>>>>> "/" in the literal expressions have to be encoded by default,
>>>>> otherwise the encoding is affected by the new build flag, similarly
>>>>> the same clarification needs to be applied to UriBuilder path docs
>>>>
>>>> Can you please provide a javadoc version that would clarify the
>>>> segment() behavior in a way that is, in your opinion, clear&
>>>> understandable?
>>>>
>>> Sure, can do that once I'm 100% clear
>>>
>>> thanks, Sergey
>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>>>
>>>>> Sergey
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>