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
-
Simple mixins
-
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
-
Simple generic views
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 = [ url(r'^view/$', MyView.as_view(size=42)), ]
Thread safety with view arguments
Arguments passed to a view are shared between every instance of a view. This means that you shouldn’t use a list, dictionary, or any other mutable object as an argument to a view. If you do and the shared object is modified, the actions of one user visiting your view could have an effect on subsequent users visiting the same view.
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.
Please login to continue.