This document discusses setting a baseline for Django projects by preventing repetitive code. It describes iterating on a book store project to add models, views, forms and authentication. It introduces the touchtechnology-public library which provides reusable model and form fields, widgets and mixins. It also addresses migrations by adding a SouthTripleMixin to custom fields to represent them as built-in fields for migrations.

1. Setting a baseline for
your Django projects
Gary Reynolds
Touch Technology
@goodtune
bitbucket.org/goodtune
github.com/goodtune

2. DRY principle
Django has loads of ways to prevent repetitive boilerplate
ModelForm
Class Based Views
django.contrib.admin
Then do I find myself writing code like this?

3. from django import forms
from .models import Book
BOOLEAN_CHOICES = ((1, 'Yes'), (0, 'No'))
class BookForm(forms.ModelForm):
for_sale = forms.ChoiceField(
choices=BOOLEAN_CHOICES)
class Meta:
model = Book

4. Iteration 0
Our example project is for a book store
Books will need to have
a title
a published date
are either for sale or not
We’ll start with an empty project

5. Iteration 1
Add our Book model
Add a front end view to output a list of books
Register the model with django.contrib.admin
Use south for schema migration

6. Iteration 2
Add the published date to the Book model
Add a view to edit our Book items in the front end

7. Better Form Fields
Default form fields for some model fields are a poor choice
BooleanField as a checkbox
DateField, TimeField, DateTimeField are all text fields
Depending on your project, there will be others
We can easily override these, build a library, and reuse
across all our applications to suit our preferences

8. touchtechnology-public
A backport of useful model & form fields, widgets, mixins,
etc that have evolved over the past 5 years
More coming soon, I’ve kept it light for this talk
Available to install from pypi, source is on bitbucket.org

9. Iteration 3
Change our model fields to implement our library
Without a single custom form defined in our project, our
form fields have now been flavoured to our taste
Add a view to create from the front end as well

10. Authentication
Do we really want just anyone editing our books?
from django.contrib.auth.decorators import login_required
from django.http import HttpResponseRedirect
from django.shortcuts import get_object_or_404
from django.template.response import TemplateResponse
@login_required
def book_edit(request, pk):
book = get_object_or_404(Book, pk=pk)
if request.method == 'POST':
form = BookForm(data=request.POST, instance=book)
if form.is_valid():
form.save()
return HttpResponseRedirect('..')
else:
form = BookForm(instance=book)
context = {'form': form, 'book': book}
return TemplateResponse(
request, 'example/book_form.html', context)

11. Iteration 4
Change our views to implement our library
Without any other changes to our project, our views have
now been protected from unauthenticated users

12. Migrations
When you use simple inheritance of built-in Django model
fields and South for migrations, you usually need to do some
extra work for each field
http://south.readthedocs.org/en/latest/tutorial/
part4.html#simple-inheritance
Oh no, that’s more boilerplate!

13. SouthTripleMixin
Add to your custom field’s inheritance structure when you
subclass a built-in Django field
We’re just altering the way we markup our field in forms,
not it’s database internal representation
Migrations will represent your field as the built-in field
This code is stand alone, you can copy it into any project

14. Questions?

15. Sample project and touchtechnology-public can be obtained
from bitbucket.org
bitbucket.org/touchtechnology/public
bitbucket.org/goodtune/sydjango-example
This presentation can be downloaded from SlideShare
slideshare.net/goodtune/setting-a-baseline-for-your-
django-projects