Django has pagination support built-in. All you need to do is to wrap your QuerySet with django.core.paginator.Paginator and add paginator.page(some_page_number) to your template context. Then you can use attributes/methods such as has_next and num_pages or iterate over page_range to display your pagination navigation. To access items in current page you can use object_list, which is in fact a QuerySet sliced with correct limits. That also means; only those items that you want to display are queried. It’s all documented well as usual.

Django-pagination Takes It One Step Further

In my opinion pagination belongs to presentation. If you have many queries/views to paginate, you might find yourself repetitively writing pagination code. You can move all your pagination code into the template with django-pagination. This is accomplished with a middleware and a set of template tags.

With django-pagination you can paginate your results like this:

{% autopaginate object_list %}

{% for object in object_list %}
  {{ object }}
{% endfor %}

{% paginate %}

autopaginate tag replaces your QuerySet with a paginator and paginate tag renders pagination/pagination.html template with correct values.

You can download django-pagination from Google Code, but appereantly development is moved to GitHub. I wish there was a message left on the Google Code page.

A Little SEO Shouldn’t Hurt

When you have a paginated view, you usually display the results of the first page if the pagination variable is missing. As a result /some_view/ and /some_view/?page=1 return identical responses. This might be interpreted by search engines as a duplicate. My solution for this is to redirect the first page to the page without a page variable:

   1 from django.http import HttpResponsePermanentRedirect
   2 from pagination.middleware import PaginationMiddleware
   3 
   4 class SEOPaginationMiddleware(PaginationMiddleware):
   5     def process_request(self, request):
   6         if request.method == 'GET':
   7             try:
   8                 page = int(request.GET['page'])
   9             except (KeyError, ValueError, TypeError):
  10                 page = None
  11             if page == 1:
  12                 params = request.GET.copy()
  13                 del(params['page'])
  14                 path = request.path
  15                 if params:
  16                     path += '?' + params.urlencode()
  17                 return HttpResponsePermanentRedirect(path)
  18         return super(SEOPaginationMiddleware, self).process_request(request)

This works only if your page variable is an URL parameter (i.e. you are using GET).

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

There is a newer version of this post. Information below is no longer valid!

There is a misconception about how static files (a.k.a media files) are handled in Django. Actually it is quite clearly documented here and here. Nevertheless a question about this comes up in the mailing-list or IRC channel frequently:

Where do I put my media files?

Django can’t find my foo.gif!

How can I link my CSS?

First of all, just to make it clear; just because a server returns a response body with an internal URL doesn’t necessarily mean it will be available on that server. It is one thing that your templates produce the correct URL to a media file and another thing that your server actually serves that resource on that URL. Django development server doesn’t automagically serve media files¹.

Settings

There are three settings to get right: MEDIA_ROOT, MEDIA_URL and ADMIN_MEDIA_PREFIX. MEDIA_ROOT is the absolute filesystem path where your media files are. I usually set it like:

MEDIA_ROOT = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'media')

This will set MEDIA_ROOT to point to the media directory in your project directory². MEDIA_URL and ADMIN_MEDIA_PREFIX are URL’s:

MEDIA_URL = '/media/'
ADMIN_MEDIA_PREFIX = '/media/admin/'

With this setup, to serve admin media in production, all I need to do is to symlink media folder of admin app into my media directory. Of course you can set MEDIA_URL to point to another domain/subdomain. Such as http://media.mydomain.com/. But this way you can’t serve your media from development server.

URL Configuration

Add the following code snipplet at the end of your root urls.py:

   1 if settings.DEBUG:
   2     from django.views.static import serve
   3     _media_url = settings.MEDIA_URL
   4     if _media_url.startswith('/'):
   5         _media_url = _media_url[1:]
   6         urlpatterns += patterns('',
   7                                 (r'^%s(?P<path>.*)$' % _media_url,
   8                                 serve,
   9                                 {'document_root': settings.MEDIA_ROOT}))
  10     del(_media_url, serve)

settings.DEBUG == True doesn’t necessarily mean development server is running. But it is a good indicator since deploying with development server is not a good idea for many reasons. Notice here we don’t serve media unless MEDIA_URL is an absolute URL on our server.

