Indeed, the more I think over the idea of "{+id}" the more I like it.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Freitag, 23. Dezember 2011 17:14
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: HEADS-UP:
> Encoding values of UriBuilder template parameters
>
> On 23/12/11 16:09, Markus KARG wrote:
> > Given the fact that existing code has a method annotated with
> > @Path("foo/{id}") and I want to get "foo/a%2Fb%2Fc" when calling
> > .path(Class, String).build("a/b/c"), what would be your solution? I
> > mean, you just criticize Marek's proposal, but what would you propose
> instead?
>
> I'm always trying my best to offer something in alternative, and never
> just keep saying does not work :-)
>
> > Adding segment(Class, String)? Using a different synax like
> "foo/{+id}" as > Julian pointed to?
>
> "foo/{+id}" seems elegant, but segment(Class, String) can be good too;
> Overload ? May be, but I'd review then what should segment() and
> query() report when they accept template vars with '/' and build()
> initiating the final step with 'false'.
>
> Let Marek decide :-)
>
> Sergey
>
>
> >
> >> -----Original Message-----
> >> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> >> Sent: Freitag, 23. Dezember 2011 17:02
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: HEADS-UP:
> >> Encoding values of UriBuilder template parameters
> >>
> >> 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
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com