[Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification
me at gustavonarea.net
Thu Jan 7 20:49:09 CET 2010
> 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
> 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.,
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
More information about the Web-SIG