Django

Django is a FLOSS (Free/Libre Open Source Software) web application framework written in Python.

Make the easy things easy and the hard things possible.
      — unknown

Basics

This section gathers basic information about Django.

Why Django?

Why would one be choosing Django? Below is a rough outline of why people favour Django:

• language choice: Python is a very clean, highly expressive language.
• batteries included philosophy: Django works out of the box with a minimum of fuss.
• reusable applications: there are lots of them and they are easy to build.
• clear industry-complying development practises plus Django has its own best practises
• alive and kicking ecosystem: many excellent tools, tight and flawless integration with other software products e.g. MongoDB.
• great documentation: although not perfect, there is a lot of officially provided documentation, and it is well written and clear.
• API stability: backwards compatibility is big with Django. This is a strong selling point for larger/enterprise customers.
• big and active community: this also includes a vibrant community of plugin, API and tool developers and testers.
• professional support and consultancy available from many independent individuals and businesses.
• proven track record: Django is on the road a long time already and has continuously been used for simple as well as complex use cases as well as small and big setups.

Zope2 vs Django

Can what happened to Zope2 happen to Django too? Sure, if we ever forget/ignore one plain fact:

Regardless of how smart, creative, and innovative your
organization/project/community is, there are more smart, creative, and
innovative people outside your organization/project/community than inside.

We must make things generic enough so Django bits and pieces work for any Python project. That is true the other way around too — we must use ready-made Python bits and pieces and not cook our own soup from scratch if not absolutely necessary. If we do not, Django will become another Zope2, die and be forgotten rather sooner than later.

Python 3

There is no certain date. There are several porting efforts whereas this one seems to be the most advanced and serious one. One milestone will be dropping Python 2.4 support which is scheduled for Django 1.4.

Update: We might actually see Python 3 support in late summer 2011 already. Hooray!

Frameworks atop Django

There are several content management systems like Django CMS or FeinCMS. Then there is Satchmo and Banjo for example. Aside from those well-known and well-established ones, there are more — please go here or use some Internet search engine to get an idea about the current situation yourself.

Core Principles and Design Philosophies

Yes, we have them. We have core Python principles too of course. Those are important things to understand, especially if we are planning on contributing to Django.

Speedup Django

Folks love super-snappy web applications therefore we shall give them what they want. Firstly, starting with the most obvious one, also creating the least effort — we get better hardware i.e. we might use a RAID array and lots of RAM (Random Access Memory), all spiced up with some crazy-horse server CPU setup. Secondly, after we threw bigger hardware at our snail-problem, we start caching. Thirdly, if all that is still not enough, we hire additional staff in order to set up a world-class clustered Django + MongoDB setup.

Building Blocks

Any Django project has four of them — models (the data tier), views (the logic tier), URL-patterns (maps URLs to particular code parts/sections within the logic tier) and templates (the presentation tier).

Django on the Filesystem

Well, if installed using aptitude install python-django, then it goes where all other Django related .debs go:

sa@wks:~$ type dpl; dpl python-djan* | grep ii
dpl is aliased to `dpkg -l'
ii  python-django                        1.1.1-1                        High-level Python web development framework
ii  python-django-doc                    1.1.1-1                        High-level Python web development framework
ii  python-django-extensions             0.4+git200905112140-2          Useful extensions for Django projects
sa@wks:~$ ll /usr/share/pyshared/ | grep django
drwxr-xr-x 16 root root 4.0K 2009-11-04 07:15 django
drwxr-xr-x 11 root root 4.0K 2009-11-12 21:39 django_extensions
-rw-r--r--  1 root root  775 2009-05-16 01:04 django_extensions-0.4.egg-info

We can see the layout on the filesystem using a nifty alias from my ~/.bashrc which makes use of tree:

sa@wks:~$ type ta; ta -L 2 /usr/share/pyshared/django
ta is aliased to `tree -a -I \.git*\|*\.\~*\|*\.pyc'
/usr/share/pyshared/django
|-- __init__.py
|-- conf
|   |-- __init__.py
|   |-- app_template
|   |-- global_settings.py
|   |-- locale
|   |-- project_template
|   `-- urls
|-- contrib
|   |-- admin
|   |-- admindocs
|   |-- auth
|   |-- comments
|   |-- contenttypes
|   |-- csrf
|   |-- databrowse
|   |-- flatpages


[skipping a lot of lines...]


|   |-- tree.py
|   |-- tzinfo.py
|   |-- version.py
|   `-- xmlutils.py
`-- views
    |-- debug.py
    |-- decorators
    |-- defaults.py
    |-- generic
    |-- i18n.py
    `-- static.py

51 directories, 87 files
sa@wks:~$

Note that the layout on the filesystem reflects how we import Python code i.e. an import statement of from django.core.urlresolvers import resolve would import the function resolve from /usr/share/pyshared/django/core/urlresolvers.py:

sa@wks:~$ grep -A2 "^def resolve" /usr/share/pyshared/django/core/urlresolvers.py
def resolve(path, urlconf=None):
    return get_resolver(urlconf).resolve(path)

sa@wks:~$

Size

How big is Django in terms of diskspace needed to install it? dlocate can tell us:

sa@wks:~$ dlocate -du python-django | grep total
16624   total
sa@wks:~$ date -u
Sun Nov 29 11:18:50 UTC 2009
sa@wks:~$

Around 16.6 MiB these days (November 2009).

django.contrib

It is a large suite of non-core Django functionality i.e. the part of the Django codebase that contains various useful add-ons to the core framework. Go here for more information.

GIS

So, can we use Django to create a GIS (Geographic Information System)? The answer is yes! For example, there is GeoDjango which is based on PostGIS — http://djangopeople.net for example makes use of GeoDjango. PostGIS puts a number of spatial datatypes into PostgreSQL, and GeoDjango builds onto that. Go here for more information about Django's storage options.

We can think of django.contrib as Django's equivalent of the Python standard library — optional, de facto implementations of common patterns. They are bundled with Django so that we do not have to reinvent the wheel in our own applications.

The admin site for example is one part of django.contrib. Technically, it is called django.contrib.admin. Other available features in django.contrib include a user authentication system (django.contrib.auth), support for anonymous sessions (django.contrib.sessions) and even a system for user comments (django.contrib.comments). There are many more... For now, just know that Django ships with many useful add-ons, and django.contrib is generally where they live.

