Beyond the Django Tutorial

Originally when I wanted to get into web development, I was looking for a good Python framework to learn.  I’ve been following Django for a while, and have been impressed by the community that has sprung up around it.  After some major life changes, new found familiarity with CSS and HTML5, and the Django 1.4 release, I decided it was finally time to jump in.  These are some of the speed bumps I encountered while starting my first few projects beyond Django’s tutorial Poll app.

Choice Sets

I decided to try using choice sets for a few fields.  They are nice in that they let you configure a list of coded values.  However, getting at the long form descriptions was a puzzle to me initially.  Before I noticed the get_FOO_display() function, a friend pointed me to this Stack Overflow question.  The last entry was perfect for my needs:

def get_display(key, list):
    d = dict(list)
    if key in d:
        return d[key]
    return None

I suspect that with a little effort, I should only need to rely on get_FOO_display().  However, with a free standing choice list, get_display() may come in handy.

Dumping your data

During the early stages of fleshing out a model, one generates a nice set of data.  While one could manually recreate it, it quickly reaches the tipping point of tediousness.  In the course of developing your data model, there comes a time when you will want to modify your data structure in a way that will conflict with a previous version.  For me, this first came trying to add a BooleanField and getting the following error message: “no such column”.  I updated my model and ran syncdb, what do you mean no such column?!?  With some assistance, best I could figure is that Django didn’t know what to do with the previous rows.  Since I’m still in the very early stages of designing my app, I decided to dump and rebuild my database.

While it is not outside of the realm of possibility to manually re-enter the 4 rows (plus related entries) I had already accumulated, that can be a major pain to do so.  I know there are tools like South to help with data migrations, but that is overkill for my needs at this point.  Fortunately, Django provides a way to save off and reload your data.  This is what I worked out for my toy projects (having an sqlite database in database.db):

python dumpdata [appName] --indent 2 > dumpfile.json
rm database.db
python syncdb
python loaddata dumpfile.json

Delete the database, re-sync everything, load the file.  Magic.

python runserver

Took me a few missteps to remember this command to enable the development web service accept outside HTTP requests. Figured that was as good a sign as any to write this one down. Excerpt from the Django tutorial:

If you want to change the server’s IP, pass it along with the port. So to listen on all public IPs (useful if you want to show off your work on other computers), use:

python runserver

Other learning mistakes…

  • When setting up a view-template, I naively tried to pass MyModel.objects which does not return a queryset.  You need to call a method like .all() or .order_by(field).
  • By having a URL in my main project with pattern “^myapp/$” – that trailing “$” prevented django from looking into my app’s file.

Other good resources

I stumbled upon this site a while ago: Django by Example which has several good examples including a To-Do list, a simple blog, a photo organizer, a forum, and a calendar.  I haven’t tried these yet on 1.4, but am planning to in the near future.

Another good jumping point I’d like to dive into further once I get more comfortable with Django:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s