[Web-SIG] Proposal: wsgi.url_vars

[Ian Bicking]

Paul Moore wrote:
> On 10/21/06, Ian Bicking <ianb at colorstudy.com> wrote:
>> Using these two variables more complex dispatchers cannot represent the
>> information they pull out of the request path.  This specification
>> simply defines a place where such dispatchers can put their information:
>> ``wsgi.url_vars``.
> 
> But what is the point? If the receiving application uses the url_vars
> information, it's tied to the particular dispatcher - so why does this
> need to be a standard key, rather than just a private convention? If
> the receiving application wants to remain compatible with generic
> dispatchers, how can it make use of url_vars?

Just like POST and QUERY_STRING variables, the meaning and content of 
the variables is unspecified.  But it's useful that frameworks have a 
common way to parse and pass around the parsed information from those 
data sources.

An application that uses url_vars is tied to *some* dispatcher that puts 
stuff into that location (though of course the application could also 
fall back to QUERY_STRING parsing or whatever).  It's not tied to any 
particular dispatcher.  Already there's two dispatchers (selector and 
routes) that put the same kind of information into environment keys 
(just in two separate locations).

> Or, to put it another way, can you provide a realistic example of a
> *consumer* of the information?

Sure: http://bitworking.org/news/wsgicollection

It takes arguments in 'selector.vars', but could take arguments from any 
dispatcher.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org