Marc,
> I like 3. '}' is not allowed in a URI path unless its escaped so it doesn't seem like a big restriction to me.
It is a substantial restriction because {…} is used in regexes when it is not trying to match a literal { or }. {n,m} is a standard regex feature for matching multiple times so you are likely to encounter it when people write a regex.
Paul,
> - URI matchers could be used as URI templates, although an unnamed variable cause issues
A variable is never unnamed, but its name can be the empty string “”. An empty string does not need to be treated any differently from any other string when building a URI.
> - What does it mean if the regex for a name contains one or more capturing groups?
Accept them.
At a minimum a JAX-RS implementation needs to count the groups so it can build its name-to-group mapping.
An additional feature where a @*Param value can have the form “name.index” would be nice. It should be easy to implement:
If (name)
v = matcher.group(map.get(name));
else if (name.index)
v = matcher.group(map.get(name) + index);
Bill,
>Why does embedding a regular expression within a {...} placeholder
require a little care? Seems like an implementation detail to me on how
the {...} string is processed.
Everyone needs to know when a } is part of the regex and when it ends the placeholder.
By “requires a little care” I meant the spec has to pick a new rule for this.
Paul,
> name = 1*(< any TEXT expect <:>>)
Need to exclude } from names as well, since the :regex bit is optional.
> regex = token | quoted-string
> token = 1*(<any TEXT except <}> that is a regex>)
> quoted-string = ( <"> 1*(<any TEXT except <"> that is a regex>) <"> )
That is ok, but slightly worse that my 1st option I think.
My 1st option forbids regexes with an unpaired { or }, or nested {{…}}s.
Your syntax forbids regexes with both “ and }.
I am happy with either restriction as I don’t believe any practical regex would be affected. You would have to deliberately design a diabolical regex to be affected.
With my 1st option it is always {name:regex}, with your syntax an author has choose {name:regex} or {name:”regex”}.
Both syntaxes complicate splitting a @Path value into literals and placeholders. However, the splitting can still be done with a pattern. I provided a 42-character pattern for my 1st option. The following pattern for your syntax is 45-characters long. => No significant difference in complexity.
For yours (ignore spaces): \{ ([^:}]*) (?: : ( (?: ($!”) [^}]* ) | (?: “[^”]*” ) ) )? \}
> what if there are literal characters present in the regex. Do those characters need to be percent encoded or not.
NOT.
encode=true/false currently does not apply to placeholders. That shouldn’t change even if a placeholder can contain a regex. As you say, parsing a regex is too hard.
James Manger
_____________________________________________
From: Manger, James H
Sent: Thursday, 3 July 2008 3:44 PM
To: 'users_at_jsr311.dev.java.net'
…
1) Only allow '{' and '}' chars in the regex as part of '{…}' pairs that are not nested.
2) Delimit the regex with ` or space (instead of : and }).
3) Disallow any '}' chars in the regex.
4) Invent an escaping mechanism.
…