Django Vanilla Views
Beautifully simple class-based views.
View --+------------------------- RedirectView | +-- GenericView -------+-- TemplateView | | | +-- FormView | +-- GenericModelView --+-- ListView | +-- DetailView | +-- CreateView | +-- UpdateView | +-- DeleteView
Django's generic class-based view implementation is unnecessarily complicated.
Django vanilla views gives you exactly the same functionality, in a vastly simplified, easier-to-use package, including:
- No mixin classes.
- No calls to
- A sane class hierarchy.
- A stripped down API.
- Simpler method implementations, with less magical behavior.
Remember, even though the API has been greatly simplified, everything you're able to do with Django's existing implementation is also supported in
django-vanilla-views. Although note that the package does not yet include the date based generic views.
If you believe you've found some behavior in Django's generic class-based views that can't also be trivially achieved in
django-vanilla-views, then please open a ticket, and we'll treat it as a bug. To review the full set of API differences between the two implementations, please see the migration guide for the base views, and the model views.
For further background, the original release announcement for
django-vanilla-views is available here. There are also slides to a talk 'Design by minimalism' which introduces
django-vanilla-views and was presented at the Django User Group, London. You can also view the Django class hierarchy for the same set of views that
django-vanilla-views provides, here.
Helping you to code smarter
Django Vanilla Views isn't just easier to use. I'd contest that because it presents fewer points of API to override, you'll also end up writing better, more maintainable code as a result. You'll be working from a smaller set of repeated patterns throughout your projects, and with a much more obvious flow control in your views.
As an example, a custom view implemented against Django's
CreateView class might typically look something like this:
from django.views.generic import CreateView class AccountCreateView(CreateView): model = Account def get_success_url(self): return self.object.account_activated_url() def get_form_class(self): if self.request.user.is_staff: return AdminAccountForm return AccountForm def get_form_kwargs(self): kwargs = super(AccountCreateView, self).get_form_kwargs() kwargs['owner'] = self.request.user return kwargs def form_valid(self, form): send_activation_email(self.request.user) return super(AccountCreateView, self).form_valid(form)
Writing the same code with
django-vanilla-views, you'd instead arrive at a simpler, more concise, and more direct style:
from vanilla import CreateView from django.http import HttpResponseRedirect class AccountCreateView(CreateView): model = Account def get_form(self, data=None, files=None, **kwargs): user = self.request.user if user.is_staff: return AdminAccountForm(data, files, owner=user, **kwargs) return AccountForm(data, files, owner=user, **kwargs) def form_valid(self, form): send_activation_email(self.request.user) account = form.save() return HttpResponseRedirect(account.account_activated_url())
- Django: 2.2, 3.0, 3.1, 3.2
- Python: 3.6, 3.7, 3.8, 3.9
Install using pip.
pip install django-vanilla-views
Import and use the views.
from vanilla import ListView, DetailView
from django.core.urlresolvers import reverse_lazy from example.notes.models import Note from vanilla import CreateView, DeleteView, ListView, UpdateView class ListNotes(ListView): model = Note class CreateNote(CreateView): model = Note success_url = reverse_lazy('list_notes') class EditNote(UpdateView): model = Note success_url = reverse_lazy('list_notes') class DeleteNote(DeleteView): model = Note success_url = reverse_lazy('list_notes')
Compare and contrast
To help give you an idea of the relative complexity of
django-vanilla-views against Django's existing implementations, let's compare the two.
Inheritance hierarchy, Vanilla style.
The inheritance hierarchy of the views in
django-vanilla-views is trivial, making it easy to figure out the control flow in the view.
CreateView --> GenericModelView --> View
Total number of source files: 1 (model_views.py)
Inheritance hierarchy, Django style.
Here's the corresponding inheritance hiearchy in Django's implementation of
+--> SingleObjectTemplateResponseMixin --> TemplateResponseMixin | CreateView --+ +--> ProcessFormView --> View | | +--> BaseCreateView --+ | +--> FormMixin ----------+ +--> ModelFormMixin --+ +--> ContextMixin +--> SingleObjectMixin --+
Calling hierarchy, Vanilla style.
Let's take a look at the calling hierarchy when making an HTTP
GET request to
CreateView.get() | +--> GenericModelView.get_form() | | | +--> GenericModelView.get_form_class() | +--> GenericModelView.get_context_data() | | | +--> GenericModelView.get_context_object_name() | +--> GenericModelView.render_to_response() | +--> GenericModelView.get_template_names()
Total number of code statements covered: ~40
Calling hierarchy, Django style.
Here's the equivalent calling hierarchy in Django's
BaseCreateView.get() | +--> ProcessFormView.get() | +--> ModelFormMixin.get_form_class() | | | +--> SingleObjectMixin.get_queryset() | +--> FormMixin.get_form() | | | +--> ModelFormMixin.get_form_kwargs() | | | | | +--> FormMixin.get_form_kwargs() | | | +--> FormMixin.get_prefix() | | | +--> FormMixin.get_initial() | +--> ModelFormMixin.get_context_data() | | | +--> SingleObjectMixin.get_context_object_name() | | | +--> SingleObjectMixin.get_context_data() | | | +--> SingleObjectMixin.get_context_object_name() | | | +--> ContextMixin.get_context_data() | +--> TemplateResponseMixin.render_to_response() | +--> SingleObjectTemplateResponseMixin.get_template_names() | +--> TemplateResponseMixin.get_template_names()
Total number of code statements covered: ~70
This repository includes an example project in the example directory.
You can run the example locally by following these steps:
git clone git://github.com/tomchristie/django-vanilla-views.git cd django-vanilla-views/example # Create a clean virtualenv environment and install Django virtualenv env source env/bin/activate pip install django # Ensure the local copy of the 'vanilla' package is on our path export PYTHONPATH=..:. # Run the project python ./manage.py migrate python ./manage.py runserver
Open a browser and navigate to
Once you've added a few notes you should see something like the following:
Copyright © Tom Christie.
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.