First steps with Django

I really like PHP and well Django is based on Python so I've been slow in getting around to looking at it. Anyway Stuart and Cyril have been raving about how great both Django and Python are recently so this weekend I finally sat down and spent a few hours with Django. I thought I'd jot down my thoughts/discoveries so far particularly as one or two things tripped me up and whilst it might just have been me being a bit stupid I'm pretty sure I won't be the last. I installed Django on Mac OS X so no doubt some of the issues I encountered may be different or possibly aren't present on your set up.

MySql

Whilst trying to use MySql with Django I found that:

1. Python doesn't include MySql client libraries by default. You need to download and install the MySQLdb package manually.
2. MAMP (which includes MySql) doesn't ship with the MySql source header files needed to build the MySQLdb package. Instead download a Mac OS X installer for MySql from mysql.com.
3. Make sure the folder location of the various MySql binaries (mysql, mysqladmin etc) is included in your path (check with echo $PATH). If not modify your .bash_profile accordingly and source (. ~/.bash_profile) after making changes.
4. If you get an error similar to -

   ImportError: dlopen(./_mysql.so, 2): Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib

   - when trying to build MySQLdb it's caused by an incorrect path specification. The easiest way to solve this is to run "cd /usr/local/mysql/bin; ln -s /usr/local/mysql/bin mysql" as described here to sym link to the correct place. Obviously there will be better ways to solve this.

Onto Django

Here's what I particularly like so far:

• The documentation and Django book. They're fantastically clear and the only time I went wrong was when I wasn't paying enough attention to them (a classic case of not RTFM). I wish all projects did it this well.
• Being able to query models from the python command line shell. It also doubles as a fairly quick (and I guess scriptable) way to add test data to your database.
• The URL configuration mechanism. It's very flexible and I like the way one can separate URL configuration for specific applications from the main URL configuration file. It also affords your application greater security through default input filtering (assuming you write good regular expressions) - a view is never called if data passed in the URL doesn't match the regular expression. The MTV model used by Django makes much more sense to me than the standard MVC model used by most frameworks.
• Configuration of template paths in settings.py (within your project folder). You can specify as many different search paths as you want and Django will search each one in turn until it finds a matching template. I see some potential for supporting different types of "localised" templates. Could these paths incorporate a dynamic element I wonder? Additionally the block tag syntax within individual templates looks like a really good way to cut down on the number of templates required, for example page.html instead of header.html and footer.html for one's base layout, as well as providing another way to "localise" template regions in specific instances. It should be noted I use the term "localise" fairly generically. I'm not just talking about localisation in the internationalisation sense.
• Python's decorator syntax. In Django this allows you to specify caching or require authentication for individual views by adding a simple one liner above the view's definition. No need to mess with the logic of the view - nice!
• The flexibility of the caching - cache the whole site, specific views or individual items of data and Django has in built support for a number of different caching mechanisms - memcached, database or file based as well as simpler single process and dummy caching mechanisms for use during development. The dummy mechanism looks particularly useful in allowing you to add your caching code without actually being burdened with cached pages during development.
• The admin interface of course. I was surprised how configurable it is from the application models.py file and I like that you can override templates files corresponding to the admin interface on an individual basis without having to modify the stock set.
• The "sites" framework. This add-on allows you to associate content in your database with one or more sites which use that content. You could use this, for example, to publish the same article to two sites with one hit. This feature also integrates editing into a single instance of the Django admin interface.

So far I've only scratched the surface but I'm really, really impressed in fact so much so that it's hard to overstate. So where from here? I'll probably start by replacing phpMyAdmin with Django to administer the content on my site. Jeff Croft wrote an interesting post about doing just this a while ago.