On May 21, 2008, at 12:03 PM, Paul Sandoz wrote:
>> An oversight, for consistency I guess we should allow the
>> collection types too. So given:
>> @Path(value="{p}/foo/{p}", limited=false)
>> @PathParam("p") List<String> paths
>> GET /1/foo/3/4
>> Should paths be:
>> {"1", "3/4"}
>> or
>> {"1", "3", "4"}
>> I think this should inform the decision we make re @PathParam("p")
>> List<PathSegment> paths. I'd like some consistency with how the
>> path is split up regardless of the type of list - i.e. I'd rather
>> not special case PathSegment.
>
> It breaks the consistency with template creation and will result in
> an error when using such matched values for URI creation from a URI
> template. I think {p} MUST have the same value for matching and
> creation. The workaround is trivial: use another template name for
> the second one.
>
I'm conflicted on this one. I agree its odd and easily worked around
but given that you can already do:
@Path("{var}")
public class RootResource {
@Path("{var}")
public SubResource locator(@PathParam("var") String var) {...}
}
and GET /1/2 will call locator("2") it doesn't seem much of a stretch
to support:
@Path("{var}")
public class RootResource {
@Path("{var}")
public SubResource locator(@PathParam("var") List<String> vars) {...}
}
where GET /1/2 will call locator({"1","2"}). If that works then it
would be surprising if
@Path("{var}/{var}")
public class RootResource {
@GET
public Result get(@PathParam("var") String var) {...}
}
didn't call get({"1","2"}).
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.