Most of the examples I have found on the web about replacing the default Django newforms widgets use hard coded values for the list of choices the widget displays. But those hard coded examples fall short when the widgets are bounded to many-to-many fields or to foreign keys in the model class. That is, when the list of choices is generated dynamically at run time, read from a database table.

The solution is obvious simple: fetch the dictionary of choices from the original widget, and use it as a parameter for your new custom widget.

It sounds simple, and it is. But it took me some time to figure out how to do it. The Django newforms lilbrary documentation is still work in progress, at least at the time of this writing. I could not found where the original widgets were stored in the Form instance. Thankfully, Django is an open source project, and Python has an interactive shell mode. Inspection of the source code and regression tests, and some playing with the Python shell is really an enlightening process. Anyway, I am posting this on the blog for further reference. I also include a working example of a sample Django blogging application I wrote for testing: pretty basic, but it and ilustrates, among other things, the use of custom widgets with dynamic choices.

Maybe the explanaition is “over-verbose”… suggestions accepted.

Don’t hit the database twice

Consider the following model class:

</p>

<h1>models.py Models for django blog application</h1>

<p>from django.db import models</p>

<p>class Tag(models.Model):
    tag = models.CharField(maxlength=50)</p>

<p>class Author(models.Model):
    name = models.CharField(maxlength=100)
    email = models.EmailField()</p>

<p>class Article(models.Model):
        (...)
    author = models.ForeignKey(Author)
    tags = models.ManyToManyField(Tag)

The standard method for displaying a form for the model class in a webpage is to subclass forms.Form, create an instance of the subclass and return the rendered the template. Examples of this can be found on the Django website and on the web.

Django newforms provides two methods that simplify the subclassing of forms.Form: form_for_instance and form_for_model. Both methods return a new class: a subclass of Form, more precisely, tuned to your model class or model instance. If you have a model class or model instance with a many-to-many relationship, and you don’t mind displaying the relationship as a listbox on the webpage, then these two methods will take care of querying the database, building the list of options and feeding it to SelectField or a SelectMultipleField widget.

          #  ArticleForm is a subclass of form.Form
          ArticleForm = forms.models.form_for_model(Article)
The next step is to create an instance of ArticleForm, and return the rendered tempalte:

        form = ArticleForm()
        return render_to_response('post.html', { 'form': form })

I don’t like lists for multiple option selection, at least not in webpages. I prefer checkboxes. It takes some CSS tweaking to render them correctly and evenly spaced on the webpage, but it greatly enhances the user experience.

The class generated by form_for_model (and by form_for_instance) stores the widgets in a variable named base_fields (a dictionary). This makes it simple to replace any of the default widgets with any other widget, provided it makes sense to do so. For example, the following code replaces the author and tags widgets with a RadioSelect widget and a CheckboxSelectMultiple widget:

        ArticleForm.base_fields['tags'].widget = CheckboxSelectMultiple(choices= ... )
        ArticleForm.base_fields['author'].widget = RadioSelect(choices= ... )

The only thing left is to provide the list of choices that both CheckboxSelectMultiple and RadioSelect constructors expect as one of their parameters. One way to build such lists is to query the database and fetch the entries for the Tag and Author classes. Something like tagChoices = Tag.objects.all() and authorChoices = Author.objects.all(). Convert the resulting queryset to a dictionary and use it as a parameter to the RadioSelect widget constructor.

But this is querying the database twice and for the same data each time the form is displayed on the webpage: once for the original SelectMultiple widget, and then again for the custom widget. And it would be a shame to have your name on such code… Obviously, this can be avoided by retrieving the list of choices from the original SelectMultiple widget and using it as the list of choices for our custom widget:

        ArticleForm = forms.models.form_for_model(Article)</p>

<pre><code>    ArticleForm.base_fields['tags'].widget = CheckboxSelectMultiple(
            choices=ArticleForm.base_fields['tags'].choices) 

    ArticleForm.base_fields['author'].widget = RadioSelect(
            choices=ArticleForm.base_fields['author'].choices)

    form = ArticleForm()
    return render_to_response('post.html', { 'form': form })
</code></pre>

<p>

That’s it. The Author SelectField gets replaced by radio buttons, and the Tag MultipleSelectField by some nice checkboxes. The database gets hit only once. Nothing to be ashamed of.

A complete example

Updated 2007-5-5: added editpost.html, which was not included by mistake.

The following is a test blog application I wrote. It uses form_for_instance and form_for_model to define the proper subclass of form, then replaces the standard widgets with custom ones. The widgets load the Author and Tags choices dynamically. In addition, creation and edition of the blog posts are handled by the same method. A regular expression in urls.py converts web page names to slugs as registered in the database, so permalinks are effectively implemented.

This blogging app is really basic: the Django admin interface is needed to add new tags and authors; no authentication; post slugs have to be hand created; no plugins; etc. But deactivate the edit line in urls.py, use css to pump up the desigh, edit your posts using the admin interface, and you have a Django-powered miniblog you can start customizing. Maybe pass the form with the article content to another method, before rendering the template, and write some plugins to pre-process the content prior to show it on the webpage.

Some screenshots of the Django mini-blog

This is pretty spartan. Throw in some CSS if you like.

Django Blog, main page

Django blog, edit post

template file: ./base.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd>
<html xmlns="http://www.w3.org/1999/xhtml"></p>

<p><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></p>

<p><title>{% block pagetitle %}Page title{% endblock %}</title></p>

<p><link rel="stylesheet" href="" type="text/css" media="screen" />
{% block head %}</p>

<p>{% endblock %}</p>

<p></head>
<body>
{% block body %}</p>

<p>{% endblock %}
</body>
</html>

template file: ./blog/index.html

{% extends "base.html" %}</p>

