Don't forget, that we need also a regular expression for
@Path("/abc/de{FGH: .*}fg/image"} and List<PathSegment>.
Stephan
Marc Hadley schrieb:
> Funny, Paul and I were just discussing the exact same idea ! I'm not
> exactly sold on this yet but lets explore the idea to see if we end up
> somewhere good.
>> I understand James's usecase, but I don't like his solution. I never
>> liked the 'limited' annotation attribute and thought we should expand
>> on @Path expressions instead. I propose supporting regular
>> expressions instead. Here's my idea:
>>
>> "{}" denotes a PathParam, expression, or both:
>>
>> "{" [ path_param ] ":" expression "}" |
>> "{" path_param "}"
>>
>> The ":" denotes that there is an expression to be matched. If the
>> ":" is preceded by a path_param, then fill that path_param with that
>> value.
>>
>> For example:
>>
>> 1. /foo/{param}/blah -> "/foo/([^/])+"
>> 2. /foo/{param: .*}/image.jpg -> "/foo/(.*)?/image.jpg"
>> 3. /foo/{:.*}/image.jpg -> "/foo/.*/image.jpg"
>>
>> #1 is an example of a path param with no expression
>> #2 is an example of a path param that matches a particular expression
>> #3 is an example of just an expression with no path param
> So essentially if its a named template var then you turn whatever
> follows the ':' into a capturing group. I notice in your example you
> follow the capturing group with '?' - why ? Is there a usecase for
> allowing the user to specify qualifiers for a capturing group ?
>> We support regular expressions in JAX-RS 1.0. If we want to support
>> different expressions down the road we can either:
>>
>> * create a new @Path annotation
>> @W3cPath
> This is probably the most straightforward.
>
> Marc.