On 23/12/11 15:58, Markus KARG wrote:
> Sergey,
>
>> I'm wondering if the only way not to get 'injured' in this thread is to
>> just say "yes, yes, yes". Come on guys, show the patience, please ! We
>> all have to be able to repeat the same thing easily without going to
>> capital letters or other pokes. Are you going to EXPLAIN it like this
>> to the users too ?
>
> please don't feel offended,
I'm not at all :-), I'm not that sensitive :-), but from my pen
experience where I was pushing strongly for a particular solution I've
found that people can get into a 'blocked' mode and simply won't react
to whatever one will say :-).
Anyway, thanks for the kind reaction - I'll think more about the
comments below, let Marek go through yet another mess :-) and will reply
later on
All, Have a good Christmas break !
Sergey
> but understand that we discussed this issues for
> weeks already in this forum, and all your questions had been asked and
> answered before (in fact, asked by me and answered by Marek). So please try
> to catch up with the mail stack, just as I did. We cannot repeat finished
> discussions again just because the mail archive is a bit unhandy to use.
> More inlined.
>
>>>> The situation with path(Class) is completely different ? The case
>>>> where we are reading from the legacy DB is about submitting the
>>>> values we do not control to UriBuilder. We are in control when
>>>> annotating the resource classes.
>>>
>>> No that exactly is the case we talk about: The annotation is given by
>>> the programmer and it provides the path template given to .path().
>> But
>>> the value provided to .build() is taken form a database and must get
>> encoded ALWAYS.
>>> That is what we discuss in this thread: The fact that slashes taken
>>> from databases and given to .build() are NOT encoded currently but
>>> MUST get encoded ALWAYS as those NEVER are intended to be path
>>> separators but ALWAYS are intended to be DATA.
>>
>> And I'm saying that passing such values indirectly via templates
>> associated with path() is wrong in the first place and they should be
>> given to segment() and segment() java docs need to be fixed to make
>> sure the user understands that irrespectivelt of the way you pass the
>> data to
>> segment() you get the same consistent result, same way you get it with
>> path().
>
> The answer to that was found in the capital letters of my last mail:
>
> You cannot pass templates by segment() in case the template is loaded from
> external configuration or is provided as @Path annoation, and segment() is
> actually currently not doing the wanted encoding, and the JavaDocs WILL get
> overhauled in that sense, which all was explained before in this thread.
>
>>>>> (c) As described earlier in depth, segment is defined in the RFC as
>>>>> a part of the path element (not as something different to path), so
>>>>> without improved JavaDocs people will not assume to find different
>>>>> encoding rules for .path() and .segment(). It is counterintuitive
>>>> that
>>>>> it is up to the
>>>>> *declaration* method how the encoding works like, as people are
>> used
>>>>> to other templating mechanisms like JDBC where this plays no role
>>>>> (it ALWAYS encodes data, even if not necessary, as people could
>> fill
>>>>> in unencoded values by .path(variable) instead of
>>>>> .path("{x}").build(variable) -- which is much more
>> straightforward).
>>>>>
>>>>>> 2. What happens with builder.segment("{bar}").path("{foo}") and a
>>>>>> value 'true' passed to a new overload, where a "{bar}"
>> substitution
>>>>>> will also contain "/" characters. I feel at the moment that given
>>>>>> that both
>>>>>> segment() and path() operate on the same URI component this extra
>>>>>> flag will confuse people like me at least a lot
>>>>>
>>>>> As 'true' means 'always encode all values' it will enforce complete
>>>>> encoding. You will get %2F for each slash in both, the values for
>>>>> bar and foo.
>>>>>
>>>>> Rule: As long as you pass 'true' to the new overload, you can
>> simply
>>>>> pass variables to .segment() and .path() to get slashes ALWAYS, and
>>>>> simply pass variables to .build() to get %2F ALWAYS. This rule is
>>>> much
>>>>> simpler to understand than the current (default, 'false')
>> behaviour.
>>>>> Nothing to think really. Just pass 'true' and decide whether you
>> want
>>>>> slashs (--> .segment(x), .path(x)) or your want %2F -->
>> .build(x)).
>>>>>
>>>> I guess I'm really slow,
>>>>
>>>> What happens if I do segment("a/x/c") and pass 'false' ? Guess we
>>>> should get "a/x/c" as this boolean applies to template vars, right ?
>>>
>>> YES, as the new boolean only decides what to do with VALUES provided
>>> to .BUILD(). LITERALS provided to .SEGMENT() or .PATH() are OUT OF
>>> SCOPE of this thread.
>>>
>>>> How about
>>>> segment("{x}") and false, should not we get "a%2Fx%2Fc" ?
>>>
>>> Marek, your new parameter, your business, your turn. ;-)
>>
>> What is your take on it ?
>
> I actually don't care! As long as .path(Class).build(myVar) will produce one
> %2F for single every slash in myVar I in fact let open all the rest to
> Marek. He gets paid for deciding it. I only get paid to use it. ;-)
>
>>>>> Hope that you see the simplicity in this new overload?
>>>>>
>>>>
>>>> I see better why you and Marek see it improving the situation. I
>>>> won't rush with my final conclusion this time, but so far what I see
>>>> is that when we have a case where we do path("{a}") and seeing the
>>>> substitution value (say a key read from the legacy data source and
>>>> similar) still containing "/" then we are simply doing a wrong code,
>>>> we should be doing
>>>>
>>>> segment("{a}")
>>>
>>> BUT YOU CANNOT IF THE TEMPLATE IS TAKEN FROM SOMEWHERE ELESE AS ONE
>>> COMPLETE PATH STRING, E. G. FROM EXTERNAL CONFIGURATION OR FROM
>> @PATH,
>>> AS THERE IS NEITHER SEGMENT(STRING) WHICH WILL SPLIT INTO SEGMENTS
>> (AS
>>> IT THINKS IT IS A SINGLE SEGMENT), NOR THERE IS SEGMENT(CLASS) NOR
>>> SEGMENT(CLASS, STRING). GOT THE PROBLEM NOW?
>>>
>>
>> But that is what you want, right ? You want '/' in "a/b/c" encoded and
>> this is what segment() needs to be able to do
>
> What I WANT is to write .path(Class, String).build(myVar) and get one %2F
> for every single slash in myVar. If I instead need to write .segment(Class,
> String).build(myVar) that is also OK for me. But I do neither want to use
> Reflection nor String.ReplaceAll, which both is needed currently in fact as
> I already wrote. What I DEMAND is that at least the JavaDocs are complete
> and unambiguous.
>
>>
>>> Don't know how often I explained already on this list... ;-(
>>>
>>> Regards
>>> Markus
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com