Our Journey to a blog with django - Part 3: Lessons learned during coding

Last Update: 14.09.2007. By azarai in django | python

This time i’ll talk about my experiences made by building our blog/tiny cms system. It’s still in development as some features are missing i’d came up since Part 1 and like to implement, but its already in a useful working state and it urged me to switch :-) The code will be published when i am sure where to host svn and which open source licence i’ll use.

If it’s your first time, as it was for me, coding a project in django you’d probably need some time to get familiar with the django way. It’s like learning any new API/Framework with alittle difference. It’s well documented(!) and fun to learn. For almost all of the “problems” i encountered i found either a solution or tip in the django docs, wiki, group or djangosnippets. Some blogs and django related code in google code where also helpful. But lets start with the issues i had.

Integrating markdown and pygments:
At first i took a snippet from djangosnippets even i wasn’t quite satisfied with it as i had to use another library (beautifulSoup). Thanks to a comment on another snippet i found a better solution. python-markdown can be extended with plugins and theres already one for syntax highlighting with pygments. No additional library required! Installed the libs, adjusted my render tag a bit and it worked like a charm.

Unicode:
I develop on windows and host on a *nix server. While testing the app after deployment i got some unicode encoding errors while rendering. I am not sure if i just forgot to test this locally or it behaves actually differently. markdown and django work fine with unicode and i traced it down to an error of mine. I passed the wrong type down to markdown. Not sure why it changed as it should be unicode already, but i simply made sure it is. django provides some supporting methods) for unicode encoding tasks.

Using django comments:
The current django comment system did lack some fields i’d like to collect for commenting and the new version isn’t out yet. I copied it to a new package and made my changes. I hope to avoid django update problems and changing to a better solution easier later. Time will show. One can either wait for the django solution, use the current comments system or build an own (and contribute). I didn’t like to wait, neither was willing to spend the time on a commenting system which might not used much here.

Tagging:
As probably most people i implemented my own tagging system in the first way. It’s easy. However one can avoid even this time and use django-tagging instead. I discovered it after i’ve done our own, but switched to django-tagging later. It has much more features, is well tested and easy to use.

URL handling:
I am not a big fan of django URL handling and specially get_absolute_url. Probably everyone has its own opinion about wether a model should be tied with view information or not. I prefer a strict(er) separation of both. But the design of django is so fine that one is not forced to use it at all. Against my own concerns i used get_absolute_url for the admin console as it was less work for me, pragmatism wins :-)
The other point is that theres no way to add an url prefix at one centralized point, i.e. settings.py, which is used for every single url output, specially for generic views. In normal installation modes there might be no need for this, but here at webfaction my django instance (with its own apache) is running behind a proxy. The url my django instance is mapped to won’t be submitted to the django instance, at least i didn’t find a way. This wasn’t a major problem for us as i didn’t wanted the mapped url prefix im my public urls anyways. I handled it via some mod_rewrite rules.

Conclusion:
In general i am satisfied with django and will recommend it to others. All the time i had the feeling that the django parts work well together and in the same time i am not forced to use them. It seemed as its standing out of my way, but still offers me solutions how i could solve my problem/wish. Normally the first project in a new technology is developed it bit slower then usual, but i think i couldn’t have done it in almost the same time with a different technology. At least not with one i like or including the wasted time to write boilerplate code.

How was your first django project? Share your experience.