Django for the Impatient: Blog Building Basics / Page 2

Django for the Impatient: Blog Building Basics [con't]

Creating the Blog Application

Now that we have a project, we can create applications (or "apps" in Django-speak) within it. To create our blog app, we'll use manage.py again.

./manage.py startapp blog # or ".\manage.py startapp blog" on win32

It's just as simple as starting a project. Now we have a blog directory inside our project directory. Here's what's in it, first in Unix format, and then in a screenshot of Windows Explorer (see Figure 2.3).

$ ls -l blog/ total 16 -rw-r--r-- 1 pbx pbx 0 Jun 26 20:33 __init__.py -rw-r--r-- 1 pbx pbx 57 Jun 26 20:33 models.py -rw-r--r-- 1 pbx pbx 26 Jun 26 20:33 views.py

Like your project, your app is a package too. The models.py and views.py files have no real code in them; they're merely placeholders. For our simple blog, in fact, we don't need to touch the dummy views.py file at all.

To tell Django this new app is part of your project, you need to edit settings.py (which we can also refer to as your "settings file"). Open your settings file in your editor and find the INSTALLED_APPS tuple near the bottom. Add your app in dotted module form to that tuple in a line that looks like this (note the trailing comma):

'mysite.blog',

Django uses INSTALLED_APPS to determine the configuration of various parts of the system, including the automatic admin application and the testing framework.

Designing Your Model

We've now arrived at the core of your Django-based blog application: the models.py file. This is where we'll define the data structures of the blog. Following the principle of Don't Repeat Yourself (DRY), Django gets a lot of mileage out of the model information you provide for your application. Let's create a basic model, and then see all the stuff Django does for us using that information.

Open up models.py in your favorite text editor (bonus points if it has a Python mode with syntax coloring). You see this placekeeper text:

from django.db import models # Create your models here.

Delete the comment, and then add the following lines:

class BlogPost(models.Model): title = models.CharField(max_length=150) body = models.TextField() timestamp = models.DateTimeField()

That's a complete model, representing a "BlogPost" object with three fields. (Actually, strictly speaking it has four fields—Django automatically creates an auto-incrementing, unique id field for each model by default.)

You can see our newly minted class, BlogPost, is a subclass of django.db.models.Model. That's Django's standard base class for data models, which is the core of Django's powerful object-relational mapping system. Also,you notice our fields are defined like regular class attributes with each one being an instance of a particular field class. Those field classes are also defined in django.db.models, and there are many more types—ranging from BooleanField to XMLField—than the three we're using here.

Setting Up the Database

If you don't have a database server installed and running, we recommend SQLite as the fastest and easiest way to get going. It's fast, widely available, and stores its database as a single file in the filesystem. Access controls are simply file permissions.

If you do have a database server—PostgreSQL, MySQL, Oracle, MSSQL—and want to use it rather than SQLite, then use your database's administration tools to create a new database for your Django project. We name this database "djangodb" in our examples, but you can name it whatever you like.

Either way, with your (empty) database in place, all that remains is to tell Django how to use it.This is where your project's settings.py file comes in.

Using a Database Server

Many people use Django with a relational database server such as PostgreSQL or MySQL. There are six potentially relevant settings here (though you may need only two): DATABASEENGINE, DATABASENAME, DATABASEHOST, DATABASEPORT, DATABASEUSER, and DATABASEPASSWORD. Their names make their respective purposes pretty obvious. Just plug in the correct values corresponding to the database server you are using with Django. For example, settings for MySQL look something like this:

DATABASE_ENGINE = "mysql" DATABASE_NAME = "djangodb" DATABASE_HOST = "localhost" DATABASE_USER = "paul" DATABASE_PASSWORD = "pony" # secret!

Note: We haven't specified DATABASEPORT because that's only needed if your database server is running on a nonstandard port. For example, MySQL's server uses port 3306 by default. Unless you've changed the setup, you don't have to specify DATABASEPORT at all.

For details on creating a new database and database user (which is required for database servers), see Appendix B.

Using SQLite

SQLite is a popular choice for testing and even for deployment in scenarios where there isn't a great deal of simultaneous writing going on. No host, port, user, or password information is needed because SQLite uses the local filesystem for storage and the native filesystem permissions for access control. So only two settings are needed to tell Django to use your SQLite database.

DATABASE_ENGINE = "sqlite3" DATABASE_NAME = "/var/db/django.db"

Note: When using SQLite with a real Web server such as Apache, you need to make sure the account owning the Web server process has write access both for the database file itself and the directory containing that database file. When working with the dev server like we are here, permissions are typically not an issue because the user (you) running the dev server also owns the project files and directories.

SQLite is also one of the most popular choices on Win32 platforms because it comes free with the Python distribution. Given we have already created a C:\py\django directory with our project (and application), let's create a db directory as well.

DATABASE_ENGINE = 'sqlite3' DATABASE_NAME = r'C:\py\django\db\django.db'

If you are new to Python, you notice the subtle difference in the first example; we used double quotes around sqlite3, whereas in the Win32 version, we used single quotes. Rest assured it has nothing to do with differing platforms—Python does not have a character type, so single quotes and double quotes are treated the same. Just make sure you open and close a string with the same type of quote!

You should also have noticed a small "r" in front of the folder name. If you've read Chapter 1, then you know this means to designate the object as a "raw string," or one that takes all characters of a string verbatim, meaning do not translate special character combinations. For example, usually means a newline character, but in a raw string, it means (literally) two characters: a backslash followed by an n. So the purpose of a raw string is specifically for DOS file paths, telling Python to not translate special characters (if there are any).

Creating the Tables

Now you tell Django to use the connection information you've given it to connect to the database and set up the tables your application needs. The command to do this is simply:

./manage.py syncdb # or ".\manage.py syncdb" on win32

You see some output that starts like this as Django sets up the database:

Creating table auth_message Creating table auth_group Creating table auth_user Creating table auth_permission Creating table django_content_type Creating table django_session Creating table django_site Creating table blog_blogpost

When you issue the syncdb command, Django looks for a models.py file in each of your INSTALLED_APPS. For each model it finds, it creates a database table. (There are exceptions to this later when we get into fancy stuff such as many-to-many relations, but it's true for this example. If you are using SQLite, you also notice the django.db database file is created exactly where you specified.)

The other items in INSTALLED_APPS, the ones that were there by default, all have models too. The output from manage.py syncdb confirms this, as you can see Django is creating one or more tables for each of those apps.

That's not all the output you got from the syncdb command, though. You also got some interactive queries related to the django.contrib.auth app.

You just installed Django's auth system, which means you don't have any superusers defined. Would you like to create one now? (yes/no): yes Username (Leave blank to use 'pbx'): E-mail address: pb@e-scribe.com Password: Password (again): Superuser created successfully. Installing index for auth.Message model Installing index for auth.Permission model

Now you've got one superuser (hopefully yourself) in the auth system. This comes in handy in a moment, when we add in Django's automatic admin application.

Finally, the process wraps up with a couple lines relating to a feature called fixtures, which we come back to in Chapter 4, "Defining and Using Models." These enable you to preload data in a freshly created application. For now, we're not using that feature, so Django moves on.

Loading 'initial_data' fixtures... No fixtures found.

Your initial database setup is now complete. The next time you run the syncdb command on this project (which you do any time you add an application or model), you see a bit less output because it doesn't need to set up any of those tables a second time or prompt you to create a superuser.

Find a programming school near you

Zip Code:

Subject: - Select All Subjects - Computer Applications Computer Engineering Computer Science Computer Prog. - Software Dev. Computer Game Programming Web Design Web Development Internet Systems Internet Certification Database Design and Development Information Systems Management Information Technology Project Management Network Design - Development Systems Analyst

Degree: - Select All Degrees - Associate's Bachelor's Master's Doctoral Certificates Diplomas Coursework MBA

Online Campus Both