Paul Moore wrote: > On 10/21/06, Ian Bicking <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com