Templates

Finally we need to specify media URL’s correctly. To avoid hard-coding media path we will be using {{ MEDIA_URL }} context variable in our templates. To have {{ MEDIA_URL }} included automatically in each template we need to do two things:

1. Make sure you have django.core.context_processors.media in your TEMPLATE_CONTEXT_PROCESSORS.
2. Make sure each view is using a RequestContext.

Afterwards all we need to do is to specify our media URL’s like this:

<img src="{{ MEDIA_URL }}img/header.jpeg" />

This will be translated to:

<img src="/media/img/header.jpeg" />

Bonus

While we are at it, why not serve our 500 and 404 pages statically. When DEBUG == True, 500 (server error) and 404 (not found) situations are handled with special debugging views. So there’s no chance to test your error pages. Add the following code, just like static serving code:

   1 if settings.DEBUG:
   2     urlpatterns += patterns('',
   3                             (r'^404/',
   4                                 'django.views.generic.simple.' \
   5                                 'direct_to_template',
   6                                 {'template': '404.html'}),
   7                             (r'^500/',
   8                                 'django.views.generic.simple.' \
   9                                 'direct_to_template',
  10                                 {'template': '500.html'}))

Now when you visit /500/ and /404/ on your development server you will be served a fake error page.

1: There is an exception here. If you configured your settings correctly, development server will serve admin media.

2: Assuming your settings.py is directly inside your project directory, hence the __file__.

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

I have done some thinking over this but I am still not sure. If you’re doing both the views and templates yourself then it can be overkill. Just like static typing, or public/private/protected discrimination. On the other hand for design-heavy projects, where there is a seperate template designer who doesn’t know/care much about programming it makes sense. Still the possibility of having adequate presentation logic in templates is a good thing. It shouldn’t hurt anyone.

Last week (jinja dev) Armin Ronacher has posted an article named “Why Jinja is not Django and why Django should have a look at it“. It is a comprehensive comparison of internal workings of both templating engines. Inevitably it is a little biased, but I think each argument is valid and important. If you are into Django, it is a good read. There is also some speed comparison to back it up.

I am currently working on a project using Django. But I don’t touch the templating engine for this one. Everything served as JSON.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 2
3. Working with files in Django – Part 3

If one sticks too rigidly to one’s principles, one would hardly see anybody. (Agatha Christie)

Web applications are thin client (your browser) applications you access through an intranet or the Internet. Due to initial design of WWW, to create rich applications you need to deal with quite a large number of protocols/languages/concepts. To name a few; you need to know about JavaScript, CSS, HTML (preferably XHTML) and (possibly) JSON to write an AJAX application. This is only client side, the front end.

To preserve sanity, a layered approach that divides and isolates different parts of the application as much as possible is usually preferred. MVC pattern, which stands for Model-View-Controller, is a popular method for layering. Model is the layer where your data storage and manipulation occur. View is the layer where the presentation of model occur. The controller layer is basically the glue between both, where your so-called business rules should be. MVC pattern allows us to change the user interaction or to adapt different back ends with minimal modifications.[1]

I would like to summarize how a web application using MVC pattern works. But before that I need to state that this is an overly simplified model I will present.

1. When an HTTP request comes to our server a request object is created. This request object might have come modified according to our configuration before we have access to it. For example we might have wanted our request body to be decoded to unicode.
2. The request object is passed to a view function, depending on our configuration again. URL patterns might be matched against view functions or, rarely, against HTTP method (GET, POST, etc) or an entirely different method can be used to determine which view function to call.
3. The view function communicates with the model, adds, deletes or modifies the models as needed. Or it might just pull some data out and present it to user.
4. We can generate the response from our view but, it is preferred to use another template layer. Because that way you can seperate application logic and presentation logic. In that case the view function returns the necessary information into a template object.
5. The template object receives the data from the view and renders the final response (an HTML page, an XML document, etc).

We can pass data from view to template in a number of ways. We can use dictionaries (hashmaps) with arbitrary objects as values for example. When we return this dictionary from our view function the template objects picks it up and makes the data available by reference to its keys.

