Re: Validation of URI template parameters

Jacob Kaplan-Moss wrote:
>
> Howdy folks --
>
> So are there any plans to add some sort of validation of template
> parameters to this spec?  That is, I would love to be able to specify in
> a URI template that a particular parameter must be an integer, or must
> be less than five characters long, or...
>[snip]

This kind of thing was considered early on in our discussions but was
ruled out in favor of keeping templates as simple as possible. There are
several ways this could happen.

1. Assign validation patterns to template-names.  That is, my
application can define that the replacement for template {foo} is any
value that matches the regex pattern "\d+".  Validation would occur on
the application level rather than in the template processing level.
This can be done with the current spec without any changes.

2. Describe validation patterns within the template-names, e.g., {\d+}.
Unfortunately, the current definition of template-name does not allow
these kinds of templates (template-names are restricted to unreserved
URI characters).  Also, the current spec assumes that token matching is
greedy (i.e., all instances of a particular token are replaced with the
same value).  For instance, http://example.org/{\d+}/{\d+}/{\d+} would
expand to something like http://example.org/1/1/1.

3. Use bash-style parameter expansion (or something similar) as
suggested by Roy.  Like option #2, this would require expanding the
range of allowable characters in the template-name production but could
help with the greedy matching problem, e.g. instead of
http://example.org/{\d+}/{\d+}/{\d+}, it could be something like
http://example.org/{a:=\d+}/{b:=\d+}/{c:=\d+}

Of these three, option #1 is obviously the easiest to spec and
implement, which is pretty much why we went with it.  It's also the one
that is a closest match to current practice (e.g. OpenSearch).

For Django, the first option could work if each of your patterns
consisted of a tuple of {pattern, token definitions, values} where the
token definitions are a map of token names to regex patterns.

- James

> 
> A bit of background: I work on Django (http://www.djangoproject.com/),
> an open-source web framework.  One of the core bits of Django is a
> resolver that maps the requested path to a function (view) responsible
> for rendering that page.  This resolver currently uses regular
> expressions, so a simple set of URLs for a blog might look like::
> 
>     urlpatterns = patterns('',
>         ('^blog/$',             blog_index)
>         ('^blog/(?P<entry_id>\d+)/$',     entry_page)
>     )
> 
> (i.e. URIs like ``http://example.com/blog/`` and
> ``http://example.com/blog/145/``).
> 
> This works pretty well for people who understand regexes -- it lets me
> do some really powerful things -- but for the newcomer and the common
> case something like this URI template proposal would be much nicer.  So
> I'd love to be able to use this (proposed) standard for URI resolution
> within Django.
> 
> However, having to do all validation within view code instead of within
> the URI template itself is going to get old really quick.  In the above
> example, in my ``entry_page`` view I can be sure that the parameter
> captured from the regex is an integer; in a URI template::
> 
>     /blog/{entry_id}/
> 
> I'd have to check ``entry_id`` in that view and in every other one.
> 
> I don't really have anything concrete to propose here, but if some form
> of validation of parameters is a possibility, I'm happy to spend some
> time thinking about ways it could fit into the spec.
> 
> Thanks!
> 
> Jacob
> 
> 
>

Received on Friday, 6 October 2006 02:43:35 UTC