On Jul 3, 2008, at 7:44 AM, Manger, James H wrote:
> I like Bill Burke’s solution.
>
> Embedding a regular expression within a {…} placeholder requires a
> little care. Four options spring to mind (from my most preferred to
> least):
>
> 1) Only allow '{' and '}' chars in the regex as part of '{…}' pairs
> that are not nested. The restriction applies even if a char is
> escaped as \{ in the regex.
> {foo:X{2,3}} is allowed (matching XX or XXX)
> {foo:X[^}]Y} is not allowed
>
> 2) Delimit the regex with ` or space (instead of : and }). These
> chars have no special meaning in a regex, and are not allowed in
> URI paths (and don't need escaping in a Java String). Consequently
> they shouldn't be needed in the regex so they can be forbidden.
> {foo`.*`} or {foo".*"} or {foo .* }
>
> 3) Disallow any '}' chars in the regex.
>
> 4) Invent an escaping mechanism.
>
My preference would be something like the following:
variable = ( "{" name [":" regex] "}" )
name = 1*(< any TEXT expect <:>>)
regex = token | quoted-string
token = 1*(<any TEXT except <}> that is a regex>)
quoted-string = ( <"> 1*(<any TEXT except <"> that is a regex>)
<"> )
Tis a bit like HTTP grammar from which i copied.
> P.S. I cannot think of any sensible @Path value with encode=false
> that couldn't be rewritten fairly easily as an encode=true value.
> At worst you have to change %xx%yy to \uzzzz. Consequently, I
> suggest dropping the @Path encode parameter.
>
This leads to an issue of what if there are literal characters
present in the regex. Do those characters need to be percent encoded
or not. How would such literal character be detected? I would prefer
to avoid writing my own regex parser (the one in the JDK is limited
in this respect) or reusing an external one introducing another
dependency and more code.
Paul.