This article is part of in the series
Last Updated: Thursday 12th December 2013

In the previous article, we wrote an index view to show a list of posts that are created less than two days ago and a detail view to show the detailed content of a post. In this article, we're going to write a view that allows the user to upload a post and improve our existing index and detail with Django's built-in generic views.

The Upload View

Similar to what we have done in the previous article, in order to write the upload view we need to write an URL pattern in myblog/urls.py first:

The previous URL pattern specifies that myblog.views.post_upload should process any request towards the URL post/upload.html. Now let's write the actual view:

post_upload handles two possible cases. If the request is a GET request, post_upload simply returns a HTML page. If it's a POST request, post_upload() creates a new Post object in the database and returns a HTML page with the new Post object in the context.

Next, we're going to write the template myblog/templates/post/upload.html for our view. This template is going to present an HTML form to the user.

The previous template file uses Django's template language to specify the content of a page. Whenever the template is rendered along with a context by Django, the code between {% and %} is processed by the template renderer and anything outside of the {% %} tags gets returned as normal string. In order to see the actual output of the rendered template, you can inspect its source code in a browser:

<form action="/post/upload.html" method="post" _lpchecked="1">
  <input type="hidden" name="csrfmiddlewaretoken" value="AGGNpA4NcmbuPachX2zrksQXg4PQ7NW0">
  <label for="content"></label>
  <input type="text" name="content" id="content">
  <input type="submit">

Now you can start the server with the python manage.py runserver shell command, and access the URL

Upload a Post

Now you can type the content of the new Post object:

Django Type Content of New Post

And click "submit" that will redirect you to your new post:

Django New Post

Generic Views

So far, we wrote three simple views in our Django application: an index view that shows a list of Posts; a post_detail view that shows a page about the details of a Post object; and a post_upload view that allows a user to upload a Post onto the database. These views represent a common case of web development: getting data from the database, rendering the data using a template and returning the rendered template as a HTTP response back to the user. Since these kinds of views are so common, Django provides a suite of generic views that help reduce the boilerplate code when writing similar views.

First, we will modify the URL configurations in myblog/urls.py:

Notice that post_detail accepts one argument pk which is required by generic.DetailView to fetch the Post object whose primary key is the passed-in argument.

Then, we modify myblog/views.py:

Notice how much more cleaner the code is, compared to the previous version. generic.ListView provides the concept of displaying a list of objects, while generic.DetailView cares about "displaying one specific object". Every generic view needs to know which model it's depending on, so the model attribute is required in every generic view subclass.

Because generic.ListView and generic.DetailView accept sensible defaults such as context_object_name to be used in the template and model to be queried against the database, our code becomes shorter and more straightforward instead of caring too much about boilerplate code such as loading and rendering templates. The generic views are a bunch of Python classes that are meant to sub-classed to suit developers' different needs.

Now you can run the server again to see the exact same output as our previous implementation.

Summary and Suggestions

In this article, we learned how to write a view to handle the POST request, as well as how to use generic views to clean up and improve our views' code quality. Django is a strong proponent of the Don't Repeat Yourself (DRY) principle which enforces that every piece of information should have a single, unambiguous and authoritative representation within a system. In Django's case, it means that there should be only one function, one class or one module in charge of one specific feature. For example, each of the generic views handle only one type of view and encapsulates the functionality essential to that specific type of view, so that the subclasses can re-use the core functionality everywhere. Django's own implementation and API closely follow the DRY principle to minimize duplication and unnecessary boilerplate code. We should also following the same principle and re-use Django's generic views whenever we can. When you face a problem where sub-classing a generic view is not enough, I recommend you to read Django's source code regarding how to implement the generic views and try to write re-usable views instead of mindlessly writing boilerplate code.

About The Author