(Motion Sickness

Now that I've made two working web site using Django and Turbogears I can speak a little more intelligently about them. There were things I liked and disliked about both of them, but I found them both to make if fairly easy to put a site up in a short amount of time.

Turbogears

In fact this website itself is running on Turbogears. It only took a few weeks to build the site - although it's not complete. A few quick observations:

• SQLObject: the documentation is a little weak with this project. It's actually difficult to tell how to delete an object. Also, a query involving a date ended up being specific to what database I was using. Mysql has the func.YEAR function, but with Postgresql I had to use func.DATE_PART. The ability to filter a list after you've declared it is nice So I could say posts = Post.select(orderBy=date).reversed() and then do posts[:10] to limit it to 10. And in some ways the lack of documentation was nice, because there was not a lot to look through. That adds to the simplicity factor.
• Kid: I would like to see a case statement in the api. There is a py:if, but no py:choose, py:when, py:otherwise kind of construct. I do like the general concepts of the template engine though. And the fact that it is already xml made the rss feed simple. Also, it seems like standard html entities should be recognized when the DocType is Xhtml. But it does not seem to recognize nbsp This led to a secondary problem (see later). Overall though Kid is very well conceived. Much better than TAL.
• Mochikit: Strangely difficult to add html to a page from pre-existing html ( I wanted to do a preview for Restructured Text. I ended up using the innerHTML method. Also, like all Javascript - when something was not working it was difficult to debug. I did like the nevow like mechanism for working with Xml though. That is very well thought out. And the project is documented well. I am noticing a convergence of good ideas. It seems to be Ruby influenced - and Nevow inspired.
• Cherrypy: Some kind of url mapping like the Rails mapper would be good. I did find a python version of Routes but couldn't quite integrate it into the framework successfully. The simplicity of this server is nice. For instance, just by adding an XmlRpcFilter object I had XmlRpc capabilities. The filter idea has a lot of potential. I set the server to run via scgi see here. If you are reading this than that is working.

When I switched to my main server - the encoding interpretation on all the pages seems to have changed - so the space code  turns into a strange looking A. I'm still trying to fix that.

If you are using Postgresql - make sure you have the mxDateTime module installed. Before I installed that I was getting strange behaviour. Including a shutdown error that would take turbogears down with it, and I could not make my database tables from tg-admin sql create (it would fail by saying something like error in Sql - in create table post - relation author does not exist or something to that effect).

Django

A lot of nice things about this framework. Good documentation, fairly complete api, and free editing screens that are actually usable. And once you get used to the named conventions get_FOO, the work flies by quickly. The fact that it often fails silently when something goes wrong is good sometimes, but can make debugging difficult.

• No 'or' query. This makes setting up a search page a real chore. I would guess this will be fixed at some point
• The FileUploadField will only upload to a single given directory. This is a problem when you want to give individual users their own folders. I tried using the _post_save(self): method to move files after they were uploaded, but the file does not exist at that point. This is a major shortcoming to me. But I noticed a lot of people complaining about this, and a ticket that marginally addressed it - so I'm guessing it will be fixed.
• I did try to write my own extension to take care of the file upload problem, but then I started to get Zope deja-vu. There is nothing easy or intutive about mucking around with the Django Api. Using it is very intuitive, but I wouldn't say extending it is.
• Although the admin screens are good - I still had problems getting a select/option list to limit it's options when the relations were stacked 3 deep (i.e. a screen with adding for Books, Chapters, and Pictures to an Artist all on the same page). This is not a problem I have solved.

As far as deciding which one is better, I'm still on the fence. On the one hand Django is more polished and ready for use in production. Turbogears is still rough. Working with if feels cruder. On the other hand cherrypy, SQLObject and Kid are all very much in line with the concise simplicity of Python. I don't think it is possible to say one is better than the other. Ideally I would continue to use both.