Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development > Usability

Web Design Reference Guide

Hosted by

Delving Deeper Into Django

Last updated Oct 17, 2003.

By Faruk Ates

In my comparison article last month, I briefly discussed Django, the Python-based "Model-View-Controller" web framework that’s becoming increasingly popular. It was a quick run-down of Django that looked at its basic philosophies and how it works, but never really got into the nitty-gritty of it. This month, I take a closer look at what it’s like to work with Django, so that you can get a good feeling for it.

Why did I choose Django and not Ruby on Rails? The answer is simple: Django is more suitable for a web site like InformIT.com, plus, well, I like it better. Due to space constraints, I’m not going to get too technical here; instead, I’m going to look at Django mostly from a workflow perspective.

The Basics

With Django installed, you start a web site by starting a new Django project. Django projects constitute the core of your web site where you’ll configure database settings, site project settings, and modules used by your project.

A Django project is located outside of the web-accessible document root, which increases the security of your web site (because files containing code can’t be viewed on the Web, should anything ever go wrong) and allows you to store the project on your server wherever it’s most convenient for you.

The new project comes in the form of a directory containing four files: an __init__.py that tells Python this directory is a Python package; a manage.py that you use to interact with your project; a settings.py where your project settings and configurations are stored, and the very important urls.py, which controls the URLs for your site. I’ll have more on that later.

But simply having a project made in Django isn’t enough—it’s like having a web site without content, fully operational with no features at all. So let’s add something!

Every content feature in Django is called an app (for application), a simple package that serves one purpose—a weblog, a photo gallery, a poll—and is made in a way that allows you to plug it in and out of Django projects. For example, you can plug someone else’s blog app into your project and you’ll instantly have a ready-for-use weblog feature on your site.

Creating an app is as easy as creating a project, which is to say, it’s a simple one-line command. We’re not getting too technical here, but if you truly want to get your hands dirty with a real, working project of your own, the Django tutorials are a great place to start.

An app comes in the form of a directory that contains two unique files of its own: the models.py, where you put your database model information for the app; and the views.py, where basically all of your coding work takes place. The views file contains all programmed functionality, but if you’re not in need of specifically programmed features, you can use Django’s built-in "generic views" system.

Generic views let you provide common views without writing any Python code. Put simply, they offer you a very quick, easy, and simple way to put relevant data from the database into a template; you can work out the details of how to present that content in the template itself. No processing, simply retrieve and present.

As you build your web site, you add more and more apps to your project, each serving its own purpose. But how do you make an app work with a certain requested URL on the site? That’s where the urls.py file comes in.

In this file, you configure the link between a requested URL and an app in your system. You instruct Django to execute a specific view (this can be a Generic view) when a user enters a certain URL, and that view will then load the template you specified and return a page to the user.

Templates in Django

The template system that comes with Django—which you aren’t forced to use, but it offers so many advantages that you’ll almost definitely want to use it—is one of its main attractions.

When a template is loaded, it is also passed one or more objects from your view. These objects generally contain the data from the database relevant to the requested URL, and putting the data into the template is as simple as writing {{ article.headline }}, where "article" is an article object and "headline" is one of the fields in the object.

However, it’s the template inheritance that’s the most convenient. Most sites are built off of a "framework"—the header of the site that’s always the same, the menu, and a footer. It’s the content in the middle that’s unique across different parts of the site. With Django’s template system, your templates for each specific page need only contain the unique parts that then get "injected" back into a base template.

Imagine this base.html template for instance:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

  <head>
    <title>{% block title %}My site{% endblock %}</title>
  </head>
  <body>
    {% block content %}{% endblock %}
  </body>

  </html>

Imagine you’re looking at a blog post on the site that uses the above template. The template you call from your view could look like this:

  {% extends "base.html" %}

  {% block title %}{{ post.title }}{% endblock %}

  {% block content %}
    <h1>{{ post.title }}</h1>
    <p>{{ post.body }}</p>

  {% endblock %}

This template would then inject the contents of the "title" and "content" blocks into the base.html template, and send the populated base.html page to the browser.

The system also offers a lot of functionality to utilize inside the templates, such as filters that you can pass variable content through. Have a datetime object that you want to present in a human-readable string? Simply pass the variable through the date filter like this: {{ post.pub_date|date:"F j, Y" }} which would present something like October 1, 2006.

Workflow Flexibility

As the database configuration—the model—for a Django project is contained within each app, it’s very easy to switch between database systems or development environments.

This kind of flexibility is also found in the plug-in nature of the Django apps utilized in the project. After you decouple your app from the project you built it in, you can simply re-use that app in every other web site you create next, where desired.

Django’s template system further increases workflow flexibility and optimization. It makes it incredibly easy to architect and plan out a large web site in regard to the HTML, CSS, and JavaScript work. The inheritance aspect keeps everything clean and manageable, and templates can be decoupled from a project along with the rest of an app, so you can plug-and-play them into other projects including their markup.

The built-in admin interface adds the finishing touch. It can be styled easily through CSS to match the look of your web site, and the Models part of Django allows you to pre-configure the behavior of the admin interface, making it easy to optimize workflow when managing the content of the site. Almost everything is customizable, so it’s unlikely that you’ll run into complications.

Building a web site with Django is a very logical and straightforward process. Even if you’re not familiar with Python, you should have no difficulties getting started and having a small web site running in no time. One of Django’s primary goals was to eliminate all repetitive and monotonous tasks that come into play when doing web development, and as far as I’m concerned, it has achieved this goal.