Hello, Aaron. Aaron said: > I think path dispatch considerations do not belong at the level > of the WSGI spec. Higher level layers should worry about > exactly how the URL gets dispatched within the application.
I agree -- That's why I believe the wsgiorg.routing_args Specification is the right place. > The higher layers can add environment entries as needed, > like "whiff.entry_point" and "whiff.template_path" etc. Right, but then why not make it standard since it could be used by 3rd party libraries or your own application? What I am suggesting is a path which represents the location of the current request in the application hierarchically. PATH_INFO can't be used because it's potentially polluted with arguments. Having this location can be useful in many situations. In addition to the examples I mentioned earlier, imagine a navigation system library: It would be able to tell where in the "navigation tree" you are right now, so you can generate breadcrumbs or just highlight the current link, among other things. This doesn't have to be framework-specific. And the dispatcher is the best component in the application to handle it. We could be a bit less strict about where to get the path from. Instead of taking the PATH_INFO and removing the arguments, Routes, for example, could merge the `controller' and `action' variables into a path string (e.g., "/controller1/subcontroller/action"). Cheers. -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | _______________________________________________ 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
