On May 20, 2008, at 6:25 PM, Bill Burke wrote:
>> *_at_PathParam(...) PathSegment*
>> while thinking how to implement @PathParam for a PathSegment: an
>> uri template variable could be represent a part of a path segment
>> (e.g. @Path("ab{CD}ef{GH}") ), but also multiple path segments:
>> (e.g. @Path(value="ab{CDEF}gh", limited=false) ).
>> For the first case it seems useful to me to return for
>>> @PathParam("CD") PathSegment ps
>> and for
>>> @PathParam("GH") PathSegment ps
>> the same (or two equal) objects implementing PathSegment.
>> But what happens, if CDEF in @Path(value="ab{CDEF}gh",
>> limited=false) matches "12/34" or "12/34/56"? What is the value of
>
> IMO, limited=false has no affect for @Path(value="ab{CDEF}gh",
> limited=false.
>
Right, the template var has to be at the end of the URI for
limited=false to have any effect.
> I don't understand your example URI though.
>
> My thinking is that
>
> GET /abVALUEgh/on/and/on
>
> CDEF = "VALUE" only since it is embedded.
>
Yup.
> If the pattern is "ab{CDEF}" my thinking is
>
> CDEF = "VALUEgh/on/and/on" since the path param ends a segment.
> Maybe Marc/Paul have other thoughts on this.
>
Agreed.
>>> @PathParam("CDEF") PathSegment ps
>> ? The first or the second (or last) of this path segments? Or
>> should this all be treated as one path segment?
>> If the last option, should this be treated as one path segment
>> ever? If I use
>>> @Path(value="{VAR}", limited=false)
>> and VAR matches "jkl/mno/pqr", than this are three path segments,
>> e.g. from UriInfo.getPathSegments(), in my understanding. I think
>> it will causes misunderstanding, if we define "jkl/mno/pqr" as one
>> path segment, if it is matched by one variable.
>
> In this case, why not require it to match a List or Array?
>
> @Path(value="{VAR}", limited = false)
> @GET
> public String get(@PathParam("VAR") List<PathSegment> var)
> {
> }
>
Interesting idea but it does raise some tricky questions, e.g.:
@PathParam("VAR") List<String> var - would you get a single string
with the whole path or a list with an entry per path segment.
Currently @PathParam doesn't allow List, Set or SortedSet like
@HeaderParam, @QueryParam and @MatrixParam.
>
>> A possible solution is to forbid limited=false for parameters of
>> type PathSegment.
>> *_at_Encoded*
>> And another small point: The end of the javadoc of @Encoded could
>> be supplemented with something like ", including bean setters and
>> also annotated fields" (will result in "Using this annotation
>> [@Encoded] on a class will disable decoding for all parameters of
>> all methods, including bean setters and also annotated fields".
>
> can providers use @*Param? That might be interesting.
>
No, only resource classes and methods can use @*Param. Providers have
a singleton lifecycle and fixed method signatures...
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.