[This is the first part of a two-part series. In this installment we'll cover the basics of building a blog, using Django. In the second installment, we'll put the finishing touches on it.]
Django bills itself as "the Web framework for perfectionists with deadlines." So let's put ourselves on deadline and see how fast we can produce a simple blog using Django. (We'll address your perfectionist side later.)
Note: This chapter assumes you've already installed Django on your system. If you haven't, consult Appendix B, "Installing and Running Django."
bash, tcsh, zsh, Cygwin, or what have you). So open your terminal and cd to a directory that is on your PYTHONPATH environment variable. On a Unix-based system such as Linux, Mac OS X, FreeBSD, and so on, you can issue an echo $PYTHONPATH command to see its contents; from a Win32 Command window, type echo %PYTHONPATH%. You can read more about paths in both the installation and Python chapters.
We recommend you try to follow along and actually build the blog as you go. If that's not practical\u2014if you aren't near a computer, or you're just impatient—simply reading it is illuminating too.That's especially true if you have experience with one or more other modern Web frameworks, since many of the basic concepts are familiar.
If you are following along on your own computer, and you reach a point where the results you're getting don't match what you see here, stop and re-examine the step you just completed, and then review the two or three steps before that. Look for a spot where you could have skipped over a seemingly unimportant detail or didn't understand a specific instruction. If no light bulbs come on, delete your sample project and start over.The authors used this method when learning Django; in addition to being faster than staring blankly at error messages for hours, the repetition of the steps leading up to your trouble spot really help with your retention!
Creating the Project
The easiest way to organize your Django code when you are starting out is to use what Django calls a project: A directory of files that constitute, usually, a single Web site. Django comes with a utility called django-admin.py to streamline tasks such as the creation of these project directories. On Unix, it has a default installation into the /usr/bin directory, and if you're on Win32, it goes into the Scripts folder right in your Python installation, for example, C:\Python25\Scripts. In either case, you need to make sure that django-admin.py is in your PATH so it can be executed from the command line.
To create the project directory for your blog project, issue this django-admin.py command:
On a Win32 box, you need to open a DOS Command window first. It can be accessed via Start -> Programs -> Accessories -> Command Prompt. Also, instead of a $, you see something like C:\WINDOWS\system32> as a shell prompt.
Now take a look at the contents of the directory to see what this command has created for you. It should look something like this on Unix:
If you were developing on a Win32 platform, opening an Explorer window to that folder looks something like Figure 2.1, if we created a folder named C:\py\django with the intention of putting our project there.
Note: As you probably know if you're an advanced Python user, that init.py file makes this project directory a Python package—a collection of related Python modules. Its status as a package enables us to use Python's dot-notation to address individual pieces of our project, such as mysite.urls.
Besides init.py, the startproject command has created three other files.
manage.pyis a utility for working with this Django project. You can see from its permissions flags in the directory listing that it is executable. We run it in a moment.settings.pyis a file containing default settings for your project. These include database information, debugging flags,and other important variables. Any value in this file is available to any of your project's installed apps—we show you the usefulness of that as we progress through this chapter.urls.pyis what's known in Django as a URLconf, a configuration file that maps URL patterns to actions your applications perform. URLconfs are an exciting and powerful feature of Django.
Note: Every file created by the startproject command is Python source code. There's no XML, no .ini files, and no funky configuration syntax. Django pursues a "pure Python" philosophy wherever possible. This gives you a lot of flexibility without adding complexity to the framework. For example, if you want your settings file to import settings from some other file or to calculate a value instead of having it hardcoded, there's no barrier—it's just Python.
Running the Development Server
At this point, you haven't built your blog application yet, but nonetheless there are some Django conveniences in place for your use. One of the handiest is Django's built-in Web server. It's a server designed not for deploying public sites, but for quick development. Advantages of using it include
- You don't need to install Apache, Lighttpd, or whatever other Web server software you'd use in actual production—great if you're working on a fresh server or a non-server development machine or just playing around.
- It automatically detects when you make changes to your Python source files and reloads those modules. This is a huge time-saver compared to manually restarting your Web server every time you edit your code, which is what's required with most Python Web server setups.
- It knows how to find and display static media files for the admin application, so you can work with it right away.
Running the development (or "dev") server is as simple as issuing a single command. We're going to use our project's manage.py utility, a thin wrapper script that saves us the work of telling django-admin.py to use our specific project settings file. The command to run the dev server is
You should see something like the following with a slight difference for Win32 platforms where the quit key combination is CTRL-BREAK instead of CONTROL-C:
Open that link in your browser, and you should see Django's "It Worked!" screen, as shown in Figure 2.2.
Meanwhile, if you look in your terminal session, you see the dev server has logged your GET request.
The four chunks of the log line are from left to right: timestamp, request, HTTP response code, and byte count. (Your byte count is likely to be slightly different.) The response code is 404 ("Not Found") because your project has no URLs defined yet. The It Worked! page is Django's friendly way of telling you that.
Tip: If your server isn't working at this point, retrace your steps. Be ruthless! It's probably easier to delete your whole project and start following this chapter again from the beginning than it is to laboriously check every file and every line of code.
When you've successfully got the server running, we can move on to setting up your first Django application.
Find a programming school near you
