Built-in class-based views API

Class-based views API reference. For introductory material, see the Class-based views topic guide.

• Base views
  • View
  • TemplateView
  • RedirectView
• Generic display views
  • DetailView
  • ListView
• Generic editing views
  • FormView
  • CreateView
  • UpdateView
  • DeleteView
• Generic date views
  • ArchiveIndexView
  • YearArchiveView
  • MonthArchiveView
  • WeekArchiveView
  • DayArchiveView
  • TodayArchiveView
  • DateDetailView
• Class-based views mixins
  • Simple mixins
    • ContextMixin
    • TemplateResponseMixin
  • Single object mixins
    • SingleObjectMixin
    • SingleObjectTemplateResponseMixin
  • Multiple object mixins
    • MultipleObjectMixin
    • MultipleObjectTemplateResponseMixin
  • Editing mixins
    • FormMixin
    • ModelFormMixin
    • ProcessFormView
    • DeletionMixin
  • Date-based mixins
    • YearMixin
    • MonthMixin
    • DayMixin
    • WeekMixin
    • DateMixin
    • BaseDateListView
• Class-based generic views - flattened index
  • Simple generic views
    • View
    • TemplateView
    • RedirectView
  • Detail Views
    • DetailView
  • List Views
    • ListView
  • Editing views
    • FormView
    • CreateView
    • UpdateView
    • DeleteView
  • Date-based views
    • ArchiveIndexView
    • YearArchiveView
    • MonthArchiveView
    • WeekArchiveView
    • DayArchiveView
    • TodayArchiveView
    • DateDetailView

Specification

Each request served by a class-based view has an independent state; therefore, it is safe to store state variables on the instance (i.e., self.foo = 3 is a thread-safe operation).

A class-based view is deployed into a URL pattern using the as_view() classmethod:

urlpatterns = [
    path('view/', MyView.as_view(size=42)),
]

Arguments passed into as_view() will be assigned onto the instance that is used to service a request. Using the previous example, this means that every request on MyView is able to use self.size. Arguments must correspond to attributes that already exist on the class (return True on a hasattr check).

Base vs Generic views

Base class-based views can be thought of as parent views, which can be used by themselves or inherited from. They may not provide all the capabilities required for projects, in which case there are Mixins which extend what base views can do.

Django’s generic views are built off of those base views, and were developed as a shortcut for common usage patterns such as displaying the details of an object. They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself.

Most generic views require the queryset key, which is a QuerySet instance; see Making queries for more information about QuerySet objects.