Step Six: The Views and Templates

by Andy Boyle.

Now that the database is set up, it’s time to make our views and templates work. In essence, the views talk to the models, or the database. The templates then talk to the views and spit out the content. It’s super awesome.

So, let’s edit our views.py file. That will be located in /opt/django-projects/firetracker/fires/

Here’s the code to copy and paste into the views.py and then save:

from firetracker.fires.models import State, City, Address, Department, Station, Title, Person, StoryLink, Injury, Victim, Fire, Cause

from django.shortcuts import render_to_response, redirect, get_list_or_404, get_object_or_404
import urllib
from django.conf import settings

def index(request):
    fires = Fire.objects.all().order_by('date')[:5]
    return render_to_response('index.html', {
        'fires': fires,

def fire(request, address, un_id):
    fire = get_object_or_404(Fire, location__street_slug=address, id=un_id)
    return render_to_response('fire_detail.html', {
        'fire': fire,

def person(request, slug, un_id):
    person = get_object_or_404(Person, name_slug=slug, id=un_id)
    return render_to_response('person_detail.html', {
        'person': person,

The first line brings in information from your models.py file, pulling in all of the classes we plan on using. The next few lines are to say “hey this is a views.py file!”

Line 7 is where we set up up our first page. This is the index, which will be our main /firetracker/ page in the URL. We will set up the URLs later in this post. But for now, let me explain some of the basics.

Line 8 makes a variable called “fires,” and we’re saying that fires should find every “Fire” in the database (Fire is a class we made in the models.py file, remember?). The .objects.all() part is saying “Find everything and spit it out.” The .order_by(‘date’) is telling it to list everything by date, which is something each Fire contains. Then the [:5] means “Show five.” If you wanted to show 15, it’d be [:15]. Then we tell it on line 9 to bring the information and spit it onto a template called index.html, which we will create later in this post.

Lastly, on line 10 we say that to allow the variable “fires” to be the same as the “fires” we defined on line 8. This means “fires” can be something we will call on the index.html page. Trust me, this will make sense later.

The next page, starting at line 13, is more complicated. This is for each individual fire page. You may notice that we define fire — def fire — and then ask for (request, address, un_id). So the request we can ignore. But the address and un_id are also variables from the urls.py file (this will all make more sense later). Line 14 is similar to line 8, except we’re doing a few extra things.

First, we tell it to get_object_or_404. This means if it doesn’t find anything matching in the database, show the 404.html page. The bits in the parenthesis — (Fire, location__street_slug=address, id=un_id) — is trying to make a match. It’s saying, “Okay, look in the Fire class. See if you can find something that has a location slug that is equal to the ‘address’ part of the url. Also, the Fire’s unique ID has to match the ‘id’ part of the url.”

For instance, the url will look something like /firetracker/fire/2/500-e-10th-street/ — 2 is the unique ID of each fire, and 500-e-10th-street is a web-made version of 500 E. 10th Street. In the admin file we create later, we’ll make something that automatically makes slug files, so don’t worry about this right now.

And then on line 19, we are making the individual person page. Similar as the individual fire page, but we’re matching the name and each person’s unique ID.


Now we gotta edit the urls.py file, which is located in the same directory as your views — /opt/django-projects/firetracker/fires/ — so open that up in your FTP client.

Go to this link and copy and paste the code (this isn’t posting into WordPress correctly, FYI). This is where we are defining our url structure. The index page will show at, for instance (where is the IP address of your AWS instance).

Line 7 has a bit that says firetracker.fires.views.index. That’s telling it “Hey, go to the views file for fires, then find the bit defined as ‘index.’ Use that for this url.” Line 8 and 9 are the more fun bits, as they are the ones that are more interacting with the views. If you see, there’s a un_id and address part in line 8. That’s corresponding to lines 13 and 14 in the views.py file, where it’s trying to make the URL by first finding if that “fire” exists, and then it’s spitting it out.

I’m sucking at explaining this, so, I apologize. But trust me. Shit will work. You will be happy.


Now that we’ve got the views.py and the urls.py made, time for some templates. As you may recall from the views.py, we have three templates: the index, the individual fire page and the individual person page. Using your FTP program, make a new folder called “templates” in your /opt/django-projects/firetracker/fires/ directory.

Inside of that, create three new files. Can you guess what they are based on the views.py?

YOU’RE RIGHT. You rule. They are, indeed, fire_detail.html, index.html and person_detail.html. You’re a fantastic human being, and I’m glad to know you.

Go to each of the following links and then copy and paste them into each of their corresponding files.




Awesome. We now have our views. They’re not the prettiest ever, but they get the basic point across. Next we will configure the server to display this stuff.