[Web-SIG] Proposal: wsgi.url_vars
Ian Bicking
ianb at colorstudy.com
Sat Oct 21 21:46:26 CEST 2006
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
More information about the Web-SIG
mailing list