DjangoCon 2011 – Advanced Django Form Usage

An experience talk from Daniel Greenfeld and Miguel Araujo

Django forms are really powerful but there are edge cases that can cause a bit of anguish. This talk will go over how to handle many common solutions not currently described in the core documentation. It will also cover some useful third-party libraries and will end with clarifications about what the state of form features will be in Django 1.4.

Updates below:

15.10

Talk wrapped up, will post slides once they’re available.

15.02

Question: “How to you advocate testing when unittests seem to only cover the django aspect”

Answer: “Testing isn’t science, having tests for the django side of forms is better than nothing”

14.58

Question Time…

14.57

@pydanny and @maraujop wrapping up here. Great technical talk at DjangoCon.

14.56

Ticket #27 – Single form field for multiple database fields. Interesting to look at, but probably won’t be fixed.

14.55

HTML5 tickets

  • Ticket #16304
  • Ticket #16630
  • Django doesn’t handle HTML5
  • Suggestion to use django-floppyforms if you want HTML5

14.54

Problems with Custom Widget Output

  • Oldest ticket #23 is related to forms
  • ComboField is broken
  • Validators are thought to validate simple values because of the way run_validators is coded

14.53

Problems with Custom Widget Output

  • Overriding render means indepth knowledge
  • Hard to do custom output with built-in widgets
  • You can’t call super.render and cusomize it easily
  • Templates? Open Ticket #15667

14.51

MultiValue, MultiWidget Fields: Needs a compress() and validate()

14.48

Sorry for everyone following along, they’re showing lots of code and going really quickly so I can’t type it out – Adam

14.47

Adding your own FormField isn’t DRY (need clean() in everything, lots of duplicated code)

14.44

Django1.4 refactoring

  • Form rendering will use templates instead of HTML in Python
  • Template based widgets

14.42

django-uni-form handles layout and django-floppyforms handle the input

14.38

django-uni-form allows you to have Fieldsets (in python code) and buttons.

14.34

Instead of duplicating ModelForm field definitions use def __init__(self): to override specific fields (like required=True)

14.32

When testing make sure you test POSTing a form and not just GETing.

14.31

Better way for doing ModelForm

mymodel = get_object_or_404(MyModel, slug=slug)
form = MyModelForm(request.POST or None, instanc=mymodel)
if form.is_valid():
    mymodel = form.save()
    mymodel.stuff = other_stuff
    mymodel.save()
 
return render(request, template_name, {'form':form, 'mymodel': mymodel})

14.28

According to @pydanny statistics

  • 91% of all Django projects use ModelForms
  • 80% of ModelForms require trivial logic
  • 20% of ModelForms require complex logic

14.28

A more sane way of doing forms

form = MyForm(request.POST or None, request.FILES or None)
if form.is_valid():
    do_x()
    return redirect('home')
 
return render(request, template_name, {'form': form}

14.25

Forms should be easier.

  • Smaller, cleaner code
  • Follow line 5 of Zen of Python
  • Less is more

14.25

@pydanny and @maraujop have taken the stage talking about Advanced Form Usage.

Also read...