Download to read offline
![Chapter 1: Introduction to Django
behavior to objects at runtime.
Beyond the productivity advantages inherent in Python, Django itself makes every effort to encourage rapid development. Every
part of the framework was designed with productivity in mind. We’ll see examples throughout this book.
…
and clean, pragmatic design
Finally, Django strictly maintains a clean design throughout its own code and makes it easy to follow best Web-development
practices in the applications you create.
That means, if you think of Django as a car, it would be an elegant sports car, capable not only of high speeds and sharp turns,
but delivering excellent mileage and clean emissions.
The philosophy here is: Django makes it easy to do things the “right” way.
Specifically, Django encourages loose coupling: the programming philosophy that different pieces of the application should be
interchangeable and should communicate with each other via clear, concise APIs.
For example, the template system knows nothing about the database-access system, which knows nothing about the HTTP
request/ response layer, which knows nothing about caching. Each one of these layers is distinct and loosely coupled to the rest.
In practice, this means you can mix and match the layers if need be.
Django follows the “model-view-controller” (MVC) architecture. Simply put, this is a way of developing software so that the code
for defining and accessing data (the model) is separate from the business logic (the controller), which in turn is separate from the
user interface (the view).
MVC is best explained by an example of what not to do. For instance, look at the following PHP code, which retrieves a list of
people from a MySQL database and outputs the list in a simple HTML page. (Yes, we realize it’s possible for disciplined
programmers to write clean PHP code; we’re simply using PHP to illustrate a point.):
<html>
<head><title>Friends of mine</title></head>
<body>
<h1>Friends of mine</h1>
<ul>
<?php
$connection = @mysql_connect("localhost", "my_username", "my_pass");
mysql_select_db("my_database");
$people = mysql_query("SELECT name, age FROM friends");
while ( $person = mysql_fetch_array($people, MYSQL_ASSOC) ) {
?>
<li>
<?php echo $person['name'] ?> is <?php echo $person['age'] ?> years old.
</li>
<?php } ?>
</ul>
</body>
</html>
While this code is conceptually simple for beginners — because everything is in a single file — it’s bad practice for several reasons:
1. The presentation is tied to the code. If a designer wanted to edit the HTML of this page, he or she would have to edit this
code, because the HTML and PHP core are intertwined.
By contrast, the Django/ MVC approach encourages separation of code and presentation, so that presentation is governed by
templates and business logic lives in Python modules. Programmers deal with code, and designers deal with HTML.
2. The database code is tied to the business logic. This is a problem of redundancy: If you rename your database tables or
columns, you’ll have to rewrite your SQL.
By contrast, the Django/ MVC approach encourages a single, abstracted data-access layer that’s responsible for all data
access. In Django’s case, the data-access layer knows your database table and column names and lets you execute SQL
queries via Python instead of writing SQL manually. This means, if database table names change, you can change it in a
single place — your data-model definition — instead of in each SQL statement littered throughout your code.
3. The URL is coupled to the code. If this PHP file lives at /foo/index.php, it’ll be executed for all requests to that address.
But what if you want this same code to execute for requests to /bar/ and /baz/? You’d have to set up some sort of includes
or rewrite rules, and those get unmanageable quickly.
file:///C|/Documents and Settings/Suren/Desktop/Chapter 1 Introduction to Django.htm (2 of 4)9/28/2007 4:13:54 PM](https://image.slidesharecdn.com/0506-django-web-framework-for-python-220826170142-795f0a87/85/0506-django-web-framework-for-python-pdf-5-320.jpg)
![The Dj ango Book
« previous ◊ table of contents ◊ next »
Chapter 2: Getting started
Let’s get started, shall we?
Fortunately, installing Django is easy. Because Django runs anywhere Python does, Django can be configured in many ways.
We’ve tried to cover the common scenarios for Django installations in this chapter.
Installing Python
Django is written in 100% pure Python code, so you’ll need to install Python on your system. Django requires Python 2.3 or
higher.
If you’re on Linux or Mac OS X, you probably already have Python installed. Type python at a command prompt (or in Terminal,
in OS X). If you see something like this, then Python is installed:
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Otherwise, if you see an error such as "command not found", you’ll have to download and install Python. See http: / / www.python.
org/ download/ to get started. The installation is fast and easy.
Installing Dj ango
Installing an official release
Most people will want to install the latest official release from http: / / www.djangoproject.com/ download/ . Django uses the
standard Python distutils installation method, which in Linux land looks like:
1. Download the tarball, which will be named something like Django-1.0.tar.gz.
2. tar xzvf Django-*.tar.gz
3. cd Django-*
4. sudo python setup.py install
If everything worked, you should be able to import the module django from the Python interactive interpreter.
>>> import django
>>> django.VERSION
(1, 0, ‘official’)
The Python interactive interpreter:
The Python interactive interpreter is a command-line program that lets you write a Python program interactively. To
start it, just run the command python at the command line. Throughout this book, we’ll feature example Python
code that’s printed as if it’s being entered in the interactive interpreter. The triple greater-than signs (“> > > ”)
signify a prompt.
Installing Django from Subversion
If you want to work on the bleeding edge, or if you want to contribute code to Django itself, you should install Django from its
Subversion repository.
Subversion is a free, open-source revision-control system similar to CVS, and the Django team uses it to manage changes to the
Django codebase. At any given time, you can use a Subversion client to grab the very latest Django source code, and, at any
given time, you can update your local version of the Django code — known as your “local checkout” — to get the latest changes
and improvements made by Django developers.
The latest-and-greatest Django development code is referred to as “the trunk.”
Chapter 2: Getting started
file:///C|/Documents and Settings/Suren/Desktop/DJANGO/CH2.html (1 of 4)9/28/2007 2:07:18 PM](https://image.slidesharecdn.com/0506-django-web-framework-for-python-220826170142-795f0a87/85/0506-django-web-framework-for-python-pdf-8-320.jpg)
![Chapter 3: The basics of generating Web pages
requirement — no “magic,” so to speak. For the sake of putting it somewhere, let’s create a file called views.py, copy this view
code into that file and save it into the mysite directory you created in the previous chapter.
Your Python path
The Python path is the list of directories on your system where Python looks when you use the Python import
statement.
For example, let’s say your Python path is set to ['', '/usr/lib/python2.4/site-packages', '/home/mycode'].
If you execute the Python code from foo import bar, Python will first check for a module called foo.py in the
current directory. (The first entry in the Python path, an empty string, means “the current directory.”) If that file
doesn’t exist, Python will look for the file /usr/lib/python2.4/site-packages/foo.py. If that file doesn’t exist, it
will try /home/mycode/foo.py. Finally, if that file doesn’t exist, it will raise ImportError.
If you’re interested in seeing the value of your Python path, start the Python interactive interpreter and
type import sys, followed by print sys.path.
Generally you don’t have to worry about setting your Python path — Python and Django will take care of things for
you automatically behind the scenes. (If you’re curious, setting the Python path is one of the things that
the manage.py file does.)
How do we tell Django to use this view code? That’s where URLconfs come in.
A URLconf is like a table of contents for your Django-powered Web site. Basically, it’s a mapping between URL patterns and the
view functions that should be called for those URL patterns. It’s how you tell Django “For this URL, call this code, and for that
URL, call that code.”
When you executed django-admin.py startproject in the previous chapter, the script created a URLconf for you automatically:
the file urls.py. Let’s edit that file. By default, it looks something like this:
from django.conf.urls.defaults import *
urlpatterns = patterns('',
# Example:
# (r'^mysite/', include('mysite.apps.foo.urls.foo')),
# Uncomment this for admin:
# (r'^admin/', include('django.contrib.admin.urls')),
)
Let’s step through this code one line at a time:
● The first line imports all objects from the django.conf.urls.defaults module, including a function called patterns.
● The second line calls the function patterns() and saves the result into a variable called urlpatterns. The patterns()
function gets passed only a single argument — the empty string. The rest of the lines are commented out.
The main thing to see here is the variable urlpatterns. This defines the mapping between URLs and the code that handles those
URLs.
By default, everything in the URLconf is commented out — your Django application is a blank slate. (As a side note, that’s how
Django knew to show you the “It worked!” page in the last chapter: If your URLconf is empty, Django assumes you just started a
new project and, hence, displays that message.)
Let’s edit this file to expose our current_datetime view:
from django.conf.urls.defaults import *
from mysite.views import current_datetime
urlpatterns = patterns('',
(r'^now/$', current_datetime),
)
We made two changes here. First, we imported the current_datetime view from its module (mysite/views.py, which translates
into mysite.views in Python import syntax). Next, we added the line (r'^now/$', current_datetime),. This line is referred to
as a URLpattern — it’s a Python tuple in which the first element is a simple regular expression and the second element is the
view function to use for that pattern.
In a nutshell, we just told Django that any request to the URL /now/ should be handled by the current_datetime view function.
A few things are worth pointing out:
● Note that, in this example, we passed the current_datetime view function as an object without calling the function. This is
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH3.html (2 of 9)9/28/2007 2:08:35 PM](https://image.slidesharecdn.com/0506-django-web-framework-for-python-220826170142-795f0a87/85/0506-django-web-framework-for-python-pdf-13-320.jpg)
![Chapter 3: The basics of generating Web pages
Regular expressions
Regular expressions (or “regexes”) are a compact way of specifying patterns in text. While Django URLconfs allow
arbitrary regexes for powerful URL-matching capability, you’ll probably only use a few regex patterns in practice.
Here’s a small selection of common patterns:
Sym bol Matches
. (dot) Any character
d Any digit
[A-Z] Any character from A-Z (uppercase)
[a-z] Any character from a-z (lowercase)
[A-Za-z] Any character from a-z (case-insensitive)
[^/]+ All characters until a forward slash (excluding the slash itself)
+ One or more of the previous character (e.g., d+ matches one or more digit)
? Zero or more of the previous character (e.g., d* matches zero or more digits)
{1,3} Between one and three (inclusive) of the previous character
For more on regular expressions, see Appendix XXX, Regular Expressions.
Now that we’ve designated a wildcard for the URL, we need a way of passing that data to the view function, so that we can use a
single view function for any arbitrary hour offset. We do this by placing parentheses around the data in the URLpattern that we
want to save. In the case of our example, we want to save whatever number was entered in the URL — so let’s put parentheses
around the d{1,2}:
(r'^now/plus(d{1,2})hours/$', hours_ahead),
If you’re familiar with regular expressions, you’ll be right at home here; we’re using parentheses to capture data from the
matched text.
The final URLconf, including our previous current_datetime view, looks like this:
from django.conf.urls.defaults import *
from mysite.views import current_datetime, hours_ahead
urlpatterns = patterns('',
(r'^now/$', current_datetime),
(r'^now/plus(d{1,2})hours/$', hours_ahead),
)
With that taken care of, let’s write the hours_ahead view.
..admonition: : Coding order
In this case, we wrote the URLpattern first and the view second, but in the previous example, we wrote the view
first, then the URLpattern. Which technique is better?
Well, every developer is different.
If you’ re a big-picture type of person, it may make most sense to you to write all of the URLpatterns for your
application at the same time, at the start of your proj ect, then coding up the views. This has the advantage of
giving you a clear to-do list, and it essentially defines the parameter requirements for the view functions you’ ll
need to write.
If you’ re more of a bottom-up developer, you might prefer to write the views first, then anchor them to URLs
afterward. That’ s OK, too.
In the end, it comes down to what fits your brain the best. Either approach is valid.
hours_ahead is very similar to the current_datetime view we wrote earlier, with a key difference: it takes an extra argument,
the number of hours of offset. Here it is:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH3.html (5 of 9)9/28/2007 2:08:35 PM](https://image.slidesharecdn.com/0506-django-web-framework-for-python-220826170142-795f0a87/85/0506-django-web-framework-for-python-pdf-16-320.jpg)
![Chapter 3: The basics of generating Web pages
For bonus points, be a perfectionist: allow /now/plus1hour/ and /now/plus2hours/ but disallow /now/plus1hours/
and /now/plus2hour/.
4. Similarly, we were lazy in the HTML display, saying "In %s hour(s), it will be %s." Fix this to remove the hour(s).
The (s) was such a cop-out! If the offset is singular, use 'hour'; otherwise, use 'hours'.
Answers to exercises
1. Here’s one implementation of the hours_behind view:
def hours_behind(request, offset):
offset = int(offset)
dt = datetime.datetime.now() - datetime.timedelta(hours=offset)
html = "<html><body>%s hour(s) ago, it was %s.</body></html>" % (offset, dt)
return HttpResponse(html)
Not much is different between this view and hours_ahead — only the calculation of dt and the text within the HTML.
The URLpattern would look like this:
(r'^now/minus(d{1,2})hours/$', hours_behind),
2. Here’s one implementation of the hour_offset view:
def hour_offset(request, plus_or_minus, offset):
offset = int(offset)
if plus_or_minus == 'plus':
dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
html = 'In %s hour(s), it will be %s.' % (offset, dt)
else:
dt = datetime.datetime.now() - datetime.timedelta(hours=offset)
html = '%s hour(s) ago, it was %s.' % (offset, dt)
html = '<html><body>%s</body></html>' % html
return HttpResponse(html)
The URLpattern would look like this:
(r'^now/(plus|minus)(d{1,2})hours/$', hour_offset),
In this implementation, we capture two values from the URL — the offset, as we did before, but also the string that
designates whether the offset should be positive or negative. They’re passed to the view function in the order in which
they’re captured.
Inside the view code, the variable plus_or_minus will be either the string 'plus' or the string 'minus'. We test that to
determine how to calculate the offset — either by adding or subtracting a datetime.timedelta.
If you’re particularly anal, you may find it inelegant that the view code is “aware” of the URL, having to test for the
string 'plus' or 'minus' rather than some other variable that has been abstracted from the URL. There’s no way around
that; Django does not include any sort of “middleman” layer that converts captured URL parameters to abstracted data
structures, for simplicity’s sake.
3. To accomplish this, we wouldn’t have to change the hour_offset view at all. We’d just need to edit the URLconf slightly.
Here’s one way to do it, by using two URLpatterns:
(r'^now/(plus|minus)(1)hour/$', hour_offset),
(r'^now/(plus|minus)([2-9]|dd)hours/$', hour_offset),
More than one URLpattern can point to the same view; Django processes the patterns in order and doesn’t care how many
times a certain view is referenced. In this case, the first pattern matches the URLs /now/plus1hour/ and /now/minus1hour/
. The (1) is a neat little trick — it passes the value '1' as the captured value, without allowing any sort of wildcard.
The second pattern is more complex, as it uses a slightly tricky regular expression. The key part is ([2-9]|dd). The pipe
character ('|') means “or,” so the pattern in full means “match either the pattern [2-9] or dd.” In other words, that
matches any one-digit number from 2 through 9, or any two-digit number.
4. Here’s a basic way of accomplishing this. Alter the hour_offset function like so:
def hour_offset(request, plus_or_minus, offset):
offset = int(offset)
if offset == 1:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH3.html (8 of 9)9/28/2007 2:08:35 PM](https://image.slidesharecdn.com/0506-django-web-framework-for-python-220826170142-795f0a87/85/0506-django-web-framework-for-python-pdf-19-320.jpg)
![Chapter 1: Introduction to Django
behavior to objects at runtime.
Beyond the productivity advantages inherent in Python, Django itself makes every effort to encourage rapid development. Every
part of the framework was designed with productivity in mind. We’ll see examples throughout this book.
…
and clean, pragmatic design
Finally, Django strictly maintains a clean design throughout its own code and makes it easy to follow best Web-development
practices in the applications you create.
That means, if you think of Django as a car, it would be an elegant sports car, capable not only of high speeds and sharp turns,
but delivering excellent mileage and clean emissions.
The philosophy here is: Django makes it easy to do things the “right” way.
Specifically, Django encourages loose coupling: the programming philosophy that different pieces of the application should be
interchangeable and should communicate with each other via clear, concise APIs.
For example, the template system knows nothing about the database-access system, which knows nothing about the HTTP
request/ response layer, which knows nothing about caching. Each one of these layers is distinct and loosely coupled to the rest.
In practice, this means you can mix and match the layers if need be.
Django follows the “model-view-controller” (MVC) architecture. Simply put, this is a way of developing software so that the code
for defining and accessing data (the model) is separate from the business logic (the controller), which in turn is separate from the
user interface (the view).
MVC is best explained by an example of what not to do. For instance, look at the following PHP code, which retrieves a list of
people from a MySQL database and outputs the list in a simple HTML page. (Yes, we realize it’s possible for disciplined
programmers to write clean PHP code; we’re simply using PHP to illustrate a point.):
<html>
<head><title>Friends of mine</title></head>
<body>
<h1>Friends of mine</h1>
<ul>
<?php
$connection = @mysql_connect("localhost", "my_username", "my_pass");
mysql_select_db("my_database");
$people = mysql_query("SELECT name, age FROM friends");
while ( $person = mysql_fetch_array($people, MYSQL_ASSOC) ) {
?>
<li>
<?php echo $person['name'] ?> is <?php echo $person['age'] ?> years old.
</li>
<?php } ?>
</ul>
</body>
</html>
While this code is conceptually simple for beginners — because everything is in a single file — it’s bad practice for several reasons:
1. The presentation is tied to the code. If a designer wanted to edit the HTML of this page, he or she would have to edit this
code, because the HTML and PHP core are intertwined.
By contrast, the Django/ MVC approach encourages separation of code and presentation, so that presentation is governed by
templates and business logic lives in Python modules. Programmers deal with code, and designers deal with HTML.
2. The database code is tied to the business logic. This is a problem of redundancy: If you rename your database tables or
columns, you’ll have to rewrite your SQL.
By contrast, the Django/ MVC approach encourages a single, abstracted data-access layer that’s responsible for all data
access. In Django’s case, the data-access layer knows your database table and column names and lets you execute SQL
queries via Python instead of writing SQL manually. This means, if database table names change, you can change it in a
single place — your data-model definition — instead of in each SQL statement littered throughout your code.
3. The URL is coupled to the code. If this PHP file lives at /foo/index.php, it’ll be executed for all requests to that address.
But what if you want this same code to execute for requests to /bar/ and /baz/? You’d have to set up some sort of includes
or rewrite rules, and those get unmanageable quickly.
file:///C|/Documents and Settings/Suren/Desktop/Chapter 1 Introduction to Django.htm (2 of 4)9/28/2007 4:13:54 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-5-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![The Dj ango Book
« previous ◊ table of contents ◊ next »
Chapter 2: Getting started
Let’s get started, shall we?
Fortunately, installing Django is easy. Because Django runs anywhere Python does, Django can be configured in many ways.
We’ve tried to cover the common scenarios for Django installations in this chapter.
Installing Python
Django is written in 100% pure Python code, so you’ll need to install Python on your system. Django requires Python 2.3 or
higher.
If you’re on Linux or Mac OS X, you probably already have Python installed. Type python at a command prompt (or in Terminal,
in OS X). If you see something like this, then Python is installed:
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Otherwise, if you see an error such as "command not found", you’ll have to download and install Python. See http: / / www.python.
org/ download/ to get started. The installation is fast and easy.
Installing Dj ango
Installing an official release
Most people will want to install the latest official release from http: / / www.djangoproject.com/ download/ . Django uses the
standard Python distutils installation method, which in Linux land looks like:
1. Download the tarball, which will be named something like Django-1.0.tar.gz.
2. tar xzvf Django-*.tar.gz
3. cd Django-*
4. sudo python setup.py install
If everything worked, you should be able to import the module django from the Python interactive interpreter.
>>> import django
>>> django.VERSION
(1, 0, ‘official’)
The Python interactive interpreter:
The Python interactive interpreter is a command-line program that lets you write a Python program interactively. To
start it, just run the command python at the command line. Throughout this book, we’ll feature example Python
code that’s printed as if it’s being entered in the interactive interpreter. The triple greater-than signs (“> > > ”)
signify a prompt.
Installing Django from Subversion
If you want to work on the bleeding edge, or if you want to contribute code to Django itself, you should install Django from its
Subversion repository.
Subversion is a free, open-source revision-control system similar to CVS, and the Django team uses it to manage changes to the
Django codebase. At any given time, you can use a Subversion client to grab the very latest Django source code, and, at any
given time, you can update your local version of the Django code — known as your “local checkout” — to get the latest changes
and improvements made by Django developers.
The latest-and-greatest Django development code is referred to as “the trunk.”
Chapter 2: Getting started
file:///C|/Documents and Settings/Suren/Desktop/DJANGO/CH2.html (1 of 4)9/28/2007 2:07:18 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-8-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 3: The basics of generating Web pages
requirement — no “magic,” so to speak. For the sake of putting it somewhere, let’s create a file called views.py, copy this view
code into that file and save it into the mysite directory you created in the previous chapter.
Your Python path
The Python path is the list of directories on your system where Python looks when you use the Python import
statement.
For example, let’s say your Python path is set to ['', '/usr/lib/python2.4/site-packages', '/home/mycode'].
If you execute the Python code from foo import bar, Python will first check for a module called foo.py in the
current directory. (The first entry in the Python path, an empty string, means “the current directory.”) If that file
doesn’t exist, Python will look for the file /usr/lib/python2.4/site-packages/foo.py. If that file doesn’t exist, it
will try /home/mycode/foo.py. Finally, if that file doesn’t exist, it will raise ImportError.
If you’re interested in seeing the value of your Python path, start the Python interactive interpreter and
type import sys, followed by print sys.path.
Generally you don’t have to worry about setting your Python path — Python and Django will take care of things for
you automatically behind the scenes. (If you’re curious, setting the Python path is one of the things that
the manage.py file does.)
How do we tell Django to use this view code? That’s where URLconfs come in.
A URLconf is like a table of contents for your Django-powered Web site. Basically, it’s a mapping between URL patterns and the
view functions that should be called for those URL patterns. It’s how you tell Django “For this URL, call this code, and for that
URL, call that code.”
When you executed django-admin.py startproject in the previous chapter, the script created a URLconf for you automatically:
the file urls.py. Let’s edit that file. By default, it looks something like this:
from django.conf.urls.defaults import *
urlpatterns = patterns('',
# Example:
# (r'^mysite/', include('mysite.apps.foo.urls.foo')),
# Uncomment this for admin:
# (r'^admin/', include('django.contrib.admin.urls')),
)
Let’s step through this code one line at a time:
● The first line imports all objects from the django.conf.urls.defaults module, including a function called patterns.
● The second line calls the function patterns() and saves the result into a variable called urlpatterns. The patterns()
function gets passed only a single argument — the empty string. The rest of the lines are commented out.
The main thing to see here is the variable urlpatterns. This defines the mapping between URLs and the code that handles those
URLs.
By default, everything in the URLconf is commented out — your Django application is a blank slate. (As a side note, that’s how
Django knew to show you the “It worked!” page in the last chapter: If your URLconf is empty, Django assumes you just started a
new project and, hence, displays that message.)
Let’s edit this file to expose our current_datetime view:
from django.conf.urls.defaults import *
from mysite.views import current_datetime
urlpatterns = patterns('',
(r'^now/$', current_datetime),
)
We made two changes here. First, we imported the current_datetime view from its module (mysite/views.py, which translates
into mysite.views in Python import syntax). Next, we added the line (r'^now/$', current_datetime),. This line is referred to
as a URLpattern — it’s a Python tuple in which the first element is a simple regular expression and the second element is the
view function to use for that pattern.
In a nutshell, we just told Django that any request to the URL /now/ should be handled by the current_datetime view function.
A few things are worth pointing out:
● Note that, in this example, we passed the current_datetime view function as an object without calling the function. This is
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH3.html (2 of 9)9/28/2007 2:08:35 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-13-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 3: The basics of generating Web pages
Regular expressions
Regular expressions (or “regexes”) are a compact way of specifying patterns in text. While Django URLconfs allow
arbitrary regexes for powerful URL-matching capability, you’ll probably only use a few regex patterns in practice.
Here’s a small selection of common patterns:
Sym bol Matches
. (dot) Any character
d Any digit
[A-Z] Any character from A-Z (uppercase)
[a-z] Any character from a-z (lowercase)
[A-Za-z] Any character from a-z (case-insensitive)
[^/]+ All characters until a forward slash (excluding the slash itself)
+ One or more of the previous character (e.g., d+ matches one or more digit)
? Zero or more of the previous character (e.g., d* matches zero or more digits)
{1,3} Between one and three (inclusive) of the previous character
For more on regular expressions, see Appendix XXX, Regular Expressions.
Now that we’ve designated a wildcard for the URL, we need a way of passing that data to the view function, so that we can use a
single view function for any arbitrary hour offset. We do this by placing parentheses around the data in the URLpattern that we
want to save. In the case of our example, we want to save whatever number was entered in the URL — so let’s put parentheses
around the d{1,2}:
(r'^now/plus(d{1,2})hours/$', hours_ahead),
If you’re familiar with regular expressions, you’ll be right at home here; we’re using parentheses to capture data from the
matched text.
The final URLconf, including our previous current_datetime view, looks like this:
from django.conf.urls.defaults import *
from mysite.views import current_datetime, hours_ahead
urlpatterns = patterns('',
(r'^now/$', current_datetime),
(r'^now/plus(d{1,2})hours/$', hours_ahead),
)
With that taken care of, let’s write the hours_ahead view.
..admonition: : Coding order
In this case, we wrote the URLpattern first and the view second, but in the previous example, we wrote the view
first, then the URLpattern. Which technique is better?
Well, every developer is different.
If you’ re a big-picture type of person, it may make most sense to you to write all of the URLpatterns for your
application at the same time, at the start of your proj ect, then coding up the views. This has the advantage of
giving you a clear to-do list, and it essentially defines the parameter requirements for the view functions you’ ll
need to write.
If you’ re more of a bottom-up developer, you might prefer to write the views first, then anchor them to URLs
afterward. That’ s OK, too.
In the end, it comes down to what fits your brain the best. Either approach is valid.
hours_ahead is very similar to the current_datetime view we wrote earlier, with a key difference: it takes an extra argument,
the number of hours of offset. Here it is:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH3.html (5 of 9)9/28/2007 2:08:35 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-16-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 3: The basics of generating Web pages
For bonus points, be a perfectionist: allow /now/plus1hour/ and /now/plus2hours/ but disallow /now/plus1hours/
and /now/plus2hour/.
4. Similarly, we were lazy in the HTML display, saying "In %s hour(s), it will be %s." Fix this to remove the hour(s).
The (s) was such a cop-out! If the offset is singular, use 'hour'; otherwise, use 'hours'.
Answers to exercises
1. Here’s one implementation of the hours_behind view:
def hours_behind(request, offset):
offset = int(offset)
dt = datetime.datetime.now() - datetime.timedelta(hours=offset)
html = "<html><body>%s hour(s) ago, it was %s.</body></html>" % (offset, dt)
return HttpResponse(html)
Not much is different between this view and hours_ahead — only the calculation of dt and the text within the HTML.
The URLpattern would look like this:
(r'^now/minus(d{1,2})hours/$', hours_behind),
2. Here’s one implementation of the hour_offset view:
def hour_offset(request, plus_or_minus, offset):
offset = int(offset)
if plus_or_minus == 'plus':
dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
html = 'In %s hour(s), it will be %s.' % (offset, dt)
else:
dt = datetime.datetime.now() - datetime.timedelta(hours=offset)
html = '%s hour(s) ago, it was %s.' % (offset, dt)
html = '<html><body>%s</body></html>' % html
return HttpResponse(html)
The URLpattern would look like this:
(r'^now/(plus|minus)(d{1,2})hours/$', hour_offset),
In this implementation, we capture two values from the URL — the offset, as we did before, but also the string that
designates whether the offset should be positive or negative. They’re passed to the view function in the order in which
they’re captured.
Inside the view code, the variable plus_or_minus will be either the string 'plus' or the string 'minus'. We test that to
determine how to calculate the offset — either by adding or subtracting a datetime.timedelta.
If you’re particularly anal, you may find it inelegant that the view code is “aware” of the URL, having to test for the
string 'plus' or 'minus' rather than some other variable that has been abstracted from the URL. There’s no way around
that; Django does not include any sort of “middleman” layer that converts captured URL parameters to abstracted data
structures, for simplicity’s sake.
3. To accomplish this, we wouldn’t have to change the hour_offset view at all. We’d just need to edit the URLconf slightly.
Here’s one way to do it, by using two URLpatterns:
(r'^now/(plus|minus)(1)hour/$', hour_offset),
(r'^now/(plus|minus)([2-9]|dd)hours/$', hour_offset),
More than one URLpattern can point to the same view; Django processes the patterns in order and doesn’t care how many
times a certain view is referenced. In this case, the first pattern matches the URLs /now/plus1hour/ and /now/minus1hour/
. The (1) is a neat little trick — it passes the value '1' as the captured value, without allowing any sort of wildcard.
The second pattern is more complex, as it uses a slightly tricky regular expression. The key part is ([2-9]|dd). The pipe
character ('|') means “or,” so the pattern in full means “match either the pattern [2-9] or dd.” In other words, that
matches any one-digit number from 2 through 9, or any two-digit number.
4. Here’s a basic way of accomplishing this. Alter the hour_offset function like so:
def hour_offset(request, plus_or_minus, offset):
offset = int(offset)
if offset == 1:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH3.html (8 of 9)9/28/2007 2:08:35 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-19-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
Similarly, dots also allow access of object attributes. For example, a Python datetime.date object has year, month and day
attributes, and you can use a dot to access those attributes in a Django template:
>>> from django.template import Template, Context
>>> import datetime
>>> d = datetime.date(1993, 5, 2)
>>> d.year
1993
>>> d.month
5
>>> d.day
2
>>> t = Template('The month is {{ date.month }} and the year is {{ date.year }}.')
>>> c = Context({'date': d})
>>> t.render(c)
'The month is 5 and the year is 1993.'
This example uses a custom class:
>>> from django.template import Template, Context
>>> class Person(object):
... def __init__(self, first_name, last_name):
... self.first_name, self.last_name = first_name, last_name
>>> t = Template('Hello, {{ person.first_name }} {{ person.last_name }}.')
>>> c = Context({'person': Person('John', 'Smith')})
>>> t.render(c)
'Hello, John Smith.'
Dots are also used to access list indices. For example:
>>> from django.template import Template, Context
>>> t = Template('Item 2 is {{ items.2 }}.')
>>> c = Context({'items': ['apples', 'bananas', 'carrots']})
>>> t.render(c)
'Item 2 is carrots.'
Negative list indices are not allowed. For example, the template variable {{ items.-1 }} would cause a TemplateSyntaxError.
Finally, dots are also used to call methods on objects. For example, each Python string has the methods upper() and isdigit(),
and you can call those in Django templates using the same dot syntax:
>>> from django.template import Template, Context
>>> t = Template('{{ var }} -- {{ var.upper }} -- {{ var.isdigit }}')
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (7 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-27-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
>>> t.render(Context({'var': 'hello'}))
'hello -- HELLO -- False'
>>> t.render(Context({'var': '123'}))
'123 -- 123 -- True'
Note that, in the method calls, you don’t include parentheses. Also, it’s not possible to pass arguments to the methods; you can
only call methods that have no required arguments. (We’ll explain this philosophy later in this chapter.)
The dot lookups can be summarized like this: When the template system encounters a dot in a variable name, it tries the following
lookups, in this order:
● Dictionary lookup. Example: foo["bar"]
● Attribute lookup. Example: foo.bar
● Method call. Example: foo.bar()
● List-index lookup. Example: foo[bar]
The system uses the first lookup type that works. It’s short-circuit logic.
Dot lookups can be nested multiple levels deep. For instance, the following example uses {{ person.name.upper }}, which
translates into a dictionary lookup (person['name']), then a method call (upper()):
>>> from django.template import Template, Context
>>> person = {'name': 'Sally', 'age': '43'}
>>> t = Template('{{ person.name.upper }} is {{ person.age }} years old.')
>>> c = Context({'person': person})
>>> t.render(c)
'SALLY is 43 years old.'
A word about method calls
Method calls are slightly more complex than the other lookup types. Here are some things to keep in mind:
● If, during the method lookup, a method raises an exception, the exception will be propagated, unless the exception has an
attribute silent_variable_failure whose value is True. If the exception does have a silent_variable_failure attribute,
the variable will render as an empty string. For example:
>>> t = Template("My name is {{ person.first_name }}.")
>>> class PersonClass3:
... def first_name(self):
... raise AssertionError, "foo"
>>> p = PersonClass3()
>>> t.render(Context({"person": p}))
Traceback (most recent call last):
...
AssertionError: foo
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (8 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-28-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
Note that it’s possible to change Django’s default behavior in this regard, by tweaking a setting in your Django configuration. We’ll
discuss this in Chapter 10, “Extending the template engine.”
Playing with Context objects
Most of the time, you’ll instantiate Context objects by passing in a fully-populated dictionary to Context(). But you can add and
delete items from a Context object once it’s been instantiated, too, using standard Python dictionary syntax:
>>> from django.template import Context
>>> c = Context({"foo": "bar"})
>>> c['foo']
'bar'
>>> del c['foo']
>>> c['foo']
''
>>> c['newvariable'] = 'hello'
>>> c['newvariable']
'hello'
A Context object is a stack. That is, you can push() and pop() it. If you pop() too much, it’ll
raise django.template.ContextPopException:
>>> c = Context()
>>> c['foo'] = 'first level'
>>> c.push()
>>> c['foo'] = 'second level'
>>> c['foo']
'second level'
>>> c.pop()
>>> c['foo']
'first level'
>>> c['foo'] = 'overwritten'
>>> c['foo']
'overwritten'
>>> c.pop()
Traceback (most recent call last):
...
django.template.ContextPopException
Using a Context as a stack comes in handy in some custom template tags, as you’ll see in Chapter 10.
Basic template tags and filters
As we’ve mentioned already, the template system ships with built-in tags and filters. Here’s a rundown of the most common ones.
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (10 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-30-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
{% ifequal user currentuser %}
<h1>Welcome!</h1>
{% endifequal %}
The arguments can be hard-coded strings, with either single or double quotes, so the following is valid:
{% ifequal section 'sitenews' %}
<h1>Site News</h1>
{% endifequal %}
{% ifequal section "community" %}
<h1>Community</h1>
{% endifequal %}
Just like {% if %}, the {% ifequal %} tag supports an optional {% else %}:
{% ifequal section 'sitenews' %}
<h1>Site News</h1>
{% else %}
<h1>No News Here</h1>
{% endifequal %}
Only template variables, strings, integers and decimal numbers are allowed as arguments to {% ifequal %}. These are valid
examples:
{% ifequal variable 1 %}
{% ifequal variable 1.23 %}
{% ifequal variable 'foo' %}
{% ifequal variable "foo" %}
Any other types of variables, such as Python dictionaries, lists or booleans, can not be hard-coded in {% ifequal %}. These are
invalid examples:
{% ifequal variable True %}
{% ifequal variable [1, 2, 3] %}
{% ifequal variable {'key': 'value'} %}
If you need to test whether something is true or false, use the {% if %} tags instead of {% ifequal %}.
Comments
Just as in HTML or in a programming language such as Python, the Django template language allows for comments. To designate a
comment, use {# #}. For example:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (15 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-35-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
DEBUG = True
TIME_ZONE = 'America/Chicago'
USE_I18N = True
ROOT_URLCONF = 'mysite.urls'
This is pretty self-explanatory; the settings and their respective values are simple Python variables. And because the settings file is
just a plain Python module, you can do dynamic things such as checking the value of one variable before setting another. (This also
means that you should avoid Python syntax errors in your settings file.)
We’ll cover settings files in depth later in this book, but for now, have a look at the TEMPLATE_DIRS setting. This setting tells
Django’s template loading mechanism where to look for templates. By default, it’s an empty tuple. Pick a directory where you’d like
to store your templates, and add it to TEMPLATE_DIRS, like so:
TEMPLATE_DIRS = (
'/home/django/mysite/templates',
)
A few things to note:
● You can specify any directory you want, as long as the directory and templates within that directory are readable by the user
account under which your Web server runs. If you can’t think of an obvious place to put your templates, we recommend
creating a templates directory within your Django project (i.e., within the mysite directory you created in Chapter 2, if you’ve
been following along with our examples).
● Don’t forget the comma at the end of the template-directory string! Python requires commas within single-element tuples to
disambiguate the tuple from a parenthetical statement. This is a common newbie gotcha.
If you want to avoid this error, you can make TEMPLATE_DIRS a list instead of a tuple, because single-element lists don’t
require a trailing comma:
TEMPLATE_DIRS = [
'/home/django/mysite/templates'
]
A tuple is slightly more efficient than a list, though, so we recommend using a tuple for your TEMPLATE_DIRS setting.
● It’s simplest to use absolute paths, i.e. directory paths that start at the root of the filesystem. If you want to be a bit more
flexible and decoupled, though, you can take advantage of the fact that Django settings files are just Python code by
constructing the contents of TEMPLATE_DIRS dynamically. For example:
import os.path
TEMPLATE_DIRS = (
os.path.join(os.path.basename(__file__), 'templates'),
)
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (20 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-40-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
the hole in the parent. If there were two similarly-named {% block %} tags in a template, that template’s parent wouldn’t
know which one of the blocks’ content to use.
● The template name you pass to {% extends %} is loaded using the same method that get_template() uses. That is, the
template name is appended to your TEMPLATE_DIRS setting.
● In most cases, the argument to {% extends %} will be a string, but it can also be a variable, if you don’t know the name of
the parent template until runtime. This lets you do some cool, dynamic stuff.
Exercises
Here are a few exercises that will solidify some of the things you learned in this chapter. (Hint: Even if you think you understood
everything, at least give these exercises, and their respective answers, a read. We introduce a couple of new tricks here.)
1. You’ve got a list of musicians and the genre of music each one plays. This data is stored as a list of dictionaries, which will be
hard-coded in your view module. (Usually we’d use a database for this, but we haven’t yet covered Django’s database layer.)
The list looks like this:
MUSICIANS = [
{'name': 'Django Reinhardt', 'genre': 'jazz'},
{'name': 'Jimi Hendrix', 'genre': 'rock'},
{'name': 'Louis Armstrong', 'genre': 'jazz'},
{'name': 'Pete Townsend', 'genre': 'rock'},
{'name': 'Yanni', 'genre': 'new age'},
{'name': 'Ella Fitzgerald', 'genre': 'jazz'},
{'name': 'Wesley Willis', 'genre': 'casio'},
{'name': 'John Lennon', 'genre': 'rock'},
{'name': 'Bono', 'genre': 'rock'},
{'name': 'Garth Brooks', 'genre': 'country'},
{'name': 'Duke Ellington', 'genre': 'jazz'},
{'name': 'William Shatner', 'genre': 'spoken word'},
{'name': 'Madonna', 'genre': 'pop'},
]
Write a Django view and corresponding template(s) that display an HTML <table> with a row for each musician in this list, in
order. Each row should have two columns: the musician’s name and the type of music he/ she plays.
2. Once you’ve done that: For all the musicians who play jazz or rock — but not the others — bold their names by applying
a style="font-weight: bold;" to their <td> cells.
3. Once you’ve done that: For all the musicians who have a one-word name — but not the others — display an asterisk after their
name. Add a footnote to the page that says “* Pretentious.” Maintain the style="font-weight bold;" from the previous
exercise.
4. Given the following three templates, devise a template-inheritance scheme that removes as much redundancy as possible.
Template 1:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (28 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-48-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
<body>
<h1 id="top">{{ task.title }}</h1>
<p>{{ task.description }}</p>
<hr>
<p><a href="#top">Back to top</a>.</p>
</body>
</html>
Answers to exercises
1. Here’s one possible implementation of the view:
from django.shortcuts import render_to_response
MUSICIANS = [
# ...
]
def musician_list(request):
return render_to_response('musician_list.html', {'musicians': MUSICIANS})
And here’s the template:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<head>
<title>Musician list</title>
</head>
<body>
<table>
<tr><th>Musician</th><th>Genre</th></tr>
{% for musician in musicians %}
<tr>
<td>{{ musician.name }}</td>
<td>{{ musician.genre }}</td>
</tr>
{% endfor %}
</table>
</body>
</html>
2. A rather clumsy way to do this would be to use {% ifequal %} in the template. The view would stay the same as in the
answer to the last exercise, and the template’s {% for %} loop would change to something like this:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (30 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-50-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
{% for musician in musicians %}
<tr>
<td {% ifequal musician.genre 'jazz' %}style="font-weight: bold;"{% endifequal %}
{% ifequal musician.genre 'rock' %}style="font-weight: bold;"{% endifequal %}>
{{ musician.name }}
</td>
<td>{{ musician.genre }}</td>
</tr>
{% endfor %}
This is overly verbose, repetitive and error-prone — and it illustrates an important point. A key to mastering Django’s template
system is to know what to pass to the template. Because templates do not have the full programming-language power of an
environment you might be used to, it’s more important in a Django environment to do as much business logic (as opposed to
presentation logic) as possible in your view.
In this case, a cleaner way of solving the problem would be to have the view precalculate whether a musician’s name is
bolded. After all, this is business logic, not presentation logic. The presentation logic dictates how the special-case genres
should be displayed, not which genres are special-cased. This is an important distinction.
Here’s one way to code the view:
def musician_list(request):
musicians = []
for m in MUSICIANS:
musicians.append({
'name': m['name'],
'genre': m['genre'],
'is_important': m['genre'] in ('rock', 'jazz'),
})
return render_to_response('musician_list.html', {'musicians': musicians})
And with that view, you could use this template code:
{% for musician in musicians %}
<tr>
<td{% if musician.is_important %} style="font-weight: bold;"{% endif %}>
{{ musician.name }}
</td>
<td>{{ musician.genre }}</td>
</tr>
{% endfor %}
See how much cleaner that is in the template? Even this is more complex than it usually will be, because usually you’ll be
dealing with database objects, and database objects can have custom methods (such as is_important()). We’ll cover
database objects in the next chapter.
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (31 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-51-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
3. This is a similar problem to the previous exercise, and the solution is also similar. The key is to precalculate whether a
musician deserves an asterisk next to his or her name. Because that’s business logic, it belongs in the view.
Here’s one possible view implementation:
def musician_list(request):
musicians = []
for m in MUSICIANS:
musicians.append({
'name': m['name'],
'genre': m['genre'],
'is_important': m['genre'] in ('rock', 'jazz'),
'is_pretentious': ' ' not in m['name'],
})
return render_to_response('musician_list.html', {'musicians': musicians})
We’re using the expression ' ' not in m['name'], which returns True if m['name'] doesn’t include a space. You could also
use the .find() method, like this:
'is_pretentious': m['name'].find(' ') == -1
Note that we’re calling this variable is_pretentious rather than has_asterisk, because the fact that we’re using asterisks is
a presentation decision.
With the above view, you could use this template code:
{% for musician in musicians %}
<tr>
<td{% if musician.is_important %} style="font-weight: bold;"{% endif %}>
{% if musician.is_pretentious %}* {% endif %}{{ musician.name }}
</td>
<td>{{ musician.genre }}</td>
</tr>
{% endfor %}
Don’t forget the “* Pretentious.” at the bottom of the template.
For bonus points, be a perfectionist and only display the “* Pretentious” footnote if there’s at least one pretentious musician.
Determine the presence of a pretentious musician in the view, like so:
def musician_list(request):
musicians = []
has_pretentious = False
for m in MUSICIANS:
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (32 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-52-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 4: The Django template system
if ' ' not in m['name']:
has_pretentious = True
musicians.append({
'name': m['name'],
'genre': m['genre'],
'is_important': m['genre'] in ('rock', 'jazz'),
'is_pretentious': ' ' not in m['name'],
})
return render_to_response('musician_list.html', {
'musicians': musicians,
'has_pretentious': has_pretentious,
})
In this implementation, we pass an extra template variable, has_pretentious, to the template. Then use it in the template
like so:
{% if has_pretentious %}* Pretentious{% endif %}
4. Here’s one way to write the base template:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<head>
<link rel="stylesheet" href="default.css" type="text/css">
<title>{% block title %}{% endblock %}</title>
{% block extrahead %}{% endblock %}
</head>
<body>
<h1 id="top">{% block headline %}{% endblock %}</h1>
{% block content %}{% endblock %}
<hr>
<p><a href="#top">Back to top</a>.</p>
</body>
</html>
And, with that base template, here’s how the child templates might look.
Template 1:
{% extends "base.html" %}
{% block title %}My to-do list{% endblock %}
{% block headline %}Latest tasks{% endblock %}
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH4.html (33 of 34)9/28/2007 2:09:26 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-53-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![The Dj ango Book
« previous ◊ table of contents ◊ next »
Chapter 5: Interacting with a database: Models
In Chapter 3, we covered the fundamentals of building dynamic Web sites with Django: setting up views and URLconfs. As we
explained, a view is responsible for doing some arbitrary logic, then returning a response. In the example, our arbitrary logic was
to calculate the current date and time.
In modern Web applications, the arbitrary logic often involves interacting with a database. Behind the scenes, a database-
driven W eb site connects to a database server, retrieves some data out of it and displays that data, nicely formatted, on a Web
page. Or, similarly, the site could provide functionality that lets site visitors populate the database on their own.
Many complex Web sites provide some combination of the two. Amazon.com, for instance, is a great example of a database-
driven site. Each product page is essentially an extract of Amazon’s product database formatted as HTML, and when you post a
customer review, it gets inserted into the database of reviews.
Django is very well-suited for making database-driven Web sites, as it comes with easy yet powerful ways of performing database
queries using Python. This chapter explains that functionality — Django’s database layer.
(Note: While it’s not strictly necessary to know basic database theory and SQL in order to use Django’s database layer, it’s highly
recommended. An introduction to those concepts is out of the scope of this book, but keep reading even if you’re a database
newbie. You’ll probably be able to follow along and grasp concepts based on context.)
The “ dumb” way to do database queries in views
Just as the previous chapter detailed a “dumb” way to output HTML within a view (by hard-coding HTML directly within the view),
there’s a “dumb” way to retrieve data from a database in a view. It’s simple: Just use any existing Python library to execute an
SQL query and do something with the results.
In this example view, we use the MySQLdb library (available at http: / / sourceforge.net/ projects/ mysql-python) to connect to a
MySQL database, retrieve some records and feed them to a template for display as a Web page:
from django.shortcuts import render_to_response
import MySQLdb
def book_list(request):
db = MySQLdb.connect(user='me', db='mydb', passwd='secret', host='localhost')
cursor = db.cursor()
cursor.execute('SELECT name FROM books ORDER BY name')
names = [row[0] for row in cursor.fetchall()]
db.close()
return render_to_response('book_list.html', {'names': names})
This approach works, but some problems should jump out at you immediately:
● We’re hard-coding the database connection parameters. Ideally, these parameters would be stored in the Django
configuration.
● We’re having to write a fair bit of boilerplate code: creating a connection, creating a cursor, executing a statement and
closing the connection. Ideally, all we’d have to do is specify which results we wanted.
● It ties us to MySQL. If, down the road, we switch from MySQL to PostgreSQL, we’ll have to use a different database adapter
(e.g., psycopg rather than MySQLdb), alter the connection parameters and — depending on the nature of the SQL statement
— possibly rewrite the SQL. Ideally, the database server we’re using would be abstracted, so that a database server change
could be made in a single place.
As you might expect, Django’s database layer aims to solve these problems. Here’s a sneak preview of how the above view can
be rewritten using Django’s database API:
from django.shortcuts import render_to_response
from mysite.books.models import Book
def book_list(request):
books = Book.objects.order_by('name')
return render_to_response('book_list.html', {'books': books})
We’ll explain this code a little later in this chapter. For now, just get a feel for how it looks.
The MTV development pattern
Chapter 5: Interacting with a database: models
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH5.html (1 of 9)9/28/2007 2:09:56 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-55-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 5: Interacting with a database: models
The syncdb command is a simple “sync” of your models to your database. It looks at all of the models in each app in
your INSTALLED_APPS setting, checks the database to see whether the appropriate tables exist yet, and creates the tables if they
don’t yet exist. Note that syncdb does not sync changes in models or deletions of models; if you make a change to a model or
delete a model, and you want to update the database, syncdb will not handle that. (More on this later.)
If you run python manage.py syncdb again, nothing happens, because you haven’t added any models to the books app, or
added any apps to INSTALLED_APPS. Ergo, it’s always safe to run python manage.py syncdb — it won’t clobber things.
If you’re interested, take a moment to dive into your database server’s command-line client and see the database tables Django
created. You can manually run the command-line client — e.g., psql for PostgreSQL — or you can run the
command python manage.py dbshell, which will figure out which command-line client to run, depending on
your DATABASE_SERVER setting. The latter is almost always more convenient.
Basic data access
Once you’ve created a model, Django automatically provides a high-level Python API for working with those models. Try it out by
running python manage.py shell and typing the following:
>>> from books.models import Publisher
>>> p = Publisher(name='Apress', address='2560 Ninth St.',
... city='Berkeley', state_province='CA', country='U.S.A.',
... website='http://www.apress.com/')
>>> p.save()
>>> p = Publisher(name="O'Reilly", address='10 Fawcett St.',
... city='Cambridge', state_province='MA', country='U.S.A.',
... website='http://www.oreilly.com/')
>>> p.save()
>>> publisher_list = Publisher.objects.all()
>>> publisher_list
[<Publisher: Publisher object>, <Publisher: Publisher object>]
In only a few lines of code, this has accomplished quite a bit. The highlights:
● To create an object, just import the appropriate model class and instantiate it by passing in values for each field.
● To save the object to the database, call the save() method on the object. Behind the scenes, Django executes an
SQL INSERT statement here.
● To retrieve objects from the database, use the attribute Publisher.objects. Fetch a list of all Publisher objects in the
database with the statement Publisher.objects.all(). Behind the scenes, Django executes an SQL SELECT statement
here.
Naturally, you can do quite a lot with the Django database API — but first, let’s take care of a small annoyance.
Adding model string representations
Above, when we printed out the list of publishers, all we got was this unhelpful display that makes it difficult to tell the Publisher
objects apart:
[<Publisher: Publisher object>, <Publisher: Publisher object>]
We can fix this easily by adding a method called __str__() to our Publisher object. A __str__() method tells Python how to
display the “string” representation of an object. You can see this in action by adding a __str__() method to the three models:
class Publisher(models.Model):
name = models.CharField(maxlength=30)
address = models.CharField(maxlength=50)
city = models.CharField(maxlength=60)
state_province = models.CharField(maxlength=30)
country = models.CharField(maxlength=50)
website = models.URLField()
def __str__(self):
return self.name
class Author(models.Model):
salutation = models.CharField(maxlength=10)
first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=40)
email = models.EmailField()
headshot = models.ImageField(upload_to='/tmp')
def __str__(self):
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH5.html (8 of 9)9/28/2007 2:09:56 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-62-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 5: Interacting with a database: models
return '%s %s' % (self.first_name, self.last_name)
class Book(models.Model):
title = models.CharField(maxlength=100)
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField()
def __str__(self):
return self.title
As you can see, a __str__() method can do whatever it needs to do in order to return a string representation. Here,
the __str__() methods for Publisher and Book simply return the object’s name and title, respectively, but the __str__()
for Author is slightly more complex — it pieces together the first_name and last_name fields. The only requirement
for __str__() is that it return a string. If __str__() doesn’t return a string — if it returns, say, an integer — then Python will
raise a TypeError with a message like "__str__ returned non-string".
For the changes to take effect, exit out of the Python shell and enter it again with python manage.py shell. (This is the easiest
way to make code changes take effect.) Now, the list of Publisher objects is much easier to understand:
>>> from books.models import Publisher
>>> publisher_list = Publisher.objects.all()
>>> publisher_list
[<Publisher: Apress>, <Publisher: O'Reilly>]
Make sure any model you define has a __str__() method — not only for your own convenience when using the interactive
interpreter, but also because Django uses the output of __str__() in several places when it needs to display objects.
Finally, note that __str__() is a good example of adding behavior to models. A Django model describes more than the database
table layout for an object; it also describes any functionality that object knows how to do. __str__() is one example of such
functionality — a model knows how to display itself.
Creating and modifying obj ects
This chapter is not yet finished.
« previous ◊ table of contents ◊ next »
Copyright 2006 Adrian Holovaty and Jacob Kaplan-Moss.
This work is licensed under the GNU Free Document License.
file:///D|/books/computer/programming/python/books/DJANGO BOOK/CH5.html (9 of 9)9/28/2007 2:09:56 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-63-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 8: Advanced views and URLconfs
urlpatterns = patterns('mysite.views',
(r'^now/$', 'current_datetime'),
(r'^now/plus(d{1,2})hours/$', 'hours_ahead'),
(r'^now/minus(d{1,2})hours/$', 'hours_behind'),
(r'^now/in_chicago/$', 'now_in_chicago'),
(r'^now/in_london/$', 'now_in_london'),
)
Note that you don’t put a trailing dot (".") in the prefix, nor do you put a leading dot in the view strings. Django puts that in
automatically.
With these two approaches in mind, which is better? It really depends on your personal coding style and needs.
Advantages of the string approach are:
● It’s more compact, because it doesn’t require you to import the view functions.
● It results in more readable and manageable URLconfs if your view functions are spread across several different Python
modules.
Advantages of the function object approach are:
● It allows for easy “wrapping” of view functions. See “Wrapping view functions” later in this chapter.
● It’s more “Pythonic” — that is, it’s more in line with Python traditions, such as passing functions as objects.
Both approaches are valid, and you can even mix them within the same URLconf. The choice is yours.
Multiple view prefixes
In practice, if you use the string technique, you’ll probably end up mixing views to the point where the views in your URLconf
won’t have a common prefix. However, you can still take advantage of the view prefix shortcut to remove duplication. Just add
multiple patterns() objects together, like this:
Old:
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^/?$', 'mysite.views.archive_index'),
(r'^(d{4})/([a-z]{3})/$', 'mysite.views.archive_month'),
(r'^tag/(w+)/$', 'weblog.views.tag'),
)
New:
from django.conf.urls.defaults import *
urlpatterns = patterns('mysite.views',
(r'^/?$', 'archive_index'),
(r'^(d{4})/([a-z]{3})/$','archive_month'),
)
urlpatterns += patterns('weblog.views',
(r'^tag/(w+)/$', 'tag'),
)
All the framework cares about is that there’s a module-level variable called urlpatterns. This variable can be constructed
dynamically, as we do in this example.
Named groups
In all of our URLconf examples so far, we’ve used simple, non-named regular-expression groups — i.e., we put parentheses
around parts of the URL we wanted to capture, and Django passes that captured text to the view function as a positional
argument. In more advanced usage, it’s possible to use named regular-expression groups to capture URL bits and pass them as
keyword arguments to a view.
Keyw ord argum ents vs. positional argum ents
A Python function can be called using keyword arguments or positional arguments — and, in some cases, both at
the same time. In a keyword argument call, you specify the names of the arguments along with the values you’re
passing. In a positional argument call, you simply pass the arguments without explicitly specifying which argument
matches which value; the association is implicit in the arguments’ order.
file:///D|/books/computer/programming/python/books/DJANGO BOOK/ch8.html (2 of 11)9/28/2007 2:27:13 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-79-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 8: Advanced views and URLconfs
improvement to the example in the Giving a view configuration options section by providing a default value for template_name:
def my_view(request, template_name='mysite/my_view.html'):
var = do_something()
return render_to_response(template_name, {'var': var})
Special-casing views
Sometimes you’ll have a pattern in your URLconf that handles a large set of URLs but you’ll need to special-case one of them. In
this case, take advantage of the linear way a URLconf is processed and put the special case first.
For example, the “add an object” pages in Django’s admin site are represented by this URLconf line:
urlpatterns = patterns('',
# ...
('^([^/]+)/([^/]+)/add/$', 'django.contrib.admin.views.main.add_stage'),
# ...
)
This matches URLs such as /myblog/entries/add/ and /auth/groups/add/. However, the “add” page for a user object
(/auth/user/add/) is a special case — it doesn’t display all of the form fields, it displays two password fields, etc. We could solve
this by special-casing in the view, like so:
def add_stage(request, app_label, model_name):
if app_label == 'auth' and model_name == 'user':
# do special-case code
else:
# do normal code
…but that’s inelegant for a reason we’ve touched on multiple times in this chapter: it puts URL logic in the view. As a more
elegant solution, we can take advantage of the fact that URLconfs are processed in order from top to bottom:
urlpatterns = patterns('',
# ...
('^auth/user/add/$', 'django.contrib.admin.views.auth.user_add_stage'),
('^([^/]+)/([^/]+)/add/$', 'django.contrib.admin.views.main.add_stage'),
# ...
)
With this in place, a request to /auth/user/add/ will be handled by the user_add_stage view. Although that URL matches the
second pattern, it matches the top one first. (This is short-circuit logic.)
Notes on capturing text in URLs
Each captured argument is sent to the view as a plain Python string, regardless of what sort of match the regular expression
makes. For example, in this URLconf line:
(r'^articles/(?P<year>d{4})/$', views.year_archive),
…the year argument to views.year_archive() will be a string, not an integer, even though the d{4} will only match integer
strings.
This is important to keep in mind when you’re writing view code. Many built-in Python functions are fussy (and rightfully so)
about accepting only objects of a certain type. A common error is to attempt to create a datetime.date object with string values
instead of integer values:
>>> import datetime
>>> datetime.date('1993', '7', '9')
Traceback (most recent call last):
...
TypeError: an integer is required
>>> datetime.date(1993, 7, 9)
datetime.date(1993, 7, 9)
Translated to a URLconf and view, the error looks like this:
# urls.py
from django.conf.urls.defaults import *
file:///D|/books/computer/programming/python/books/DJANGO BOOK/ch8.html (8 of 11)9/28/2007 2:27:13 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-85-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![The Dj ango Book
« previous ◊ table of contents ◊ next »
Chapter 9: Generic views
Here again is a recurring theme of this book: at its worst, web development is boring and monotonous.
So far we’ve covered how Django tries to take away some of that monotony at the model and template layers, but web
developers also experience this boredom at the view level.
Django’s generic view s were to developed to ease that pain. They take certain common idioms and patterns in view
development and abstract them so that you can quickly write common views of onto data without having to write too much code.
In fact, nearly every view example in the preceding chapters could be re-written with the help of generic views.
Django contains generic views to do the following:
● Perform common “simple” tasks: redirect to a different page, and render a given template.
● Display list and detail pages for a single object. For example, the Django documentation index (http: / / www.djangoproject.
com/ documentation/ ) and individual document pages are built this way. The crime index and list of crimes by type views
from Chapter 5 could easily be re-written to use generic views; we’ll do so below.
● Present date-based objects in year/ month/ day archive pages, associated detail and “latest” pages. The Django weblog’s
(http: / / www.djangoproject.com/ weblog/ ) year, month, and day archives are built with these, as are ljworld.com’s news
archives, and a whole host of others.
● Allow users to create, update, and delete objects — with or without authorization.
Taken together, these views provide easy interfaces to perform the most common tasks developers encounter.
Using generic views
All of these views are used by creating configuration dictionaries in your URLconf files and passing those dictionaries as the third
member of the URLconf tuple for a given pattern.
For example, here’s the URLconf for the simple weblog app that drives the blog on djangoproject.com:
from django.conf.urls.defaults import *
from django_website.apps.blog.models import Entry
info_dict = {
'queryset': Entry.objects.all(),
'date_field': 'pub_date',
}
urlpatterns = patterns('django.views.generic.date_based',
(r'^(?P<year>d{4})/(?P<month>[a-z]{3})/(?P<day>w{1,2})/(?P<slug>[-w]+)/$',
'object_detail', dict(info_dict, slug_field='slug')),
(r'^(?P<year>d{4})/(?P<month>[a-z]{3})/(?P<day>w{1,2})/$',
'archive_day', info_dict),
(r'^(?P<year>d{4})/(?P<month>[a-z]{3})/$',
'archive_month', info_dict),
(r'^(?P<year>d{4})/$',
'archive_year', info_dict),
(r'^/?$',
'archive_index', info_dict),
)
As you can see, this URLconf defines a few options in info_dict. 'queryset' gives the generic view a QuerySet of objects to use
(in this case, all of the Entry objects) and tells the generic view which model is being used. The remaining arguments to each
generic view are taken from the named captures in the URLconf.
This is really all the “view” code for Django’s weblog! The only thing that’s left is writing a template.
Documentation of each generic view follows, along with a list of all keyword arguments that a generic view expects. Remember
that as in the example above, arguments may either come from the URL pattern (as month, day, year, etc. do above) or from the
additional-information dictionary (as for queryset, date_field, etc.).
Most generic views require the queryset key, which is a QuerySet instance; see the database API reference in Appendix 3 for
more information about QuerySet objects.
Chapter 9: Generic views
file:///D|/books/computer/programming/python/books/DJANGO BOOK/09.html (1 of 17)9/28/2007 2:27:38 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-89-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 9: Generic views
A boolean representing whether there’s a next page.
has_previous
A boolean representing whether there’s a previous page.
page
The current page number, as an integer. This is 1-based.
next
The next page number, as an integer. If there’s no next page, this will still be an integer representing the theoretical next-page
number. This is 1-based.
previous
The previous page number, as an integer. This is 1-based.
pages
The total number of pages, as an integer.
hits
The total number of objects across all pages, not just this page.
A note on pagination:
If paginate_by is specified, Django will paginate the results. You can specify the page number in the URL in one of
two ways:
● Use the page parameter in the URLconf. For example, this is what your URLconf might look like:
(r'^objects/page(?P<page>[0-9]+)/$', 'object_list', dict(info_dict))
● Pass the page number via the page query-string parameter. For example, a URL would look like this:
/ obj ects/ ?page=3
In both cases, page is 1-based, not 0-based, so the first page would be represented as page 1.
Detail views
The django.views.generic.list_detail.object_detail gives a “detail” view of a single object.
Example
Extending the example above, we could make a detail view for a given author. Given an info dict like this:
author_detail_info = {
"queryset" : Author.objects.all(),
"template_object_name" : "author",
}
We could use a urlpattern like:
(r'^authors/(?P<object_id>d+)/$', list_detail.object_detail, author_detail_info),
to show details about a given book, rendered in the bookstore/author_detail.html template. In that template, the Author
object itself would be put into the {{ author }} variable.
Required arguments
queryset`
A QuerySet that will be searched for the object.
Either:
object_id
The value of the primary-key field for the object.
or:
slug
The slug of the given object. If you pass this field, then the slug_field argument (below) is also required.
file:///D|/books/computer/programming/python/books/DJANGO BOOK/09.html (5 of 17)9/28/2007 2:27:38 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-93-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 9: Generic views
Required arguments
date_field
As above.
queryset
A QuerySet of objects for which the archive serves.
year
The four-digit year for which the archive serves (usually taken from URL parameters).
Optional arguments
make_object_list
A boolean specifying whether to retrieve the full list of objects for this year and pass those to the template. If True, this list of
objects will be made available to the template as object_list. (The name object_list may be different; see the information
about object_list in the “Template context” section below.) By default, this is False.
allow_future
A boolean specifying whether to include “future” objects on this page, as described in the note above.
This view may also take these common arguments (documented above):
● allow_empty
● context_processors
● extra_context
● mimetype
● template_loader
● template_name
● template_object_name
Template name
If template_name isn’t specified, this view will use the template <app_label>/<model_name>_archive_year.html by default.
Template context
In addition to extra_context, the template’s context will be:
date_list
A list of datetime.date objects representing all months that have objects available in the given year, according to queryset,
in ascending order.
year
The given year, as a four-character string.
object_list
If the make_object_list parameter is True, this will be set to a list of objects available for the given year, ordered by the date
field. This variable’s name depends on the template_object_name parameter, which is 'object' by default.
If template_object_name is 'foo', this variable’s name will be foo_list.
If make_object_list is False, object_list will be passed to the template as an empty list.
Monthly archives
The django.views.generic.date_based.archive_month views provides a monthly archive page showing all objects in a given
month.
Example
Continuing on with our example, creating month views should look mighty familiar:
(r'^(?P<year>d{4})/(?P<month>[a-z]{3})/$', date_based.archive_month, book_info),
Required arguments
year
The four-digit year for which the archive serves (a string).
month
The month for which the archive serves, formatted according to the month_format argument.
file:///D|/books/computer/programming/python/books/DJANGO BOOK/09.html (8 of 17)9/28/2007 2:27:38 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-96-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 9: Generic views
queryset
A QuerySet of objects for which the archive serves.
date_field
The name of the DateField or DateTimeField in the QuerySet‘s model that the date-based archive should use to determine
the objects on the page.
Optional arguments
allow_future
A boolean specifying whether to include “future” objects on this page, as described in the note above.
This view may also take these common arguments (documented above):
● allow_empty
● context_processors
● extra_context
● mimetype
● template_loader
● template_name
● template_object_name
Template name
If template_name isn’t specified, this view will use the template <app_label>/<model_name>_archive_week.html by default.
Template context
In addition to extra_context, the template’s context will be:
week
A datetime.date object representing the first day of the given week.
object_list
A list of objects available for the given week. This variable’s name depends on the template_object_name parameter, which
is 'object' by default. If template_object_name is 'foo', this variable’s name will be foo_list.
Day archives
The django.views.generic.date_based.archive_day view provides a page showing all objects in a given day.
Example
Keep on keepin’ on:
(r'^(?P<year>d{4})/(?P<month>[a-z]{3})/(?P<day>d{2})/$', date_based.archive_day, book_info),
Required arguments
year
The four-digit year for which the archive serves (a string).
month
The month for which the archive serves, formatted according to the month_format argument.
day
The day for which the archive serves, formatted according to the day_format argument.
queryset
A QuerySet of objects for which the archive serves.
date_field
The name of the DateField or DateTimeField in the QuerySet‘s model that the date-based archive should use to determine
the objects on the page.
Optional arguments
month_format
A format string that regulates what format the month parameter uses. See the detailed explanation above.
day_format
Like month_format, but for the day parameter. It defaults to "%d" (day of the month as a decimal number, 01-31).
file:///D|/books/computer/programming/python/books/DJANGO BOOK/09.html (10 of 17)9/28/2007 2:27:38 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-98-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
![Chapter 9: Generic views
allow_future
A boolean specifying whether to include “future” objects on this page, as described in the note above.
This view may also take these common arguments (documented above):
● allow_empty
● context_processors
● extra_context
● mimetype
● template_loader
● template_name
● template_object_name
Template name
If template_name isn’t specified, this view will use the template <app_label>/<model_name>_archive_day.html by default.
Template context
In addition to extra_context, the template’s context will be:
day
A datetime.date object representing the given day.
next_day
A datetime.date object representing the next day. If the next day is in the future, this will be None.
previous_day
A datetime.date object representing the given day. Unlike next_day, this will never be None.
object_list
A list of objects available for the given day. This variable’s name depends on the template_object_name parameter, which
is 'object' by default. If template_object_name is 'foo', this variable’s name will be foo_list.
Archive for today
The django.views.generic.date_based.archive_today view shows all objects for today. This is exactly the same
as archive_day, except the year/ month/ day arguments are not used, and today’s date is used instead.
Date-based detail pages
The django.views.generic.date_based.object_detail view shows a page representing an individual object. This differs from
the object_detail page in their respective URLs; the object_detail view uses URLs like /entries/<slug>/, while this one
uses URLs like /entries/2006/aug/27/<slug>/.
Note
If you’re using date-based detail pages with slugs in the URLs, you probably also want to use the unique_for_date
option on the slug field to validate that slugs aren’t duplicated in a single day. See Appendix 2 for details
on unique_for_date.
Example
This one differs (slightly) from all the other examples in that we need to either provide an object ID or a slug so that Django can
look up the object in question.
Since the object we’re using doesn’t have a slug field, we’ll use the slightly uglyier ID-based URLs. In practice we’d prefer to use
a slug field, but in the interest of simplicity we’ll let it go.
We’ll add the following to the URLconf:
(r'^(?P<year>d{4})/(?P<month>[a-z]{3})/(?P<day>d{2})/(?P<object_id>[w-]+)/$', date_based.
object_detail, book_info),
Required arguments
year
The object’s four-digit year (a string).
month
file:///D|/books/computer/programming/python/books/DJANGO BOOK/09.html (11 of 17)9/28/2007 2:27:38 PM](/p?url=https%3A%2F%2Fimage.slidesharecdn.com%2F0506-django-web-framework-for-python-220826170142-795f0a87%2F85%2F0506-django-web-framework-for-python-pdf-99-320.jpg&__src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2F0506djangowebframeworkforpythonpdf%2F252714815%2397&__type=image)
Uploaded byradhianiedjan1
111 views
0506-django-web-framework-for-python.pdf
This document is the table of contents for "The Django Book", which is a guide to the Django web framework for Python. It lists the chapter titles and their dates, which cover topics like introductions to Django, getting started, generating web pages, templates, databases, forms, views, URLs, and deployment. The book is being released chapter-by-chapter and is licensed under the GNU Free Document License.
