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, 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