Winnipeg Web Design

Django Tutorial: Blog Basics

Today we’ll be learning the gist of Django, a pythonic web framework. In the spirit of a stereotypical web framework django tutorial, we’ll produce a primitive blog with the minimal amount of code possible. Yellow background color text indicates text to be entered into a command line/terminal and blue indicates code. If you’ve followed my django screencast, you’ll be familiar with the most of what this tutorial covers. However, I’ll explain the code in this tutorial in more depth than I did in the screencast. If you like to know what everything does, this article is for you.

If you’ve never dealt with (or even seen) python code before, I recommend skimming through python’s official tutorial. The most notable difference between python and most other languages is that tabs/spaces are used to indicate code blocks. So an if statement would look something like this:

if myvariable == True:
    print “myvariable is True”
print “Always printed”

One other thing to note is that boolean variables are True and False (case-sensitive). It’s also a good idea to dust off your terminal / command line skills (cd, ls, etc.).

Table of Contents

Installation

If you’ve followed another django tutorial, you’re all set. Otherwise here’s some brief steps to follow.

1. Download & Install Python 2.6 (via python’s site or apt-get)
2. Install your database engine of choice and it’s associated python library. I use sqlite3 when developing because it’s lightweight and requires no db login information. As an added convenience, pysqlite is pre-bundled into python 2.5 and beyond.
3. Install Django. This is can be either the latest official build or the stable (in my opinion) subversion repository. Use the svn url, http://code.djangoproject.com/svn/django/trunk/ for checkout. If you’re using a terminal/command line system, type:
   svn co http://code.djangoproject.com/svn/django/trunk/ django to download the trunk release to a django subdirectory. While in that directory, use svn upto update your repository when needed. I’ll be using the svn revision #10071, although any 1.0+ version of django should work just fine.
4. (For windows) Add your (python path)/scripts to your windows PATH environment variable. See video if you’re unsure how to do this. You may need to reboot afterwards.
5. If typing the django-admin.py command in your command prompt/terminal doesn’t give you a missing command/file error then you’re all set! If you prefer not to have it in your PATH variable, you’ll have to refer it via an absolute path from your python/scripts/django-admin.py.

Alternatively, you could try using a DjangoStack installer, but I’ve never used one so I can’t say how easy or hard it is.

Development Methodologies

Unless you’ve been hiding under a rock or are completely new to the web development community, you know that Model-View-Controller (MVC), is the latest craze is the web world. This provides a clean separation among:

• Code that interfaces with data resources (usually from a database) [Model]
• Logic for each type of page a user can visit [Controller]
• Html or other response output to the end user [View]

Django is quite similar, although it uses the name MTV (Model-Template-View) instead. This is slightly confusing for people coming from other MVC frameworks since a MVC Controller is a View in Django and a MVC View is a Template in Django. I’ll be referring to everything in terms of Django’s MTV in the remainder of the tutorial.

Django templates have their own template language which is relatively easy to grasp for programmers. It’s catered for web designers (not programmers) to manage logic that directly deals with how to display data. The templating system is designed to be as minimal as possible and specifically excludes any feature that doesn’t relate to the display logic (e.g. variable assignments are not allowed). Although the templating system could be extended to implement such features, most of that code really belongs in the view.

For more information, you can see the entire laundry list of Django’s philosophies.

---

Getting Started

I prefer to run instead of walk first, but that’s just me. Let’s create a django project using django-admin.py startproject myblog to create a myblog directory containing our django project.

We’ll edit settings.py and enter our database information:

DATABASE_ENGINE = ‘sqlite3′
DATABASE_USER = ‘sqlite.db’

Fill in other database information if your database engine requires it (which is anything other than sqlite3). You can edit your TIME_ZONE to be closest to your server location (or your location if you’re running it locally), but it doesn’t really matter too much for us.

File paths in settings.py must be absolute. This is because a relative path isn’t explicit (one of python’s philosophies) since it could refer to either where django’s site-package location (where some provided addons reside) or your current working directory (where you executed the command to start the server) or your project directory. Instead paths are all absolute. Since we’re going to make all our relative paths relative to the project directory, or settings.py to be more precise, we’ll add the following code snippet to the top of our settings.py to automatically convert all our relative paths we specify to absolute paths.

