Paul Sandoz wrote:
> On Jul 2, 2008, at 6:28 PM, 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.
>>
>
> Some comments:
>
> - We can still retain the ordering of the "URI matchers" based on the
> number of template variables (unnamed or
> named) and literal characters that are not declared in a regex.
>
> - URI matchers could be used as URI templates, although an unnamed
> variable cause issues when constructing
> the URI as information is lost. Thus i am wondering if they should be
> disallowed and we should require a name
> and that template variable name/value may be ignored e.g. call it
> 'noname'. Or a perhaps a known name is
> assigned if one is absent e.g. _1, _2 etc.
>
For URI templates you mean the RFC? If not, then I think this is just
an implementation detail.
> - The regex associated with the template variable name could be used,
> perhaps optionally, to validate the value
> when the URI matcher is used as a URI template.
>
> - What does it mean if the regex for a name contains one or more
> capturing groups?
Ignore capture groups? In this case, IMO, you should be creating new
path-param variables rather than defining regex groups.
> It is possible to determine using javax.util.regex.Pattern/Matcher the
> number of capturing groups in an expression.
> Tis a bit funky but one compiles the pattern and obtains a matcher, m
> say, for say "", then one calls m.groupCount().
> Thus it may also be possible to assign names to such sub-groups as is
> the case for unnamed template variables. Or
> it may be possible to easily reject a regex that contains capturing
> groups.
>
I say we prototype it and flush out the details through code.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com