zoia.org

Some interesting examples on how to handle file uploads using Django:

• Code snippet posted on Djangosnippets. The file is saved by declaring a save() method in the form class. This method is invoked when calling form.save(), which is standard Django newforms practice. (Note that this snipped uses clean_data. As of Django version 0.96, clean_data has been renamed to cleaned_data, so you will have to change the code or it won’t work)
• Django image upload and validation. The author uses a model for the file and its related data. The uploaded file is saved by calling the save_FOO_file method. (This method is automatically provided by Django for fields declared as models.ImageField or models.FileField in the model. See the db-api documentation.)
• Django image upload, form_for_instance and monkey-patching. The example code creates a form class from request.user by calling form_for_instance. The resulting class in then monkey-patched to insert the avatar image validation code. (Although the code is interesting the monkey patch seems unnecessary. I wouldn’t mind inserting the avatar validation method in a UserProfileForm class derived from form.Forms. The code would be certainly clearer: I think KISS takes precedence over DRY in this case.)

Interesting, there seems to be no easy way of limiting the uploaded file size. The file can be rejected at validation time, but the data would have already been transfered.

A file upload recipe

After reading those posts, I think that a good recipe for handling file uploads in Django would be:

• Write a django model for the uploaded file and its related data. Using a Django model makes sense, because it is usually necessary for the application to keep track of the uploaded files.
• Write a subclass of form.Forms and declare a clean_FOO method for each models.FileInput or models.ImageInput fields declared in the model class. These clean_FOO methods are used to validate the uploaded files.
• use a django view to receive the POST data, or display the form if no data is posted or errors are found.
• validate the uploaded file or files by triggering the standard django newforms validation mechanism: is_valid().
• save the file or files getting the data directly from the request.FILES object, by writing a save() method for the subclassed form or by calling save_FOO_file for the model instance.

A simpler way to upload a file

The following short Django example uses no data models, does no data validation, and saves the file directly to disk using python standard file functions. It is just a simple test I wrote to get familiar with the request.FILES object. This is not production code: it could be used to execute an arbitrary script on the server.
The directory where the file is to be saved must be writable by the user that is running the Django server script. (The example uses MEDIA_ROOT as defined in settings.py.)

file: views.py

from django import http from django import newforms as forms from django.shortcuts import render_to_response from djangotest.settings import MEDIA_ROOT     class SimpleFileForm(forms.Form): file = forms.Field(widget=forms.FileInput, required=False)     def directupload(request): """ Saves the file directly from the request object. Disclaimer: This is code is just an example, and should not be used on a real website. It does not validate file uploaded: it could be used to execute an arbitrary script on the server. """   template = 'fileupload.html'   if request['method'] == 'POST': if 'file' in request.FILES: file = request.FILES['file']   # Other data on the request.FILES dictionary: # filesize = len(file['content'])<br /> # filetype = file['content-type']   filename = file['filename']   fd = open('%s/%s' % (MEDIA_ROOT, filename), 'wb') fd.write(file['content']) fd.close()   return http.HttpResponseRedirect(' upload_success.html') else: # display the form form = SimpleFileForm() return render_to_response(template, { 'form': form })  

file: fileupload.html

{% extends "base.html" %}   {% block body %} <h1>Upload a file</h1> <form action="." method="post" enctype="multipart/form-data"> {{ form }} <input type="submit" value="Upload" /> </form> {% endblock %}

The Django newforms documentation has been updated some days ago. It includes an explanation on how to use form_for_models and form_for_instance and provides some examples.

More interesting, however, is when not to use them: “If you want to create a form whose fields map to more than one model, or a form that contains fields that aren’t on a model, you shouldn’t use these shortcuts.”

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:

# models.py Models for django blog application from django.db import models   class Tag(models.Model): tag = models.CharField(maxlength=50)   class Author(models.Model): name = models.CharField(maxlength=100) email = models.EmailField()   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)   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 })

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.

[Read the rest of this entry...]