After going through the Django tutorial, I decided to try how Django felt with a (small) real life application. I decided to port Solu (Self-service Office Resource Locator) – an application I originally wrote in Werkzeug.
Django-Solu gained two new features compared to the original: an administrator’s interface, and support for multiple maps. Administrators can add, delete and modify maps (as well as other resources), and when you create a resource you can select the map to put it on. There is no installable package, which is a regression from the original, due to the reasons described below.
At some level I was surprised how similar Django was to Werkzeug. For example, I was able to lift some unit tests and make just minor tweaks like changing a property name to get them to work in Django. There were also some very big differences, most notably in the database layer (compared to SQLAlchemy of which I have prior experience) and templates (compared to Mako Templates).
I can see how I can get stuff done in Django, but I was left puzzled with some pieces. Django seems to make a big deal about applications being self contained, so that (theoretically) you could create an app and anyone could download and install your app in their Django environment. Except this seems to fail a little bit with imports and templates, and spectacularly when dealing with static resources. Imports can be fixed by going through some hoops and modifying PYTHONPATH (which feels like a hack to me), templates by moving them inside the app directory (unlike what the tutorial instructs you to do) and calculating site root etc. in settings.py file (which isn’t actually one of the “standard” settings so you can’t rely on it), but I haven’t figured out any decent solutions for static resources. The problem with static resources is that I don’t know how to point to static resources from templates. Currently I just made these absolute paths, which may need to be edited based on deployment situation. Maybe there is a simple solution I am overlooking, since I can’t imagine Django being so popular with this kind of limitation.
The templates themselves kind of force you to not put any code in the templates, but this has in turn resulted in some bizarre constructs to work around the no code limitations. For example, the template language still allows you to do simple arithmetic with tortured syntax: my_variable|add:"-10" adds -10 to my_variable before printing it out.
The database layer was simple to work with, at least in my simple use case, although there was one point where I was stumped for a while. When searching for resources, I wanted to order the search results in certain way. But there does not seem to be a way to do that in the query syntax. Instead, you need to add a Meta class as a child of each model class and add ordering class attribute. I don’t see how this would work if you wanted to change ordering on the fly or if you have joins and want to order by attributes from different tables. It was also a little difficult to find this information about ordering.
All in all I spent 9-10 hours porting the application, which was roughly what I expected. I spent another 2 hours deploying a live demo application on Dreamhost, which was somewhat more involved than I expected.
