Django for the Impatient: The Finishing Touches
By Jeff Forcier, Paul Bissex and Wesley Chun
[This is the second part of a two-part series. The previous installment covered the basics of building the blog. In this installment, we'll put the finishing touches on it.]
Making Your Blog's Public Side
With the database and admin side of our application taken care of, it's time to turn to the public-facing pages. A page, from Django's perspective,has three typical components:
- A template that displays information passed to it (in a Python-dictionary-like object called a Context)
- A view function that fetches information to be displayed, typically from a database
- A URL pattern that matches an incoming request with your view function, optionally passing parameters to the view as well
We'll tackle these three in that order. In a sense this is building from the inside out— when Django processes a request, it starts with the URL patterns, then calls the view, and then returns the data rendered into a template.
Creating a Template
Django's template language is easy enough to read that we can jump right in to example code. This is a simple template for displaying a single blog post:
It's just HTML (though Django templates can be used for any kind of textual output) plus special template tags in curly braces. These are variable tags, which display data passed to the template. Inside a variable tag, you can use Python-style dot-notation to access attributes of the objects you pass to your template. For example, this template assumes you have passed it a BlogPost object called "post."The three lines of the template fetch the BlogPost object's title, timestamp, and body fields, respectively.
Let's enhance the template a bit so it can be used to display multiple blog posts, using Django's for template tag.
The original three lines are unchanged; we've simply added a block tag called for that renders a template section once for each of a sequence of items. The syntax is deliberately similar to Python's loop syntax. Note that unlike variable tags, block tags are enclosed in {% ... %} pairs.
Save this simple five-line template in a file called archive.html, and put that file in a directory called templates inside your blog app directory. That is, the path to your template file should be:
The name of the template itself is arbitrary (we could have called it foo.html), but the templates directory name is mandatory. By default, when searching for templates, Django looks for a templates directory inside each of your installed applications.
Creating a View Function
Now we'll write a simple view function that fetches all our blog posts from the database and displays them using our template. Open up the blog/views.py file and type the following:
Skipping over the import lines for the moment (they just load up the function and classes we need), here's the breakdown of the view function, line by line:
- Line 5: Every Django view function takes a
django.http.HttpRequestobject as its first argument. It can also take other arguments that get passed in via the URLconf, which is a feature you are using a lot. - Line 6: When we created our
BlogPostclass as a subclass ofdjango.db.models.Model, we inherited the full power of Django's object-relational mapper. This line is a simple example of using the ORM (Object-Relational Mapper; see Chapters 3, "Starting Out," and 4 for more) to get all theBlogPostobjects in the database. *Line 7: To create our template objectt, we only need to tell Django the name of the template. Because we've stored it in the templates directory of our app, Django can find it without further instruction. *Line 8: Django templates render data that is provided to them in a context, a dictionary-like object. Our context c has only a single key and value. *Line 9: Every Django view function returns adjango.http.HttpResponse object. In the simplest case, we pass the constructor a string. The template render method returns a string, conveniently.
Creating a URL Pattern
Only one more piece is needed for our page to work—like anything else on the Web, it needs a URL.
We could create the needed URL pattern directly inside mysite/urls.py, but that creates a messy coupling between our project and our app.We can use our blog app somewhere else, so it would be nice if it were responsible for its own URLs. We do this in two simple steps.
The first step is much like enabling the admin. In mysite/urls.py, there's a commented example line that is almost what we need. Edit it so it looks like this:
This catches any requests that begin with blog/ and passes them to a new URLconf you're about to create.
The second step is to define URLs inside the blog application package itself. Make a new file, mysite/blog/urls.py, containing these lines:
It looks a lot like our base URLconf. The action happens in line 5. First, note the blog/ part of the request URL, which our root URLconf was matching, is stripped—our blog application is reusable and shouldn't care if it's mounted at blog/ or news/ or what/i/had/for/lunch/. The regular expression in line 5 matches a bare URL, such as /blog/.
The view function, archive, is provided in the second part of the pattern tuple. (Note we're not passing a string that names the function, but an actual first-class function object. Strings can be used as well, as you see later.)
Let's see it in action! Is the dev server still running? If not, fire it up with manage.py runserver, and then go to http://127.0.0.1:8000/blog/ in your browser. You should see a simple, bare-bones rendering of any blog posts you have entered, complete with title, timestamp, and post body.
