Routes

Ah yes, time for another release. This time its Routes 1.3.1, nothing too big to see here, thus the minor version increase. However if you were using Routes with the prefix option its highly recommended that you upgrade as there were 2 bugs ... [More] specifically when used with that option that have been fixed. Also, for those that want all their URL’s to end in a /, there’s now a append_slash option that will ensure URL’s are generated exactly how you want them to be. Enjoy! [Less]

I got Routes 1.2 out the door today, it’s a fairly important update for 2 reasons: A bug crept in with 1.1 using the default controller directory scanner. The scanner wasn’t properly retaining the directory prefix which causes mismatches when ... [More] using controllers underneath a sub-directory. url_for can (and should) be used for all your URL needs, including static files The second one is pretty important if you’re at all interested in creating portable web applications that can be used along-side other applications. While some frameworks provide generation of URL’s that lead to other web pages, hard-linking the other ‘static’ content will cause problems if you try and use the application under a different mount point. Instead of using a url like /css/source.css it should instead be generated with url_for('/css/source.css'). This way Routes can ensure that if you’re running under a WSGI environment and there’s a SCRIPT_NAME present (this indicates the applications location), it will be pre-pended to your absolute URL’s. When used like this, additional keyword arguments passed in will be used as query args on the URL making url_for a handy way to create URL’s that are properly URL encoded. Another useful feature that made it into 1.2 allows you to alias URL’s you might want to use throughout your web application, I call these static named routes. An example can be found in the named routes section of the Routes Manual. Enjoy! [Less]

I’ve released Routes 1.1 today after extending the unit tests for the new Groupings syntax and updating the docs. The new syntax is quite powerful and will hopefully make everyone using Routes rather happy. While I’m not about to encourage anyone ... [More] to use URL’s with .html at the end, there’s plenty of times when you want extensions to mingle with dynamic parts. You can also get some useful abilities like being able to pull out the extension like so: map.connect('archives/:category/:(section).:(format)', controller='archive', action='by_extension') This makes it easy to toggle the response depending on the extension, and the regexp business is handled for you. Integration Enhancements An additional feature, suggested by a Routes user was to make integration easier in WSGI environments. Earlier, at the beginning of each request you would have to populate the Routes config with the host, protocol, and match result. Now, merely passing the WSGI environ to the Routes config object will run a match, and populate those attributes for you. The Routes Mapper now can take a function that when called returns a list of valid controllers. If you want to use the directory scanner Routes comes with, all you need to do is pass in the directory you’d like to scan and Routes will scan it for you. These two new integration improvements make it rather simple to integrate Routes, here’s a basic WSGI app showing this off: #myapp.py from routes import * map = Mapper(directory=’/my/directory/of/controllers’)map.connect(’:controller/:action/:id’)map.connect('home’, '’, controller='home’, action='splash’) class WSGIApp(object): def init(self, mapper=map): self.mapper = mapper def call(self, environ, start_response): config = request_config() config.mapper = self.mapper config.environ = environ if not config.mapper_dict: start_response(“404 Not Found”, [(“content-type”,“text/html”)]) return [“No match”] else: start_response(“200 OK”, [(“content-type”,“text/html”)]) return [“Match with the following dict: %s” % str(config.mapper_dict)] That’s it! If you’re not using WSGI, there’s been no backwards breakage so the old style of setting up all the attributes of the config will work fine as well. So, now I have to figure out if there’s anything else Routes should possibly have… or is the only space for improvement at this point further optimization and perhaps usability improvements? [Less]

The major feature I was waiting on for Routes 1.1 is for the most part done, mainly adding more unit tests for the new syntax now. As I mentioned previously when announcing Routes 1.0, this feature is the one quite a few people have been waiting for. ... [More] The ability to split the route path somewhere other than on a /. Here’s what a few Routes using the new feature look like: map.connect(’:category/:(page).html’, controller='stories’, action='view’) map.connect('feeds/:(section).:(extension)’, controller='feeds’, action='formatter’) map.connect('archives/:(year):(month):(day).html’, controller='archives’, action='view’, requirements=dict(year=r’\d{4}’,month=r’\d{2}’,day=r’\d{2}’)) The new section dividers, :(something) can be used side-by-side as the last example above shows, however in such cases each path part must have a rigid regexp requirement placed on it to ensure proper collection of the variables. Typically you will have some characters in between each dynamic part so this issue doesn’t arise. I’ve retained full backward compatibility with the old syntax as well, if you don’t designate the dynamic part using the () modifier it will fall back to looking for the next / instead. So far, all the existing (and extensive) unit tests are passing, in addition to new tests I’ve been adding. Routes generates a full regular expression for URL matching based off the route path you give it. This makes it a great way to setup URL routing with the power of regexp’s yet avoiding the hassle of writing a large complex regexp yourself. The other very powerful ability you gain is that Routes can turn the keywords back into the URL, like so: >>> url_for(controller='archives’, action='view’, year=2004, month=10, day=12)‘archives/20041012.html’ >>> url_for(controller='feeds’,action='formatter’,section='computers’,extension='xml’)‘feeds/computers.xml’ If you’re interested in giving it a spin, it can be checked out and installed easily from the svn repository using setuptools: sudo easy_install -U http://routes.groovie.org/svn/branches/newsplit Feedback / Suggestions / Bug Reports greatly appreciated. [Less]

I’ve finally finished the documentation for Routes and as I mentioned earlier regarded releases am now ready for a 1.0 release. If you’re curious about Routes and want to get up to speed, I’d suggest jumping straight to the Routes Manual. Routes is ... [More] currently used in Myghty with the routes Paste template, and has been integrated for use both in Aquarium as well as CherryPy (though CherryPy 2.2 should allow better integration). Now that Routes is feature-equivilant to the Rails version, its time to start planning for new stuff. The first and most obvious is to allow for more advanced configurability of URL’s by allowing for a new separator. This would allow you to get as creative as you like with URL’s, so you could do something like this: m.connect('archives/:(article)-:(page).html', controller='blog', action='view') m.connect('feeds/:section/:(format).xml', controller='feeds', action='xml', format='atom') This should make for a nice 1.1 feature. For those familiar with the Rails system of Routes, has there been anything you’ve found lacking or were just itching for? [Less]