import os
rel = lambda *x: os.path.join(os.path.abspath(os.path.dirname(__file__)), *x)

The first line imports the python-provided os module which provides us with path-related functionality.

We then join a series of paths (which will figure out the appropriate directory separator based on the operating system) which includes the absolute path determined by the directory name where this file resides (settings.py) and any directories we provide in the function parameters. *x expands the x array and passes to the function as parameters.

Now we can provide relative directories from our project directory. Let’s specify those now in settings.py. Make the following changes (or change them to whatever you feel is right):

MEDIA_ROOT = rel(‘media’) # media subdirectory in the project directory

MEDIA_URL = ‘/resources/’ # for the variable we get to use in templates, later
TEMPLATE_DIRS = (
    rel(‘templates’),
)

If you wanted all the media and templates in one directory you could do something like:

MEDIA_ROOT = rel(‘resources’, ‘media’)
MEDIA_URL = ‘/resources/’
TEMPLATE_DIRS = (
    rel(‘resources’, ‘templates’),
)

Save, and we’re good for now.

Creating Our First Application

What good is a blog without any posts? Our first application will provide the framework for a blog post. So in the project directory execute django-admin.py startproject posts or python manage.py startproject posts to create a subdirectory and application names posts.

The following files in the new directory are as listed:

• __init__.py - same reason as the project’s __init__.py
• models.py - contains classes that pertain to data to be stored in the database and their mapping to python as classes.
• views.py - contains functions that the project’s urls.py can map to. They provide the “glue” to your database data and your templates.
• tests.py - Provides a file to perform unit testing for the application.

Before we implement anything else, we should probably create the models for our app. Our post model is going to be minimalistic. So open up models.py and append the following:

from django.contrib.auth.models import User
class Post(models.Model):
    author = models.ForeignKey(User, related_name=’posts’)
    title = models.CharField(max_length=200)
    body = models.TextField()
    pub_date = models.DateTimeField(auto_now_add=True)
    up_date = models.DateTimeField(auto_now=True)
    def __unicode__(self):
        return self.title

This is presents our data for our model which inherits from django’s Model class. The first line imports the django-provide User model, which adds users support for our project, including authentication and permissions. But in this case, we’re using it to associate a user who creates a post to be the author of it. The named key parameter related_name is the variable name the User model should have to store the list of posts. By default it is <model_name>_set, but here we’re specifying it as posts.

Each post will have a title field which is a database char field whose max length is 200. This is validated both via the database (assuming you use Django to create the tables) and by Django when the model is saved. The body field is self explanatory, create a field to store a large string of text. Pub_date and up_date store datetime fields in the database. The auto_now_add keyword parameter sets the field to the current date time when the model is being added to the database (not when saving changes). Likewise, auto_now applies the current datetime whenever the model is saved.

Finally, we have a __unicode__ method defined. This is simply a unicode string to return when a post instance is requested to be displayed automatically.

That’s all the models we need!

Next, we’ll need to add our application to our project. Add the following line to your INSTALLED_APPS variable in settings.py:

‘posts’, # whatever you named your application

So you INSTALLED_APPS should look something like this:

INSTALLED_APPS = (
    ’django.contrib.auth’,
    ’django.contrib.contenttypes’,
    ’django.contrib.sites’,
    ’posts’,
)

It is worth noting that applications are loading in order they are listed. So your applications should always be at the end since they’ll usually depend on Djangos’ built-in applications.

We can tell Django to create all the tables in INSTALLED_APPS based on what the models defined. This can be done with python manage.py syncdb.

When creating tables for django.contrib.auth, it asks you to create a superuser, do so since it’ll allow you to login in the admin interface we’ll be discussing in the next section.

We will be continuing Part II tomorrow so stay tuned by subscribing to the RSS Feed

Be Sociable, Share!

• 

Related posts:

1. A Detailed Django Tutorial: Blog Basics Part II
2. A Detailed Django Tutorial: Blog Basics Part IV
3. A Detailed Django Tutorial: Blog Basics Part III
4. Django Python Framework
5. Ruby on Rails To Do List Tutorial

Written by Brenley Dueck