My Django form field validation and cleanup pain

July 6, 2015

Our Django based account request system has quite a number of (HTTP) forms that all reflect and manipulate the same underlying model data. Because these are different forms (and some of them are in complex dynamic situations), they of course all have different form (Python) classes. Some of you may already be seeing my problem here: a certain number of these fields need to be cleaned up and validated.

There are two problems here. The first is that in Django, form field validation and cleanup is attached to the form, not to the field. If you have five different forms all using the same field, that means five different forms need a clean_<field> method, even if all of these methods call the same code. The state of the code right now is actually that most of the forms do not have field cleanup and validation because they were restricted to administrative users and I was either overlooked the issue originally or was lazy. The second problem is that some of the forms want to generate somewhat different validation error messages for certain validation failures.

(Specifically, normal outside people submitting account requests need different error messages than staff who are basically doing data entry.)

I was going to say that Django doesn't support clean_<field> functions on models, but that's kind of incorrect. You don't get individual field methods, but you can clean and adjust data in an overall model clean() method. This deals with some but not all of my issues (eg the different error messages problem still remains) and it creates new ones; I'm essentially enforcing user interface restrictions at the database layer. I'm also not sure how happy Django will be if I do database lookups in a model clean() method.

(My view layer is actually deliberately more restrictive than the model layer right now. To put it one way, the view layer is concerned with saving people from errors while the model layer is concerned with hard data integrity constraints.)

All of this suggests that what I need to do is pull out most of the current .clean_<field> validation code into standalone functions and then find some easy way to add them to forms while handling error messages. Probably I will experiment with mixin classes that just have appropriate .clean_<field> methods.

(Now I wonder what happens if you have a .clean_<field> method for a field not defined in your form. Probably nothing good can come of that in the long run even if it works today in current Django.)

On the whole I wish that Django allowed you to attach form field cleanup logic directly to the field and then easily reuse field definitions between forms (right now this probably causes issues). Overall validation is part of the form, but individual field validation and cleanup really feels like it belongs to the field instead, and validation is already partly a field responsibility.

(Possibly you actually can hijack form field validators in order to also do cleanup, but if so I can't find any documentation on it so I'm not going to touch it.)


Comments on this page:

By Phillip at 2015-07-07 09:46:33:

Field.clean() exists and is documented, maybe this helps:

https://docs.djangoproject.com/en/1.8/ref/forms/validation/

Could you just a method like validate_all_teh_things and add it to the validators kwarg when you instantiate the form field? https://docs.djangoproject.com/en/1.8/ref/forms/validation/#validators (or similarly in the model field definition: https://docs.djangoproject.com/en/1.8/ref/validators/)

Oh, I see, you're interested in the clean methods, not the validators. You can subclass WhateverField and just override Field.clean: https://github.com/django/django/blob/1.8.2/django/forms/fields.py#L155 That API has been pretty stable as long as I've been using Django (since 1.4).

By cks at 2015-07-13 14:31:04:

Ah, that's a useful trick; thank you for letting me know about that, and pointing to the right bit of the code for the actual clean() calling convention (which wasn't clear from the docs I read). It's now quite tempting to do some field subclassing to create the custom fields I need; it would probably eliminate a bunch of code duplication and annoyances to have a single source of truth for what the form fields are supposed to be like.

Written on 06 July 2015.
« Sysadmin use of email is often necessarily more or less interrupt driven
The Git 'commit local changes and rebase' experience is a winning one »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jul 6 00:25:41 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.