Django Views and URLconfs – Your First Django page

This mini tutorial explains how to serve a simple web page through Django that display’s a traditional ‘Hello world’ message.

The examples on this page assume that you have completed the Django installation, and have started a new Django project in a directory named /mysite/.

Key concepts

In Django, the contents of the page are produced by view a function, which you place in a file you create, conventionally named views.py. The URL of the page itself is specified in a URLconf,, which you specify in urls.py.

Sample view

To output a simple Hello world! message, add this to your new views.py:

from django.http import HttpResponsedef hello(request):     return HttpResponse("Hello world")

Translation:

  • Import the HttpResponse class, from django/http/ (or, the django.http module)
  • Define a function called hello. This is our view function.
  • Return an HttpResponse object that’s been instantiated with the text Hello world.

In order for a Python function to be a Django view, it must do two things:

  1. Takes an HttpRequest as its first parameter.
  2. Return an instance of HttpResponse.

Each view function takes at least one parameter, called request by convention.

Sample URLconf

Default URLconf:

If we ignore the code that’s commented out of the urls.py file (the one that was created when you first created your Django testProject folder), we’re left simply with:

from django.conf.urls.defaults import *urlpatterns = patterns('',)

Translation:

  • Import all objects from the django/conf/urls/defaults/ (the django.conf.urls.defaults module). This includes the proceeding function, patterns.
  • Calls the function patterns and save the result into a variable called urlpatterns.

Edit the URLconf:

from django.conf.urls.defaults import *from mysite.views import hellourlpatterns = patterns('',    ('^hello/$', hello),)

Translation:

  • Import the hello view from the mysite.views.py module.
  • Any request to the URL /hello/ should be handled by the hello view function.

Things to remember

  • mysite/views.py must be on your Python path.
  • If you want to load this page from Apache as http://127.0.0.1/hello instead of as http://127.0.0.1:8000/hello from Django’s development server, make sure that the following is in Apache’s configuration file (httpd.conf):

    <Directory C:/mysite>
    Order deny,allow
    Allow from all </Directory>
  • The URLpattern ('^hello/$', hello), is a Python tuple in which the first element is a regular expression, and the second is the view function to use for that pattern.

Test your first Django page

Either run the command python manage.py runserver to view your /hello/ page in Django’s development server at http://127.0.0.1:8000/hello, or view it with your Apache web server at http://127.0.0.1/hello .

The page you see from this example is static; the content doesn’t change from user input, nor does it involve any database. Move on to a simple example of a dynamic Django page—as well as to an introduction to dynamic URLs—in Chapter 3 of DjangoBook: Views and URLconfs.

10 Improvements Posterous Needs To Make

Note: This post is no longer relevant, as Posterous was shut down April 30, 2013, after much of the team was acquired by Twitter on March 12, 2012.

I’m quickly realizing that while Posterous is said to be a fast and easy solution for making blog posts from your email when you’re on the go, it’s lacking some fundamental features I’d expect from any serious blogging platform.

This list will grow (hopefully not much more) as I make new preposterous discoveries.

  1. Give us our alt attributes: Alt attribute text is non-existant and can’t be added. Accessibility issue.
  2. Let us control our image file names: Image file names are changed to horrendously long random strings when you upload using the media uploader, and they can’t be modified. Accessibility issue.
  3. Let publishers decide what (and what not) to syndicate: All posts are given canonical attributes, and you can’t undo this “feature”. Ethics issue.
  4. Let us preview our posts: Posts can’t be previewed—only updated—which automatically takes you out of the editor and displays the published page in its place. Usability issue.
  5. Let us save posts quickly: Posts can’t be saved without being updated, which takes you out of the editor (see previous complaint). Usability issue.
  6. Watch our back. Just a bit: There is no autosave feature. Usability issue.
  7. Let us edit our comments: Comments can’t be edited, only deleted and re-posted in the case of typos or other errors. Usability issue.
  8. Let us reply to specific comments: Admins can’t reply to specific user comments. Usability issue.
  9. Let us name anchors: Posterous automatically strips id or name attributes from most HTML elements, which prevents you from linking to specifics section of your pages. Usability issue. The workaround: Add an empty anchor with a name attribute just before the section you want to name, e.g., <a name="anchor_name"></a>. Thanks to Luke Sampson for this useful little hack.
  10. Fix your HTML rendering issues: Just one example of straightforward HTML that doesn’t render properly in Posterous, although it renders properly in their “rich text editor”. em>Usability, accessibility issue. I’ve included a screencast due to the inability to properly markup the code in Posterous.

    Click on the icon next to the Screenr Logo (bottom right of the player) to see the video at a decent size
    :Since moving this blog from Posterous to WordPress, the Screenr widget is no longer embedded, since WordPress.com doesn;t allow iframes. Here’s the link to the video instead: http://www.screenr.com/qywIn item 9 of this list, I left the last &gt; (>) symbol outside of the <code> element, immediately after the closing </code> tag. Another ugly hack, but I’m getting used to the fact that to makes things work in posterous, you often have to get ugly.