Half-baked CherryPy
As part of my work on the Identity framework for TurboGears, I’ve had to write a filter for CherryPy. While I’m certain the team building CherryPy is well meaning, I doubt whether there’s a coherent design in place.
For example, because CherryPy doesn’t allow filters to catch and handle exceptions thrown, er, raised by the controllers, I’ve had to resort to throwing, er, raising an InternalRedirect exception which is somewhat strange.
One of the latest features of the framework raises an IdentitySessionExpiredException when your login has expired (um, duh?). However, because only the filter is able to check your identity credentials to determine whether your session has expired, I need to redirect as part of the beforeMain filter function.
Wouldn’t you know it? This just happens to be outside the function that catches the InternalRedirect exception when it’s thrown, damn, raised. Of course, I could fuck with the internal and almost entirely undocumented cherrypy.request.objectPath. Why is this even necessary?
Fortunately, all of this Python stuff ships with source code. After pouring over the code for CherryPy, I’ve discovered I can magically change the cherrypy.request.objectPath value to the URL I would normally use as the parameter to InternalRedirect.
Inadvisability of casting stones
Of course, there’s likely to be someone who’ll point out that I still haven’t documented the Identity framework. That’s definitely true. I’ve been meaning to, but this whole product release at work has taken most of my attention and the rest has been consumed by writing an ORM for Python (I’m trying to crossbreed Hibernate and CoreData). But I haven’t forgotten my obligation to document what I’ve built. Ultimately, the docs will include this spiffy diagram drawn in OmniGraffle.
I hope to get started on the documentation this weekend. After all, I will be committing some changes to the framework to make it a little more customisable — perhaps not as much as some would like, but more than it already is. Of course, I’m getting really close to being able to read & write from SQLite with my new ORM, so maybe that will be more pressing.
And there’s more painting to be done too…
Comments
Yeah, CherryPy looks great at first… until you try something slightly complex with it, and end up having to run everything through default() so it can handle forms with lots of inputs, and manually handle redirects, cookies, sessions (something like “warning: this isn’t thread safe”), etc… Some things it might handle but with a lack of documentation it’s faster to do it yourself. CherryTemplate has various glitches (e.g. filling in template values with old data if you left any variables out, which could expose user A’s data to user B; not handling start and end tags well; near-useless error messages when it can’t parse things). The python-hosting site, done with CherryPy, is very simple. The CherryPy site is actually a Trac site. What’s that about eating your own dog food..?
Give me a break! Plenty of sites don’t “eat their own dog food”. Not because their software is bad, but because some other software was more convenient or focused on the specific need. Why should you build something from scratch when there are plenty of ready-made solutions already out there?(wikis, forums, project tracking…)
Besides, the CherryPy site has testimonials and success stories that demonstrate the usefulness of CherryPy.
http://www.cherrypy.org/wiki/CherryPyUserTestimonials
http://www.cherrypy.org/wiki/CherryPySuccessStory
Why not just use Django?
Jason, I don’t know. Some of the ORM code in Django looks a little weird to me. But I don’t doubt it works, just it feels a little uncomfortable.
Mind you, given my discomfort with SQLObject, I’m not certain whether Django would be better or worse.
I’m in the process of coming up with a new platform for my Web site here, so maybe I’ll give Django a look.