Today I'll start a series of entries on django class based generic views. It seems the documentation is somewhat lacking, so I hope these posts helps clarify its use.
The new generic classes are formed by aggregation of multiple mixins. A mixin is just a class intended to add functionality to another by subclassing it. Sometimes a mixin can't even live by itself, it needs some piece of behavior provided by another base class, or by the derived class.
This diagram show the relationships among the different mixins:
The ready to use classes are the ones at the bottom.
First, lets recall the standard form processing cycle:
Examining the code, the obvious thing to abstract first is the paths for get and post.
This is precisely what ProcessFormView does:
You can see that there are lots of different methods that need to be implemented for this mixin to work. This is done on several others, like FormMixin and ModelFormMixin, which we'll examine later.
Ok, let's begin by creating an object.
The simplest possible use case is this:
1) An automatically generated ModelForm
2) No extra context needed in the template
3) No initial data passed to the form constructor
In this case, this code will suffice:
the template 'app/mymodel/detail.html' could be something like this:
Finally, the relevant urls.py section: