On 11/5/07, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Alex,
>
> As you probably know, we already have a way to specify the type of each
> variable in an URI template via the org.restlet.util.Variable class and the
> Template.variables and Template.defaultVariable properties.
>
> Could you describe the use case(s) that would require a full regex syntax in
> URI templates ?
The problem is that if you look at the specification for URI
templates[1], it explains
how templates can be used to create URI values and not how they are matched.
In fact, I can't really find that information anywhere except in the code.
Unfortunately, looking at the URI templates specification, I can find
inconsistencies
between generating and matching URI values.
One of the examples is:
http://example.com/{q}
http://example.com/hello#world
where q=hello#world.
If you tried to use the URI template "http://example.com/{q}";, you'd
get 'hello' for the
variable 'q' because the default is to use a URI segment rather than
the remaining
URI path.
In several of my applications I need to be able to match a remaining
URI path. When I've
developed custom code, I attach a Finder to do that but I have
problems when the root needs
to be handled differently than its sub-resources.
I've run into trouble with simple applications that are configured
from a configuration file
where the match "pattern" is specified and a restlet is attached for
all "sub paths".
For example, if you want to map:
/ -> RootRestlet.class
/.* -> EverythingElseRestlet.class
you can use the two templates:
"/" -> RootRestlet.class
"/{name}" -> EverythingElseRestlet.class
Now, that does the right thing only because any resource below the
root must have an
additional segment in typical directory hierarchy paths. The problem
is that the Request
instance now has a Reference where the getRemainingPart() does not
return the whole
subpath without prefixing the "name" attribute value. Then you have
special case your
attached Restlet to deal with that oddity.
Certainly the above problem can be solved by allowing more control
over the Route or
by messing with the template used by the route. It just seems
incomplete that you can
attach a Restlet to a template/pattern that says "all sub resources
but not the root" without
messing up the getRemainingPart() call.
Another simple use case is knocking out a URI (e.g. a moved or bad
resource) from amongst
valid ones by mapping it to a error handling resource. For example,
you might want to find all
paths then end with ".js" under a certain resource.
[1]
http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-01.html
--Alex Milowski