Container

The term container is, as of now (November 2010), not part of the official terminology used within the Django community — some use it, many do not. However, I think it is very helpful in approaching and understanding other basic concepts and conventions which are, in fact, official Django concepts/practices and therefore part of the official and everyday Django parlance.

Now, let us take one step back and look at the big picture... Many people, especially when new to Django, ask the most basic questions:

• what are the best practises as well as core principles and design philosophies?
• what is the best workflow and which are the common tools used?
• what does the filesystem layout for a Django project look like?

The first two are discussed on other sections/pages on this website but the last one is where we drill down now... first thing we come across is... you guessed it, containers! However, before we start drilling down on what does the filesystem layout for a Django project look like, let us go over a view basic things:

Outer Container, Inner Containers

The major guidelines are similar to any other code project. Django applications should address a single, clearly-defined responsibility. The name application is actually a misnomer — Django applications should be thought of more as reusable components which can be plugged together in order to create a web application.

So what we end up with is containers — one outer container (Python/Django project) containing one or more inner containers (Django applications).

The entire outer container e.g. a Django project then makes up for a web application which caters to a particular domain object. The point being that a container, whether outer or inner one, groups together what semantically/logically belongs together.

For example, we might have a web application which domain object is a social networking site (think mini-Facebook). From a technical point of view this web application might be made of a Django project which contains a bunch of Django applications (e.g. email, photo sharing, friends, file storage, etc.) which together make up for this social networking site — or shall we say web application with domain object social networking site ;-]

Anyhow, those would all just be directories on the filesystem, the outer container being the Django project container, grouping together all the application containers (subdirectories) which in turn group together task specific things e.g. the Django application email would contain all source code related to sending and receiving email.

Below is how it would look like on the filesystem, one root directory (outer container) with a bunch of subdirectories i.e. one outer container and one or more inner containers (ta is just an alias from my ~/.bashrc):

sa@sub:/tmp$ pwd; type ta; ta mini-facebook.com/
/tmp
ta is aliased to `tree    --charset ascii -a        -I \.git*\|*\.\~*\|*\.pyc'
mini-facebook.com/
|-- email
|-- file_storage
|-- friends
`-- photo_sharing

sa@sub:/tmp$

Inner Containers also known as Django Applications

We already know that, from a technical point of view, Django applications as well as Django projects, both are just Python packages. Tests for each Django application should be contained within that particular Django application — Django applications should be decoupled from each other as much as possible so they become reusable, but clearly there will be dependencies, so the goal should be to keep the dependency graph as simple and lightweight as possible.

It is recommended to keep all the templates for a Django project under a single project-wide template directory and/or within subdirectories for each application (using a template subdirectory for each application is a very strong convention in Django, as it avoids template name collisions between applications). The reason for a single project-wide templates directory is that templates, template inheritance trees, and block names can be quite project-specific, so it is hard to provide default application templates that can plug into any Django project.

So what is the takeaway here? Well, the takeaway is that as inner containers (Django projects), very much like outer containers, group together what semantically/logically belongs together e.g. a Django application becomes reusable only if it ships with its own templates, tests, models, views, etc.