What we pass depends on the presentation logic in the template. Just to give you an idea, say we have a query page, where the user simply asks for a particular piece of data and we present it;

• It will surely need a reference to that data. (Maybe a model instance if you are using an ORM)
• It may present data conditionally, some parts might be available only to the administrators and invisible to normal users for example. So we would need to pass something to determine these conditions. I’ll come back to that something later.
• It may have other elements (on the page) that need references to other data. (There might me a dynamically generated menu on certain pages for instance)

This means we would pass three kinds of references to a template; primary data, conditinal information and secondary data. I have mentioned that when we have templates we can seperate application logic (business rules?) and presentation logic. In (beautiful) web framework Django‘s documentation it is said;

…the template system is meant to express presentation, not program logic.

and

We see a template system as a tool that controls presentation and presentation-related logic — and that’s it. The template system shouldn’t support functionality that goes beyond this basic goal.

If we wanted to put everything in templates, we’d be using PHP. Been there, done that, wised up.

I read presentation as laying out output and program logic as inserting/querying/modifying/deleting. This takes us back to the something I would like to discuss. How do we pass information related to conditional rendering. What we pass depends greatly on the functionality of the template engine. Let me illustrate with an example;

We want to display a tip if;

• A user who is registered for at least 2 weeks ago.
• Who has less than 5 friends.
• No other warning, such as a form validation error, is present on the page.

My intuition tells me I would need a reference to the list of errors and the (authenticated) user object in my template. I would like to have a reference to my user object because if I get anything less I might have to modify the view if the requirements change. So the registration date with the friend count would not do. After all we are deciding whether or not to show a tip, we are not doing inserting/querying/modifying/deleting I mentioned earlier.

Suppose we have user and error passed into our template, how do we use them; [2]

{% if user.registered.today().toordinal()
    -user.registered.toordinal() >= 14
    and user.friends.count < 5
    and not errors %}
    <div class="tip"> ... </div>
{% endif %}

Of course this does not work in Django. Django template engine’s if doesn’t have greater-than-or-equal operator, less-than operator and can not combine with truth testing (Instead has a seperate ifequal statement for truth testing). There are two workarounds;

1. We calculate conditions at the view and pass them as simple boolean values.

   {% if user_registered_for_at_least_two_weeks
       and user_has_less_than_five_friends
       and no_errors %}
       <div class="tip"> ... </div>
   {% endif %}
   

2. We pass user reference and add checking functions to the models.

   {% if user.registeredAtLeastTwoWeeksAgo
       and user.hasLessThan5Friends %}
       {% ifequal errors None %}
           <div class="tip"> ... </div>
       {% endif %}
   {% endif %}
   

The first one is actually not a solution, since we calculate the conditions in the view the presentation code is spanning both layers. The second workaround allows us to decouple the template and the view but adding more and more functions on models for such simple operations is just displacing the problem.

As far as I understand Django template engine has very simple control flow functionality for a reason. To ensure logic stays in the view; limit functionality in the template (to truth testing and equality testing only). But eventually you want a somewhat complex template and either the view or the model gets cluttered.

The first sample, the one with the complex if, is jinja code. It’s conditional staments are almost as powerful as Python. This allows bad programming of course. You can do almost everything you are supposed to do in the view. But you if you follow decoupling principle you can have your code working, clean and maintanable.

I think Django is a special project (as an open source project, like Blender, like Inkscape in this sense). If we look carefully there are many lessons to be learned. Both in the API level and in the source code itself. I try to learn as much as possible from Django. But on my personal projects I would like to take full advantage of the expressive power of jinja (and sqlalchemy similarly). I try to assemble best components available, but I also do my best to follow best practises (learned from Django or other sources).

If you are considering Python for web development, I would say learn Django first. And then go ahead and study other frameworks and libraries. Python is extremely powerful and suits web development well. Once you found the setup (framework or whatever) that works best for you, I am sure you will enjoy it.

1: There are different interpretations of MVC model. What happens in each layer might slightly change depending on the application type and of course implementors.

2: I know these line breaks look stupid. But it blows the page away otherwise.

Related posts:

1. I Am Discontinuing Telvee
2. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
3. Working with files in Django – Part 1