Marc Hadley wrote:
> 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 ?
>
No reason, no usecase for '?'. Probably just bad regexp by me.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com