Next, extending on the example from above, we are now showing the most basic filesystem layout for a web application build as a Django-based project (outer container) with a bunch of Django applications (inner containers) e.g. email.

 1  sa@wks:/tmp$ ta mini-facebook.com/
 2  mini-facebook.com/
 3  |-- email
 4  |   |-- models.py
 5  |   |-- templates
 6  |   |-- tests
 7  |   `-- views.py
 8  |-- file_storage
 9  |   |-- models.py
10  |   |-- templates
11  |   |-- tests
12  |   `-- views.py
13
14
15  [skipping a lot of lines...]
16
17
18  |-- models.py
19  |-- settings.py
20  |-- templates
21  |-- tests
22  `-- views.py
23
24  sa@wks:/tmp$

As we can see, we have project specific/wide (line 20) as well as application specific parts (lines 5 and 10). As mentioned before, we make this distinction so Django applications become reusable across Django projects.

Bottom Line

Now, with all the knowledge about containers and naming conventions we backup a bit by saying that all this is more like a recommendation rather than set in stone requirements:

sys.path, INSTALLED_APPS

Basically, a Python/Django project is just an outer container for our source code that makes up for whatever web applications we are creating, with whatever its domain object may be. However, this structuring into one outer and several inner containers really is just a recommendation to make things easy to work with. The fact of the matter is that our source code can live anywhere on the filesystem as long as the Python interpreter is able to find and import it. In addition, what needs to be the case is that every Django application that is used in a Django project is added INSTALLED_APPS Python variable in settings.py.

Outer/Inner Container Philosophy

Some people find that using terms such as container, Python/Django project as well as Django application is bad. I would respectfully disagree with that point of view as I do find them to be coherent concepts. For example, Python/Django projects are what we generally work on, after all, that is the deliverable. So we have a directory (outer container) where we keep all stuff that semantically/logically belongs to this one web application — a bunch of files and/or subdirectories (inner containers) e.g. our Django application(s), static content, templates, settings, root URLconf, oftentimes a few one-off project-specific applications, etc. We put it all under version control and call it the project.

Even with those terms and recommendations/conventions, the key thing to realize is that there is nothing magic about a certain directory or directory structure, we can arrange things however it suits our workflow and make it work.

Projects vs Application vs Site

Understanding the distinction Django draws between a project, an application and a site is mandatory for anybody who wants to do good code layout on the filesystem, write portable software, and most importantly create scalable and long-term maintainable web applications using Django.

It is also worth mentioning that a Django project is not the same as a Python project — the difference is that a Django project is actually what we call package in Python i.e. a Django project lives inside (is a subdirectory of) a Python project.

Project:

This is the directory that contains all the applications belonging to a particular Django project — in Python terminology this directory is called a Python package which can easily be told by the fact that it contains a __init__.py file. The applications share a common run-time invocation and can refer to each other. In other words:

A project is a collection of applications, installed into the same database, and all using the same settings file (settings.py). In a sense, the defining aspect of a project is that it supplies a settings file which specifies the database to use, the applications to install, and other bits of configuration.

A project may correspond to a single website, but does not have to — multiple projects can run on the same site. The project is also responsible for the root URL configuration, though in most cases it is useful to just have that consist of calls to include which pull in URL configurations from inidividual applications.

Application:

This is a set of views, models, and templates — again, this is also a package in Python terminology. Applications are often designed so they can be plugged into another project. In other words:

An application tries to provide a single, relatively self-contained set of related functions — it is a Python package so of course it is self-contained. An application is allowed to define a set of models (though it does not have to) and to define and register custom template tags and filters (though, again, it does not have to).

Site:

We can designate different behavior for an application based on the site (read URL) being visited. This way, the same application can customize itself based on whether or not the user has visited example-bar.com or example-foo.com, even though it is the same codebase that is handling the incoming HTTP request to Django.

How we arrange these is really up to our project. In a complicated case, we might do:

Project: ExampleProject
    App: Web Version
        Site: example-foo.com
        Site: example-bar.com
    App: XML API Version
        Site: example-foo.com
        Site: example-bar.com
    Common non-app settings, libraries, auth, etc

Or, for a simpler project that wants to use one of the many available FLOSS (Free/Libre Open Source Software) add-ons:

Project: ExampleProject
    App: Example
        (No specific use of the sites feature... it's just one site)
    App: Plug-in TinyMCE editor with image upload
        (No specific use of the sites feature)

Views, custom manipulators, custom context processors and most other things Django lets us create can all be defined either at the project level or the application level. Generally, though, they are best placed inside an application (this increases their portability across projects).

Aside from the fact that there needs to be a project, and at least one application, the arrangement is very flexible — we can design the filesystem layout to adapt whatever suits us best to help abstract and manage the complexity (or simplicity) of our deployment.

Admin Site

Django provides us with an automatic admin interface also known as admin site. Django does so by reading metadata from our models which it then uses to provide a powerful and production-ready interface that content producers can immediately use to start adding/deleting/altering content to/from/at their website.

Some common examples where having an admin site might be useful are:

• an interface we use to post to our blog
• the backend site managers use to moderate user-generated comments
• the tool our clients use to update the press releases on their website which we built for them
• photos a real estate agent uploads for a house he would like to sell
• etc.

Note that the admin site is entirely optional because only certain types of websites need this functionality. It is disabled per default i.e. we need to take a few steps in order to activate an admin site. Usually that means we need to touch our projects settings.py, synchronize with the database (thereby creating a superuser) and last but not least, add and entry for the admin site to urls.py.

Admin Site from a technical Point of View

A Django admin site is represented by an instance of the class AdminSite found at django.contrib.admin.sites.AdminSite. By default, an instance of this class is created as django.contrib.admin.site and we can register our models and ModelAdmin instances with it.

If we would like to set up our own admin site with custom behavior, however, we are free to subclass AdminSite and override or add anything we like. Then, simply create an instance of our AdminSite subclass (the same way we would instantiate any other Python class), and register our models and ModelAdmin subclasses with it instead of using the default (django.contrib.admin.sites.AdminSite).

What if I forget/loose my Password used to enter the Admin Site?

If it is a remote machine located within some datacenter for example, we might use SSH (Secure Shell). If it is locally we do not need that of course. However, what is needed in both cases is for us to create a new superuser account which can then be used to log in and alter/reset the password for the original superuser or delete the original superuser account altogether and use the new one from now on. The command used is createsuperuser:

sa@wks:~/0/django/mysite$ ./manage.py help createsuperuser
Usage: manage.py createsuperuser [options]

Used to create a superuser.

Options:
  -v VERBOSITY, --verbosity=VERBOSITY
                        Verbosity level; 0=minimal output, 1=normal output,
                        2=all output
  --settings=SETTINGS   The Python path to a settings module, e.g.
                        "myproject.settings.main". If this isn't provided, the
                        DJANGO_SETTINGS_MODULE environment variable will be
                        used.
  --pythonpath=PYTHONPATH
                        A directory to add to the Python path, e.g.
                        "/home/djangoprojects/myproject".
  --traceback           Print traceback on exception
  --username=USERNAME   Specifies the username for the superuser.
  --email=EMAIL         Specifies the email address for the superuser.
  --noinput             Tells Django to NOT prompt the user for input of any
                        kind. You must use --username and --email with
                        --noinput, and superusers created with --noinput will
                        not be able to log in until they're given a valid
                        password.
  --version             show program's version number and exit
  -h, --help            show this help message and exit
sa@wks:~/0/django/mysite$

Concepts

We now know about the basics. Next we are going to take a first glance at what it means to develop Django-based web applications. After this subsection we will be familiar with all core concepts in Django.

Settings, Variables

This one is about connecting the dots — where are things located on the filesystem and how do they make their way down the pipe to the users web browser that is.

In order to discuss this topic, we need to know about a few terms (environment/Python variables actually). Below is how the stack would look like for a Python/Django project:

Django            # introduces MEDIA_ROOT, MEDIA_URL, STATIC_ROOT, STATIC_URL, STATICFILES_DIRS
Python            # introduces PROJECT_ROOT
Operating System  # introduces WORKON_HOME

As we can see, since the stack grows bottom to top, a Django project would use/have all of the environment/Python variables. A Python project would only have WORKON_HOME and PROJECT_ROOT.

Container Roots

• WORKON_HOME and
• PROJECT_ROOT

Those three tell us about the container roots (as in Unix filesystem root) of our virtual environments as well as Django projects. Three things to note here:

1. we call them container roots because they are a) directories which are b) below the actual filesystem root (/)
2. they might point to the same directory but usually they do not
3. we might have two (WORKON_HOME, PROJECT_ROOT) in case we have a Django project or we might even just have one (WORKON_HOME) in case we do a non-Django project i.e. we set up a virtual environment for some Python project.

Static Content

Now, assuming that we have a Django project, we also need to know about

• MEDIA_ROOT and MEDIA_URL
• STATIC_ROOT, STATIC_URL and STATICFILES_DIRS.

The latter three are part of the puzzle in case we are using django-staticfiles which we do automatically these days (November 2010) because it went into Django with version 1.3. Generally, when discussing where things are located on the filesystem, there are three main areas of concern:

1. Static content e.g. CSS, javascript, images, videos, etc — note that static content was/is often called media in common Django parlance. Starting with Django 1.3 we make a further distinctions in whether or not we are talking about user generated static content (MEDIA_ROOT and MEDIA_URL) or whether we are talking about non-user generated static content that is part of our Django project (STATIC_ROOT, STATIC_URL and STATICFILES_DIRS) e.g. CSS.
2. Templates i.e. the parts of our project responsible for presenting information to the user.
3. Internationalization i.e. what makes our project available in multiple languages (i18n) and takes into account differences in how, for example, dates and numbers are displayed across different cultures and countries (l10n).

Filesystem Location/Layout

After the introduction from above, we can now have a closer look at those particular environment/Python variables.

PROJECT_ROOT

MEDIA_ROOT, MEDIA_URL

• http://docs.djangoproject.com/en/dev/ref/settings/#media-url
• http://docs.djangoproject.com/en/dev/ref/settings/#media-root

STATIC_ROOT, STATIC_URL, STATICFILES_DIRS

• http://bitbucket.org/jezdez/django-staticfiles/src/
• http://pinaxproject.com/docs/dev/settings.html#staticfiles-dirs

Models

In short: A model is the software layer (code to store/retrieve/alter/etc.) atop the data and the data itself.

Django has the notion of so called models with regards to its approach towards MVC (Model-View-Controller) respectively MTV (Model Template View) as it is called with Django.

Models are used to execute SQL code behind the scenes and return convenient Python data structures representing the rows in our database tables.

A Django model is a description of the data inside the database, represented as Python code. It is our data layout i.e. the equivalent of our SQL CREATE TABLE statements except it is in Python instead of SQL (Structured Query Language), and, in addition of describing data inside a database, it includes additional functionality.

Models are also used to represent higher-level concepts that SQL cannot handle like for example functionality for a particular model. In other words: A Django model not just describes the database table layout for an object but it also describes any functionality an object knows about itself.

Let us take __unicode__() for example — it is one example of such functionality — which is used so a model knows how to display itself.

While __unicode__() is a so called model method, there are also model meta options — yet another higher-level concept SQL cannot provide us with. Managers are yet another higher-level concept a model provides us with.

Relationship Database-table / Python Objects

A model class represents a database table, and an instance of that class represents a particular record in the database table.

Field

An attribute on a model — think of a model as a Python class and of fields as its class attributes. A given field usually maps directly to a single database column.

Model Metadata, Model Meta Options

Model metadata is anything that is not a field such as the use of class Meta, model methods and manager methods.

Meta options are used within class Meta blocks for ordering options, database table name, or human-readable singular and plural names.

No model metadata is required, and adding it to a model is completely optional.

Model Methods

We can add methods to a model in order to get custom row-level functionality (i.e. per single instance of a model instance/object) for our objects. Model methods act on object instances whereas manager methods on the other hand are intended to do table-wide things.

Adding model methods to a model is a valuable technique for keeping business logic in one place — the model itself that is.

Manager

A model's manager is a Python object through which Django models perform database queries i.e. an interface for database queries in Django. Each model object/instance has at least one manager object (named objects per default) attached to it, and we can also create additional custom managers in order to customize database access.

Any database look up follows the general pattern of calling methods on the manager(s) attached to the model we want to query against.

A manager is used any time we want to look up model instances i.e. managers take care of all table-level operations on data including, most importantly, data lookup.

Model Methods vs. Custom Managers

Managers are accessible only via model classes, rather than from model instances, to enforce a separation between table-level operations and record-level operations.

Adding extra model manager methods is the preferred way to add table-level functionality to our models i.e. functions that act on all instances of a models instances/objects. For row-level functionality i.e. functions that act on a single instance of a model instance/object, using model methods is the way to go.

Queryset

A queryset represents a collection of objects from our database(s) returned by a query. It can have filters i.e. criteria that narrow down the collection of objects based on given parameters.

In SQL terms, a queryset equates to a SELECT statement, and a filter is a limiting clause such as WHERE or LIMIT.

A queryset is an object itself. It is constructed via a Manager on some model class. For example if we had a model called Car, we could get a queryset like this a_query_set_representing_all_cars = Car.objects.all(). objects is the models default manager. all() is a method on the manager, returning a queryset which itself yields all instances of the class Car.

As can be seen, querysets in its simplest form provide us with an easy and efficient way to execute all kinds of queries on our data. Using filters makes things a lot more versatile and easy — in 9 out of 10 cases, that is all we ever need. However, if filters are still not enough to get the job done, querysets provide us with the ability of using so called F or Q objects.

Note that lookup functions (such as all(), get(), filter(), etc.) can mix the use of Q objects and keyword arguments. All arguments provided to a lookup function (be they keyword arguments or Q objects) are ANDed (logical AND) together. However, if a Q object is provided, it must precede the definition of any keyword arguments.

Querysets can be cached, effectively boosting application speed when used correctly i.e. the database(s) are only queried once if asked for the same queryset more than once.

One-to-One? Many-to-One/Foreign Key? Many-to-Many?

We use models to store/retrieve/alter information. However, there is not just information inside each model, but also in the relationships amongst them...

The whole is more than the sum of its parts.
      — Aristotle (384 BC - 322 BC)

One-to-One, Many-to-One (also known as foreign key) and Many-to-Many are principles describing relationships amongst models.

Generic Foreign Key, Generic Relation

Please go here for more information.

blank=True, null=True

Both are model field options. They are optional. Django uses default values of False for both of them.

blank=False is different than null=False. null is purely database-related, whereas blank is validation-related. If a field has blank=True, validation on Django's admin site will allow entry of an empty value. If a field has blank=False, the field will be required. Let us look at an example where we have the following model (Author) which lives inside a books application:

class Author(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=40)
    email = models.EmailField()

Every author has a first name and a last name but not necessarily an E-mail address. The above model however requires us to provide an E-mail address to every author. We can make it so that providing an E-mail address becomes optional if we use email = models.EmailField(blank=True) instead. That is terrific. What is it with null=True though?

null=True means that Django will store empty values as NULL in the database. So, how is that important to us one might ask?

Well, SQL has its own way of specifying blank values — a special value called NULL. NULL could mean unknown, or invalid, or some other application-specific meaning. In SQL, a value of NULL is different to an empty string, just as the special Python object None is different than an empty Python string (""). This means it is possible for a particular character field (e.g. a SQL VARCHAR column) to contain both NULL values and empty string values. This can cause unwanted ambiguity and confusion like for example

• Why does this record have a NULL but this other one has an empty string? Is there a difference, or was the data just entered inconsistently?
• How do I get all the records that have a blank value — should I look for both NULL records and empty strings, or do I only select the ones with empty strings?

To help avoid such ambiguity, Django's automatically generated CREATE TABLE statements add an explicit NOT NULL to each SQL column definition. For example, the generated statement for our Author model from above:

CREATE TABLE "books_author" (
    "id" serial NOT NULL PRIMARY KEY,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(40) NOT NULL,
    "email" varchar(75) NOT NULL
)

Excellent! We have all SQL columns set to NOT NULL whether they actually contain data or not i.e. an empty string when leaving fields blank because we used blank=True. Problem solved? Well, no. Here is why: Some database column types simply do not accept empty strings as valid values. Examples are dates, times and numbers. If we try to insert an empty string into a SQL date or SQL integer column, we will likely get a database error, depending on which database we use — PostgreSQL, which is strict, will raise an exception here. MySQL might accept it or might not, depending on the version we are using. In other words: Every time we deal with dates, times and numbers, NULL is the only way to specify an empty value.

When both need be used...

In Django models, we can specify that a database column SQL NULL is allowed by adding null=True to a model field. If we want to allow blank values in a date field (e.g. DateField, TimeField, DateTimeField) or numeric field (e.g. IntegerField, DecimalField, FloatField), we will need to use both null=True and blank=True.

We change our Author model to allow a blank author_added_to_database timestamp using the DateTimeField:

class Author(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=40)
    email = models.EmailField(blank=True)
    author_added_to_database = models.DateTimeField(blank=True, null=True)

Adding null=True is more complicated than adding blank=True, because null=True changes the semantics of the database i.e. it changes the CREATE TABLE statement to remove the default NOT NULL from the author_added_to_database field:

CREATE TABLE "books_author" (
    "id" serial NOT NULL PRIMARY KEY,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(40) NOT NULL,
    "email" varchar(75) NOT NULL
    "author_added_to_database" timestamp with time zone
)

App Label

WRITEME

Shortcut

We already know that, by using Django, we deal with a web framework adhering to the MVC (Model-View-Controller) principle. Usually that means we have to take care of three things (the model (read data), the logic (read application) and the presentation (read CSS, HTML, JavaScript, etc.) in order to show something to the user on the Internet.

Not so with shortcuts — those basically allow us to span multiple MVC layers e.g. grab an HttpRequest object and use the render_to_response function with it — that is, we do not need to process a request as usual i.e. using some view function to carry out some logic, to load a template and to fill in a context and finally return a HttpResponse object with the result of the rendered template. Instead, we just return an HttpResponse object right away, providing a particular template and an optional context to render_to_response.

Template

A template is used to give structure to our user-facing part of the web application. It is a simple text file used to generate any text-based output format e.g. HTML, XML, etc. The output of templates together with CSS makes for the so-called look and feel of our web application i.e. the way it appears to the user.

Both, structure and presentation, live within the presentation tier of our web application — rather than within the data (models) or logic (views) tier.

Nodes

Internally, a Django template is represented as a collection of nodes. Nodes are Python classes which all inherit from the base node class django.template.Node.

Nodes can do various sorts of processing, but they have one thing in common: every Node must have a method called render() which accepts as its second argument (the first argument, of course, will be the node instance itself) an instance of django.template.Context class, which is a dictionary-like object containing all the variables which are accessible to the template.

The render() method of a node must return a string, but if the node is meant to carry out some task other than output something (for example, if it is meant to modify the template context by adding, removing or modifying variables in the context instance passed to it) it can return an empty string. However, usually the return value of the template's render() method is a non-empty string. This string is the concatenation of the return values of the render() methods of all the template's constituent nodes, called in the order in which they occur in the template.

Context

A context is a variable name to variable value mapping that is passed to a template. The data structure used for this mapping is a Python dictionary, mapping template variable names (dictionary keys) to Python objects (dictionary values).

A template then renders a context by replacing the variable holes with values from the context and executing all block tags.

Context Processor

WRITEME

URLconf

It is a Python module called URLconf containing mappings between URL (Uniform Resource Locator) patterns (regular expressions) and views i.e. it decouples URLs from Python code (the logic-tier in Django also known as views; see MTV).

Note that these mappings do not search GET and POST parameters, or the domain name. For example, in a request to http://www.example.com/myapp/, the URLconf module will look for myapp/. In a request to http://www.example.com/myapp/?page=3, the URLconf module will look for myapp/.

Forms

A form is a collection of fields that knows how to validate itself and display itself as HTML. Django has a dedicated form library which allows us to do a bunch of things:

• Display an HTML (Hypertext Markup Language) form with automatically generated form widgets.
• Check submitted data against a set of validation rules.
• Redisplay a form in the case of validation errors.
• Convert submitted form data to the relevant Python data types.

The library is decoupled from other Django components, such as the database layer, views and templates. It relies only on Django settings, a couple of django.utilities helper functions and Django's internationalization hooks (we are not required to be using internationalization features to use this library i.e. their usage is optional).

bound, unbound

The distinction between bound and unbound forms is important. An unbound form instance does not have any data associated with it i.e. when rendered to the user, it will be empty or will contain default values. Of course, because it has no data associated with it, there is nothing to validate!

A bound form instance does have submitted data associated with it (from a POST), and hence can be used to tell if that data is valid (see is_valid() from ../django/forms/forms.py). If an invalid bound form is rendered it can include inline error messages telling the user where they went wrong.

ModelForm

If our form is going to be used to directly add or edit a Django model, we can use a ModelForm to avoid duplicating our model description.

Views

A view has to be a callable. It usually is a Python callback function that does something (or not as in def i_am_a_view: pass) — in practice, of course, it should do something: Each view has is responsible for doing one of two things

1. Returning an HttpResponse object containing the content for the requested page, or
2. raising an exception such as Http404.

The rest is up to us i.e. our view can (or not) read/write from/to a database. It can (or not) use a template system, either Django's built-in template system or a third-party template system. A view might also generate a PDF file, output XML, create a ZIP file on the fly, anything we want, using whatever Python libraries we want, there is no built-in limitation to what a view can do except, Django either demands a HttpResponse or an exception.

Generic Views

First we need to know that, with Django, the MVC principle is called MTV (Model Template View) — same thing, different names/approaches. A view in Django actually represent the controller/logic i.e. the Python/C/JavaScript/etc. code needed to grab some data from the database, do something with it, and pass the result the template machinery in order to send back a HTTP response to the user.

A generic view is no different except it is a higher-order view that provides an abstract/generic implementation of a common idiom or pattern found in view development i.e. a generic view is a ready-made view we can use without the need to write a view ourselves. In other words: Django provides us with a bunch of views for common/recurring cases so we do not have to code them over and over again.

The two most popular generic views are ListView and DetailView. Those two views abstract the concepts of display a list of objects and display a detail page for a particular type of object.

Middleware

WRITEME

Sessions

WRITEME

Extensions

We have tons of them. In Django parlance those extensions are called Django applications.

First let us clarify on the matter: There is core Django and then there are hundreds if not thousands of additional extensions, written by third parties, that can be used to extend Django's functionality and/or change its core behavior somehow.

Note that code that makes up our Django project (code that builds on Django and creates some added value which ultimately ends in being an individual project i.e. what users visit using their web browser) is not necessarily what we call a Django extension.

Only if code which builds upon Django (or portions of it) can be reused in other Django projects as well do we recognize it as an extension. All the rest that cannot be reused is considered code that makes our project unique.

Of course, every project ultimately has some portions of code that either cannot be reused or of which reusing does not make any sense. The point here is, the more code can be reused outside our project, the better it is. Into that... Pinax is an effort towards the goal of maximizing code reuse and thus minimizing repeating tasks and code redundancy. This is a core principle called DRY (Don't repeat yourself) which, for good reasons, is very prominent amongst Python/Django developers.

To answer the question about available extensions: There are so many and changes often happen frequently that listing them here does not make any sense. The right place to look for extensions is the PyPI (Python Project Index), where extensions can be shared and explained with/to others.

Create Django Extensions

In Django parlance those extensions are called Django applications. Here is information about how to build and maintain Django reusable apps.

Inlines

Please go here.

Preparing

We now know about all the basic concepts of Django and all the parts that resemble a Django-based web application, we are now going to have a look at a few basic guidelines which are considered best practice and should thus be followed.

Best Practices

Depends. Here are a bunch of links with different angles on different things:

• http://docs.djangoproject.com/en/dev/misc/design-philosophies/
• http://docs.djangoproject.com/en/dev/internals/contributing/
• http://github.com/ericholscher/django-reusable-app-docs, use ./manage.py create_app --template=/path/to/app_template found in django-extensions
• http://github.com/lincolnloop/django-best-practices
• http://lucumr.pocoo.org/2010/12/24/common-mistakes-as-web-developer/

Programming

We now know what it takes to create a Django-based web application. This subsection is about tools and procedures which help us boost productivity, ease the overall process of software development, and last but not least, help us make sure that our web application is fast/efficient and has the lowest bug-count possible.

Utilities, Helpers

django-extensions

• http://github.com/django-extensions/django-extensions/blob/master/docs/installation_instructions.rst
• http://ericholscher.com/blog/2008/sep/12/screencast-django-command-extensions/
• http://wiki.github.com/django-extensions/django-extensions/current-command-extensions

Database Model Extensions

• TimeStampedModel: An abstract base class model that provides self-managed created and modified fields.
• TitleSlugDescriptionModel: An abstract base class model that has a title (CharField), slug (AutoSlugField) and a description (TextField) field.

sa@wks:/usr/share/pyshared/django_extensions/db$ grep 'models.Model' models.py
class TimeStampedModel(models.Model):
class TitleSlugDescriptionModel(models.Model):
class ActivatorModel(models.Model):
sa@wks:/usr/share/pyshared/django_extensions/db$

Database Model Field Extensions

• http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.prepopulated_fields
• http://docs.djangoproject.com/en/dev/ref/models/fields/#slugfield

sa@wks:/usr/share/pyshared/django_extensions/db/fields$ grep 'class ' __init__.py
class AutoSlugField(SlugField):
class CreationDateTimeField(DateTimeField):
class ModificationDateTimeField(CreationDateTimeField):
class UUIDVersionError(Exception):
class UUIDField(CharField):
sa@wks:/usr/share/pyshared/django_extensions/db/fields$

Current Admin Extensions

• ForeignKeyAutocompleteAdmin: will enable the admin application to show ForeignKey (also known as Many-To-One) fields with an search input field. The search field is rendered by the ForeignKeySearchInput form widget and uses jQuery to do configureable autocompletion.

Miscellaneous Notes

• We’d highly recommend using filter_horizontal for any ManyToManyField that has more than 10 items. It’s far easier to use than a simple multiple-select widget. Also, note you can use filter_horizontal for multiple fields — just specify each name in the tuple.
• filter_horizontal and filter_vertical only work on ManyToManyField fields, not ForeignKey fields.
• http://www.djangobook.com/en/2.0/chapter06
• http://docs.djangoproject.com/en/dev/ref/contrib/admin
• http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/

Examples

sa@wks:~/0/django/mysite$ ./manage.py show_urls | column -t | grep -v /admin
/rosetta/                                rosetta.views.home                               rosetta-home
/rosetta/pick/                           rosetta.views.list_languages                     rosetta-pick-file
/rosetta/download/                       rosetta.views.download_file                      rosetta-download-file
/rosetta/select/<langid>/<idx>/          rosetta.views.lang_sel                           rosetta-language-selection
sa@wks:~/0/django/mysite$

django-boss

• http://blog.zacharyvoase.com/2009/12/09/django-boss/

Testing

• http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/
• http://toastdriven.com/blog/2011/apr/17/guide-to-testing-in-django-2/
• http://docs.djangoproject.com/en/dev/topics/testing/
• http://docs.djangoproject.com/en/dev/topics/testing/#the-test-database
• http://docs.python.org/3.1/library/unittest.html
• http://docs.python.org/3.1/library/unittest.html#organizing-test-code
• http://dougalmatthews.com/articles/2010/jan/20/testing-your-first-django-app/
• http://ludios.org/ivank/2010/10/testing-your-eq-ne-cmp/
• https://github.com/has207/flexmock

  Tests that require a database (namely, model tests) will not use your "real" (production) database. A separate, blank database is created for the tests. Regardless of whether the tests pass or fail, the test database is destroyed when all the tests have been executed.

• python -Wall manage.py test
  • https://docs.djangoproject.com/en/dev/topics/testing/

Fixtures

• http://docs.djangoproject.com/en/dev/topics/testing/#fixture-loading
• http://docs.djangoproject.com/en/dev/ref/django-admin/#djadmin-loaddata
• A test fixture represents the preparation needed to perform one or more tests, and any associate cleanup actions. This may involve, for example, creating temporary or proxy databases, directories, or starting a server process.

Checker

• http://chris-lamb.co.uk/projects/django-lint/

Profiling

• http://www.agmweb.ca/blog/andy/2247/
  • http://github.com/andymckay/django-query-analyzer
• http://packages.python.org/django-extensions/runprofileserver.html

Monitoring

This subsection is about knowing what is going on with our setup i.e. if it is healthy or not, if we need to add more servers to cope with growth etc.

Using Ganglia

• http://en.wikipedia.org/wiki/Ganglia_%28software%29
• http://ganglia.info/
• http://www.ibm.com/developerworks/wikis/display/WikiPtype/ganglia
• https://github.com/ganglia

Nginx

• http://wiki.nginx.org/NginxHttpStubStatusModule
• https://github.com/csakatoku/ganglia-pymodule_nginx_status
• wget http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py

Security

• http://www.djangobook.com/en/beta/chapter20
• http://de.wikipedia.org/wiki/Cross-Site_Scripting
  • ... always escape any content that might have come from a user e.g. <h1>Hello, {{ name|escape }}!</h1>
• http://en.wikipedia.org/wiki/Cross-site_request_forgery
  • Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
  • https://docs.djangoproject.com/en/dev/ref/contrib/csrf/

Django

• http://bitbucket.org/rudolph/django-monitoring
• https://github.com/dcramer/django-sentry
  • http://dcramer.github.com/django-sentry/

MongoDB

• https://github.com/ganglia/gmond_python_modules/tree/master/mongodb/
• https://github.com/quiiver/mongodb-ganglia

Money

This subsection is about money when it is shoot back and forth as ones and zeros across wires, stored onto non-volatile memory and processed by random computing devices.

Electronic Commerce

WRITEME

• http://github.com/hbussell/pinax-satchmo-buildout
• http://www.satchmoproject.com/blog/2010/aug/01/satchmo-virtualenv/
• http://bitbucket.org/bkroeze/django-bursar/overview/
• http://github.com/hbussell/social-commerce-project
  • http://www.hbussell.com/2010/02/12/pinax-loves-satchmo/

PyCheddar

• https://cheddargetter.com/
• http://www.feedmagnet.com/blog/cheddargetter-for-python-and-django/
• http://github.com/jasford/pycheddar

Scaling

This subsection is about scaling our Django-based web application i.e. how we architecture it (the entire stack i.e. presentation tier, logic tier and data tier) so we can keep up with a growing number of requests and a growing data set.

A scalable system should not need to undergo fundamental changes in
its architecture when the size of the problem changes.
      — Mike Malone

Introduction to Scaling

We can scale in two dimensions, each one being mutually exclusive within a single tier, but possible to combine across tiers:

1. Vertically is when the entire stack runs on a single machine or if it is split up and its tiers are spread across two or three machines, each machine being responsible for a particular tier e.g. one machine runs the data tier and another one runs the logic and presentation tier. With this setup it is possible to swap a slow/small server with a faster/bigger one. However, the problem is that at some point even the fastest/biggest server out there might become to slow/small in order to handle all requests and/or store the growing data set.
2. Horizontally is when we have potentially many servers in each tier e.g. we run our data tier on n (one or more) cheap commodity shared nothing servers rather than a single big and expensive machine. Same for our logic tier, we run it on n cheap commodity shared nothing servers as well. Last but not least, the presentation tier... if it is not run side by side on the same servers powering the logic tier, then it also runs on a bunch of n cheap commodity shared nothing servers.

As indicated already, even if the above examples assume that we choose one approach for the entire stack, note that we can mix both approaches e.g. the data tier might be designed to scale horizontally whereas the logic tier within the same stack might be designed to scale vertically. So, what is better, scaling horizontally or scaling vertically?

Vertically is better if we have plenty of financial resources right from the start so we can afford to buy big machines and the service contracts that go with them but if we are limited in time (as in TTM (Time to Market) for example) and human resources/knowledge to architecture, implement and maintain a horizontally scalable solution.

The downside with the vertical approach however is that it has a practically relevant upper boundary, which, when reached, will make it impossible to grown any further (i.e. if the already fastest/biggest machine can not handle our requests and/or data set anymore). However, as already mentioned, until we arrive at this upper boundary, the good thing about the vertical approach is that the entire development and maintenance cycle stays the same (read easy/low) at all times.

Anyhow, considering that the whole idea of scaling is to not have a practically relevant upper boundary, the vertical approach seems wrong to even begin with — I would even go as far as to say that scaling vertically is a contradiction in itself as we certainly cannot achieve what we can achieve with the horizontal approach which allows us to practically scale infinitely.

Note the usage of the word practically here. It basically determines that we can manage to stay below the upper boundary which we can define as the currently technically possible.

Both, our current needs in terms of how much requests we need to handle and/or the size of the data set we need to store, as well as what is currently considered the currently technically possible upper boundary in software and hardware, they are both moving targets. As long as we manage to keep our needs for speed and size below that technically possible upper boundary, its fair to say that we can practically scale infinitely. That is something which is simply not possible with the vertical approach where it is not unusual that the need for speed and size surpasses the upper boundary for what is the currently technically possible (see example where the already fastest/biggest server becomes to slow/small).

So, assuming there is enough time and human resources as well as just about enough money to start with a setup of commodity hardware at our disposal, scaling horizontally is certainly what everybody should opt for — even if we had enough money from the very beginning to afford expensive hardware, it is probably smarter in the long run to invest in people rather than hardware, license fees and service contracts.

Everything is possible, as usual it all depends on the use case at hand, the problems we need to solve, the domain object, the available time frame, and things like TCO (Total Cost of Ownership) and RoI (Return on Investment), switching costs and if the vendor lock-in is bearable, as well as things which are rather hard to quantify such as how to buildup assets, sustain/gain competitor ship and, most importantly, have fun at what we do.

Load Balancing

Distribute incoming requests across many machines...

WRITEME

Caching

Not every incoming request should hit the data tier...

WRITEME

Messaging

Prioritize tasks. What can wait and should be handled asynchronously (maybe even by another machine)?

WRITEME

Storage

Scaling the data tier horizontally means distributing the data set as well as load across many servers and not loose data (i.e. also have it replicated).

WRITEME

Advanced Concepts

This subsection is considered to be an advanced section i.e. functionality, concepts and tasks which we usually do not need in small to mid-sized web applications and/or features respectively use cases which are not considered to be mainstream so far.

Single Sign On

• http://en.wikipedia.org/wiki/Single_sign-on

CAS

• http://en.wikipedia.org/wiki/Central_Authentication_Service
• http://www.jasig.org/cas
• http://code.google.com/p/django-cas/

Shibboleth

• http://en.wikipedia.org/wiki/Shibboleth_%28Internet2%29
• https://github.com/harbulot/foafsslshib

Miscellaneous

federation, login across several domains

• http://www.janrain.com/products/federate
• http://en.wikipedia.org/wiki/Federation_%28information_technology%29
  • http://en.wikipedia.org/wiki/Federated_identity

OpenID

• http://openid.netk
• http://en.wikipedia.org/wiki/Openid
• http://en.wikipedia.org/wiki/Federated_identity
• http://code.djangoproject.com/wiki/DjangoResources#Djangoapplicationcomponents

Web Hooks

• That is a bit like http://en.wikipedia.org/wiki/Comet_%28programming%29
• http://github.com/ask/durian

Generic Relations

• http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/#id1
• http://www.caktusgroup.com/blog/2010/03/11/decoupled-django-apps-and-the-beauty-of-generic-relations/
• /ws/python_web.html#content_bridge
• /ws/python_web.html#core_concept_idea_functionality

Email Framework

Deployment

With this subsection we are going to look at how to deploy Django-based web application and how to apply changes/upgrades once they are deployed.

WRITEME

Django CMS

The level of flexibility that can be achieved with the Django CMS 2.0
is unlike any other CMS platform. In a climate of evolving needs,
this platform provides a refreshing reminder that simplicity
drives creativity. When your platform augments your skills
instead of channeling them into its environment, both the
client and the developer win.
      — Comfy Chair

FAQs

This section gathers FAQs about Django CMS.

What are the mptt, publisher and cms Python packages?

If we take a look at the source code from current HEAD, we can see the directories example, cms, mptt and publisher.

• example contains an example project we might use as a starting point for custom projects or to simply experiment with and therefore familiarize ourselves with Django CMS.
• MPTT (Modified Preorder Tree Traversal) is used by Django CMS and many others to gain the notion/functionality of models structured in a tree-like structure.
• cms contains pretty much what makes up for Django CMS itself i.e. the source code of Django CMS.
• Last but not least, publisher has the source code that allows for functionality like for example create content but not immediately publish it to the Internet where anybody can see it i.e. content can remain in draft state being worked on, be scheduled for review by a moderator and things like that.

Development

• http://github.com/digi604/django-cms-2.0/tree/master/cms/docs

Configuration

• http://github.com/digi604/django-cms-2.0/blob/master/cms/docs/configuration.txt
• ../cms/conf/global_settings.py
• ../example/settings.py

Quickstart

WRITEME

Just some rough notes so far....

1. http://github.com/digi604/django-cms-2.0/blob/master/cms/docs/tutorial.txt
2. It appears to me that although we do have an installation guide many folks stumble when trying to get started with django-cms. Therefore, until I have the time to write a proper quickstart tutorial, here are the basic steps in order to install and setup django-cms:

• We use GIT to clone from the repository onto our local machine git clone git://github.com/digi604/django-cms-2.0.git
• then setup virtualenv
• use add2virtualenv to add cms, mptt and publisher to pythons module search path
• change into ../example
• switch settings.py from mysql to sqlite i.e. DATABASE_ENGINE = 'sqlite3'
• name the database e.g. DATABASE_NAME = 'example.db'

• run python manage.py syncdb --all
• issue python manage.py migrate --fake followed by
• python manage.py runserv
• visit http://localhost:8000 and start your django-cms experience :-)
• alter ../example/templates/index.html and ../example/templates/cms/menu.html
• work on CSS in ../example/templates/index.html as you see fit

Required Debian packages:

• build-essential
• python-setuptools
• python-dev
• python-pip
• python-virtualenv
• python-imaging
• libjpeg-dev
• python-ncrypt
• git-core
• virtualenvwrapper

Miscellaneous Info or stuff to install/setup:

• south/django-evolution and django-reversion are both optional
• pip install and set up django-extensions real quick
• pip install pil
• pip install django
• when using sqlite3, comment south in settings.py

Plugins

For information about developing a plugin, please go here.

YouTube

• http://www.django-cms.org/en/extensions/cmsplugin-youtube/detail/
• http://bitbucket.org/xenofox/cmsplugin-youtube/

Photologue

• http://www.django-cms.org/en/extensions/cmsplugin-photologue/detail/
• http://bitbucket.org/tehfink/cmsplugin-photologue/wiki/Home
• http://bitbucket.org/justhamade/cmsplugin-photologue/overview/

FAQ

• http://www.django-cms.org/en/extensions/cmsplugin-faq/detail/
• http://bitbucket.org/tehfink/cmsplugin-faq/

News

• http://www.django-cms.org/en/extensions/cmsplugin_news/detail/
• http://groups.google.com/group/django-cms/browse_thread/thread/70510598bed8197a?hl=en
• http://bitbucket.org/MrOxiMoron/cmsplugin-news/overview/

Comments

• http://bitbucket.org/limpbrains/cmsplugin_comments/overview/

Search

• http://www.django-cms.org/en/extensions/simple-search-plugin/detail/
• http://github.com/rtpm/cmsplugin_search

Contact

• http://www.django-cms.org/en/extensions/simple-contact-form-plugin/detail/
• http://github.com/rtpm/cmsplugin_contact

Image-Filer

• http://www.django-cms.org/en/extensions/image-filer/detail/
• http://github.com/stefanfoulis/django-image-filer

Form-Designer

• http://www.django-cms.org/en/extensions/form-designer/detail/
• http://github.com/philomat/django-form-designer

Plugin Development

• http://wiki.github.com/digi604/django-cms-2.0/plugin-examples