Winnipeg Web Design

This imports the settings configuration and if it’s in DEBUG mode, adds the static serve content to the url patterns. You should change rsrc to whatever you specified as your MEDIA_URL excluding the prefixed slash. Everything else should be mostly explanatory (path named capture grabs everything else in the incoming url).

Listing page

Now we’re going to implement templates that generic views use. In the generic views defined by urls.py look for template in certain locations by default (you can customize this behavior with the template_name parameter). But by default, it looks for the template in <app_name>/<model_name>_list.html for object_list and <app_name>/<model_name>_detail.html for object_detail. So for our particular application, we need templates for posts/post_list.html and posts/post_detail.html. Since I planned the actual html for a particular post to be the same, we’ll be using the include tag to include another extra html file located at posts/_post.html.

First, post_list.html:

{% extends ‘base.html’ %}
{% block content %}
{% for object in object_list %}
    <hr/>
    {% include ‘posts/_post.html’ %}
{% endfor %}
{% endblock %}

Pretty simple here. We tell Django that we’re extending base.html which inherits all the contents from that file. We’ll override the  content block and loop through all the posts adding a horizontal rule before including the _post.html file which will display the data of the post. If you haven’t noticed, all template paths are relative to the base template directory (so we need to specify ‘posts’).

You may wonder where in the world we got the object_list variable. object_list is provided by the object_list generic view as stated by Django’s documentation, which contains a list of our posts. So in python fashion, we iterate over all the posts, and generate the html block for each object. _post.html will inherit all variables accessible in the template it was included in as if its contents were inserted into this template. We keep the post name as object as oppose to something like post since object_detail generic view uses the object variable to represent the single post that was fetched. Using the same variable allows use to reuse the include.

Detail page

Our posts/post_detail.html is even simpler:

{% extends ‘base.html’ %}
{% block content %}
{% include ‘posts/_post.html’ %}
{% endblock %}

Nothing new to explain. But we have to also implement our _post.html template so lets create that now:

<div id=”object_{{ object.id }}”>
<h2>
    <a href=”{% url post object.id %}”>{{ object.title }}</a>
    <small>{{ object.pub_date|timesince }} ago</small>
    </h2>
    {{ object.body }}
</div>

The object variable represents a post model that we’re interacting with. So object.id, object.title, object.body are all post model fields we specified, although they could be fields, a function call (with no parameters) can be referenced the same way.

Here we’ve used the url template tag. This returns a url based on the url pattern name (see urls.py in posts app) and a set of parameter values separated by commas. The parameter values can specify the keyword name such as object_id=object.id, but that just makes it more verbose especially for one parameter.

Likewise we can add a link to return the user to all the posts. In post_detail.html add:

<a href=”{% url posts %}”>Back to posts</a>

Since the posts url pattern doesn’t require any parameters, we can leave that portion blank.

In this template, we also utilized a template filter, timesince, to transform the datetime field into a relative time from today. Template filters are only used in variable outputs (which are inside {{ }}) to modify the output in some fashion. Filters are functions that accept the variable from the left of itself and are stackable. So we can also do: {{ object.pub_date|timesince|upper }} to make the outputted timesince text display all in uppercase.

Part IV will most likely be published on Monday so subscribe to our RSS Feed

Written by Brenley Dueck