Marc Hadley wrote:
> On Jul 3, 2008, at 1: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):
>>
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.
>> 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.
>>
> I like 3. '}' is not allowed in a URI path unless its escaped so it
> doesn't seem like a big restriction to me.
>
Why do you like #3? I think we should support any regex after : and
before the last '}'. Its not hard to parse to create the correct path
regex and documenting this feature becomes easier as you just point the
user to the javadoc on Pattern.java or something similar. I liked the
':' delimiter because its pleasing to the eye and I've seen similar
approaches in the past with other frameworks/languages, etc.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com