I was nearly ready to suggest that may be we were coming to the
conclusion that segment() can become deprecated because
path() + new build overload will just cover this case.
Or we'd say that segment("{id}") and the false means an illegal state
exception or something because that would effectively break the
segment() contract otherwise
But we also can get template vars in query(...) so...
Sergey
On 23/12/11 12:59, Sergey Beryozkin wrote:
> 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 ?
>
> More comments below
>
> On 23/12/11 12:43, Markus KARG wrote:
>>> The situation with pm,entath(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().
>
>>
>>>> (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 ?
>
>
>>
>>>> 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
>
>> 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