Routes 0.2 released 5
- Added prefix option
- Fixed Python 2.3 bug with thread-local singleton
But hey, its a small package to begin with so what the heck. Though its only 0.2 I’m rather pleased with it so far, its performance is great and quite reliable so I’m using it in production environments already.
If you haven’t been following my blog long, Routes is a feature-complete implementation of Rails routes system. I talk more about my reasons for re-implementing Routes in Python in an earlier post so I won’t repeat them all here.
It’s fairly unique in the Python world as it will do a route lookup search to turn a dictionary back into the URL (URL Generation) that will ensure the same values are created. This allows you to generate URL’s from inside your web pages and easily add new URL schemes without touching all your web pages.
The Routes package is aimed directly at integration with Python web frameworks that support the MVC style paradigm as it returns a controller and action value with the assumption your framework will know what to do with it.
Tired of writing big regexp’s to match URL’s to a class/method for dispatch in your webapp? Pester the framework creator to integrate Routes. :)
Here’s some Python Web Frameworks that currently or will shortly have Routes support/integration:- Aquarium has a URL Connector that uses Routes. Not sure if its been added to the core or only exists as an add-on right now.
- Myghty will have Routes integration packaged with it in 0.99 which is on track to be released this week hopefully. It will also bring Python Paste support and integration which will bring a whole bunch of goodies to webapp developers and users. (Note that Python Paste requires Python 2.4)
I’ll be talking more about Python Paste and why you should care later this week. Any comments/suggestions on Routes are greatly appreciated.
What’s kind of interesting, the more I think about it, is that “controller” and “action” are really arbitrary. Viewed from just a tiny bit higher-up, this could be viewed as a way to map URLs to Python objects. What’s a controller other than a path to an object? Actions are just a convention for those objects to follow, a way of identifying a subobject (e.g., method) without actually zooming in directly to it.
There’s an interesting flattening that can occur with this. It’s like object publishing without all the piece-by-piece issues that create so many extra rules and needed features.
Exactly. In the Myghty integration I’ve done, the “controller” is merely used to indicate the object used, and the “action” is just the method to call on it. The rest of the parameters are just passed in as keyword arguments.
CherryPy, Django, and other frameworks already map it out like this. CherryPy doesn’t have the programmatic flexibility of Routes, and Django requires writing regexp’s for all its object resolution. Neither of them will generate the URL to get there though.
I’d love to see some Django and CherryPy folks integrate this, and/or hear their thoughts on it.
I might take a run at it with CherryPy—I’m thinking through a URL refactoring project for a CherryPy based application, and I’m not looking forward to it. In considering how to do this, I want to remove the absolute URLs (well – at least Base URL relative urls) from the templates and replace them with some sort of abstracted notation. This looks like it will fit the bill nicely.
Very cool. I’m looking forward to seeing it in Myghty.
I’ve played with a very simplistic CherryPy and Routes integration. Results are here:
http://www.zachary.com/s/blog/2005/10/01/integrating_cherrypy_and_routes
It’s pretty nice, through I’m still not quite sure what to do about the “default” method in CherryPy—so far it’s only “sort-of” handled.