[Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification

[Gustavo Narea]

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 |