<p>{% block title %}
    A minimal blog, powered by Django
{% endblock %}</p>

<p>{% block body %}</p>

<h2>Hello, world!</h2>

<ul>
<li><a href="./add">Write new post</a></li>
</ul>

<p>{% for post in posts %}</p>

<div class="post">
    <h2><a href="./{{ post.slug }}.html" title="{{ post.title }}">
        {{ post.title }}</a></h2>
    <div class="postmeta">
        <div class="postdate">{{ post.pub_date }}</div>
        <div class="posttags">
        Tags: 
        {% for tag in post.tags.all %}
            {{ tag.tag }},
        {% endfor %}
        </div>
        <div class="postauthor">
            By {{ post.author }}.
        </div>
    </div><!-- end postmeta -->
    <a href="./edit/{{ post.id }}">Edit post</a>
    <div class="postcontent">
    {{ post.content }}
    </div>
</div>

<p>{% endfor %}
{% endblock %}

template file: ./blog/editpost.html

{% extends "base.html" %}</p>

<p>{% block title %}
        Add post
{% endblock %}</p>

<p>{% block body %}</p>

<h2>Write a post</h2>

<form method="POST" action=".">
        {{ form.as_p }}

        <input type="submit" value="submit" />
</form>

<p>{% endblock %}

models.py

</p>

<h1>Models for django blog application</h1>

<p>from django.db import models</p>

<p>class Tag(models.Model):
    tag = models.CharField(maxlength=50)  # tagname</p>

<pre><code>def __str__(self):
    return self.tag

class Admin:
    pass
</code></pre>

<p>class Author(models.Model):
    name = models.CharField(maxlength=100)
    email = models.EmailField()</p>

<pre><code>def __str__(self):
    return self.name

class Admin:
    pass
</code></pre>

<p>class Article(models.Model):
    title = models.CharField(maxlength=250)
    slug = models.CharField(maxlength=250)
    content = models.TextField()
    author = models.ForeignKey(Author)
    pub_date = models.DateTimeField('date published')
    mod_date = models.DateTimeField('date modified')
    tags = models.ManyToManyField(Tag)</p>

<pre><code>def __str__(self):
    return self.title

class Admin:
    pass
</code></pre>

<p>

url.py

</p>

<h1>-<em>- coding: utf-8 -</em>-</h1>

<p>from django.conf.urls.defaults import *</p>

<p>urlpatterns = patterns('',
    # Example:
    # (r'^djangotest/', include('djangotest.foo.urls')),
&nbsp;
    (r'^blog/$', 'djangotest.blog.views.index'),
&nbsp;
    #  regex for slugs.  Note that the regex matches even 
    #  .html without slug:  this gets handled in views.single
    (r'^blog/(?P&lt;slug&gt;((\w+|-)*))(&#46;html)\/?$', 'djangotest.blog.views.single'),
&nbsp;
    # edit post
    (r'^blog/edit/(?P&lt;post_id&gt;\d+)/$', 'djangotest.blog.views.edit'),<br />
&nbsp;
    # add new post
    (r'^blog/add/$', 'djangotest.blog.views.edit'),
&nbsp;
    # Uncomment this for admin:
    (r'^admin/', include('django.contrib.admin.urls')),
)

views.py

</p>

<h1>-<em>- coding: utf-8 -</em>-</h1>

<h1>views.py</h1>

<p>from django.http import HttpResponse, HttpResponseRedirect
from django.template import Context, loader
from django.shortcuts import render_to_response, get_list_or_404</p>

<p>from django import newforms as forms
from django.newforms.widgets import *</p>

<p>from djangotest.blog.models import *</p>

<p>def index(request):
    """ Display last 5 articles """
    # TODO:  make '5' not a magic number
    last_five = Article.objects.all().order_by('-pub_date')[:5]</p>

<pre><code>t = loader.get_template('blog/index.html')
c = Context({
    'posts' : last_five,
})

return HttpResponse(t.render(c))
</code></pre>

<p>def single(request, slug):
    # handle page not found
    articles = get_list_or_404(Article, slug__exact=slug)
    return render_to_response('blog/index.html', { 'posts':articles })</p>

<p>def edit(request, post_id=None):</p>

<pre><code>if post_id is None:
    # no id, user is creating new post
    ArticleForm = forms.models.form_for_model(Article)
else:
    # editing or updating post
    try:
        article = Article.objects.get(id=post_id)
    except Article.DoesNotExist:
        HttpResponseRedirect('blog/postdoesnotexist.html')

    ArticleForm = forms.models.form_for_instance(article)

# we need to feed the new widget with the choices from the 
    # default one:  SelectMultiple

ArticleForm.base_fields['tags'].widget = CheckboxSelectMultiple(
    choices=ArticleForm.base_fields['tags'].choices)
ArticleForm.base_fields['author'].widget = RadioSelect(
    choices=ArticleForm.base_fields['author'].choices)

if request.method == 'POST':
    # form has been submited (i.e., new post or old post update)
    form = ArticleForm(request.POST)
    if form.is_valid():
        form.save()
        return HttpResponseRedirect('/blog')

else:
    # empty form
    form = ArticleForm()

return render_to_response('blog/editpost.html', { 'form': form })
</code></pre>

<p>

References

    The following pages were of great help in understanding the newforms library better:
  • The Django documentation for newforms. (Still work in progress.)
  • Some examples of using a select field with static choices and hidden fields: Big nerd ranch. (qué tal nombre…)
  • How to render dynamic forms using Django newforms. From the author’s blog: the newforms library works only for static forms. Forms that have a fixed number of fields. What I wanted to do, is create a page that allows you to edit multiple instances of a model at once.. Uses Javascript, no AJAX.
  • How to use the model specified defaults as the default values for fields, and how to make the help_text entries available in the fields for rendering.