Ian Bicking: the old part of his blog

Turbogearsandpylonscomment000

I must concur on the dispatching being a pretty major differentiator. I did what David did and used Routes with TurboGears.

But both options seem to suffer from a similar problem - redispatch or delegation of dispatch.

In CherryPy (2, at least), you can't easily include an identifier early in a URL, and then carry on with the methods to perform on the object identified in that URL (ie, /object-type/identifier/verb, or /blogname/archives/year/month/title/edit). You basically have to reimplement the exposure-checking in your code to redispatch to another class/object - you can't just say "restart the dispatch at this point on this class". In Quixote (another object publisher), for example, this is pretty trivial to do.

The current Routes implementation (at least, as far as I can see) seems to expect only one instance of routing too. Django uses a somewhat-similar-to-use routing system, using regexes directly. But it is designed to work by delegation, meaning that the default mode of operation is to have components of sites controlling their own URLs. With Routes, it's possible to pass around the mapping object to do the same thing - I'm doing something like that with plugins in a project I'm working on - but it's cumbersome.

Of course, one of the biggest wins for Routes over the Django dispatcher, the "named routes", might be hard to reconcile with multiple mapping objects. Once you've been bitten by redesigning your URL scheme by using other methods, you'll quickly wonder why nobody thought of the url_for("article", article) construct earlier.

I've not given Pylons a full go yet, but the only major thing I missed was some guidance in terms of existing projects. Perhaps it's a bit of an WSGI thing too - I didn't know where to start shopping for middleware that does SQLAlchemy setup and rollback/commit. Google found me some code, but I'd much prefer to see what other people are using and what they have to say about it. I might have given up too early - unfortunately I didn't have the time. Maybe a TurboGears-esque usage of the Cheese Shop to build a "Usable by WSGI/Pylons" page is what would've helped me get over that little hump.

Comment on Re: TurboGears and Pylons (a technical comparison)
by Neil Blakey-Milner

Comments:

It's true that CP 2 was not quite flexible in terms for dispatching but CherryPy 3 has fixed that and comes with three builtin dispatchers: URI-to-object as current, HTTP method dispatching and Routes dispatching.

They all provide the same level of features from within CherryPy itself whil offering the flexibility many people were looking for.

Personally in the WSGI world the selector middleware is my favourite dispatcher.

# Sylvain Hellegouarch

Typically what I think is called "components" in Django would be applications in Pylons. The analogous concept in TurboGears is a little vague; making it clearer was a motivation for using Paste Deploy configuration. Typically applications in Pylons are dispatched to be URL prefix, which is pretty easy to handle recursively. You can also set up a route that consumes a prefix, and leaves the rest in PATH_INFO for further dispatching. Actually doing that further dispatching with Routes is, I believe, non-trivial -- Routes currently is integrated with Pylons in such a way that it doesn't provide a simple WSGI application frontend. I doubt this is difficult to fix, and Ben has mentioned fixing it recently. I haven't generally had a need to do dispatching like that, so I'm a little unclear about the motivation.

Notably, Pylons applications are just WSGI applications, and (especially at the prefix level) can be used fairly opaquely -- that is, you don't have to know it is a Pylons application.

Well, maybe coming to your example, /{blogname}/archives/{year}/{month}/{title}/edit -- I would implement that with my own dispatcher on blogname, that instantiated the next application. I would probably do that as middleware, putting the blog name into the environment and expecting the Pylons application to pick that up. Thus the Pylons application would only implement one blog at a time, but the dispatcher would instantiate the application dynamically, turning that single instance into a farmable blog system.

# Ian Bicking

What do you mean, "Routes currently is integrated with Pylons in such a way that it doesn't provide a simple WSGI application frontend"? What would this look like?

# Mike Orr