The following three classes provide much of the functionality needed to create Django views. You may think of them 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 and Generic class-based views.
Many of Django’s built-in class-based views inherit from other class-based views or various mixins. Because this inheritance chain is very important, the ancestor classes are documented under the section title of Ancestors (MRO). MRO is an acronym for Method Resolution Order.
The base view class. All other class-based views inherit from this base class. It isn’t strictly a generic view and thus can also be imported from
from django.http import HttpResponse from django.views import View class MyView(View): def get(self, request, *args, **kwargs): return HttpResponse('Hello, World!')
from django.urls import path from myapp.views import MyView urlpatterns = [ path('mine/', MyView.as_view(), name='my-view'), ]
The list of HTTP method names that this view will accept.
['get', 'post', 'put', 'patch', 'delete', 'head', 'options', 'trace']
Returns a callable view that takes a request and returns a response:
response = MyView.as_view()(request)
The returned view has
When the view is called during the request/response cycle, the
setup()method assigns the
HttpRequestto the view’s
requestattribute, and any positional and/or keyword arguments captured from the URL pattern to the
kwargsattributes, respectively. Then
Viewsubclass defines asynchronous (
async def) method handlers,
as_view()will mark the returned callable as a coroutine function. An
ImproperlyConfiguredexception will be raised if both asynchronous (
async def) and synchronous (
def) handlers are defined on a single view-class.Changed in Django 4.1:
Compatibility with asynchronous (
async def) method handlers was added.
setup(request, *args, **kwargs)¶
Performs key view initialization prior to
If overriding this method, you must call
dispatch(request, *args, **kwargs)¶
viewpart of the view – the method that accepts a
requestargument plus arguments, and returns an HTTP response.
The default implementation will inspect the HTTP method and attempt to delegate to a method that matches the HTTP method; a
GETwill be delegated to
post(), and so on.
By default, a
HEADrequest will be delegated to
get(). If you need to handle
HEADrequests in a different way than
GET, you can override the
head()method. See Supporting other HTTP methods for an example.
http_method_not_allowed(request, *args, **kwargs)¶
If the view was called with an HTTP method it doesn’t support, this method is called instead.
The default implementation returns
HttpResponseNotAllowedwith a list of allowed methods in plain text.
options(request, *args, **kwargs)¶
Handles responding to requests for the OPTIONS HTTP verb. Returns a response with the
Allowheader containing a list of the view’s allowed HTTP method names.
If the other HTTP methods handlers on the class are asynchronous (
async def) then the response will be wrapped in a coroutine function for use with
await.Changed in Django 4.1:
Compatibility with classes defining asynchronous (
async def) method handlers was added.
Renders a given template, with the context containing parameters captured in the URL.
This view inherits methods and attributes from the following views:
from django.views.generic.base import TemplateView from articles.models import Article class HomePageView(TemplateView): template_name = "home.html" def get_context_data(self, **kwargs): context = super().get_context_data(**kwargs) context['latest_articles'] = Article.objects.all()[:5] return context
from django.urls import path from myapp.views import HomePageView urlpatterns = [ path('', HomePageView.as_view(), name='home'), ]
Redirects to a given URL.
The given URL may contain dictionary-style string formatting, which will be interpolated against the parameters captured in the URL. Because keyword interpolation is always done (even if no arguments are passed in), any
"%"characters in the URL must be written as
"%%"so that Python will convert them to a single percent sign on output.
If the given URL is
None, Django will return an
This view inherits methods and attributes from the following view:
from django.shortcuts import get_object_or_404 from django.views.generic.base import RedirectView from articles.models import Article class ArticleCounterRedirectView(RedirectView): permanent = False query_string = True pattern_name = 'article-detail' def get_redirect_url(self, *args, **kwargs): article = get_object_or_404(Article, pk=kwargs['pk']) article.update_counter() return super().get_redirect_url(*args, **kwargs)
from django.urls import path from django.views.generic.base import RedirectView from article.views import ArticleCounterRedirectView, ArticleDetailView urlpatterns = [ path('counter/<int:pk>/', ArticleCounterRedirectView.as_view(), name='article-counter'), path('details/<int:pk>/', ArticleDetailView.as_view(), name='article-detail'), path('go-to-django/', RedirectView.as_view(url='https://www.djangoproject.com/'), name='go-to-django'), ]
The URL to redirect to, as a string. Or
Noneto raise a 410 (Gone) HTTP error.
The name of the URL pattern to redirect to. Reversing will be done using the same args and kwargs as are passed in for this view.
Whether the redirect should be permanent. The only difference here is the HTTP status code returned. If
True, then the redirect will use status code 301. If
False, then the redirect will use status code 302. By default,
Whether to pass along the GET query string to the new location. If
True, then the query string is appended to the URL. If
False, then the query string is discarded. By default,
Constructs the target URL for redirection.
kwargsarguments are positional and/or keyword arguments captured from the URL pattern, respectively.
The default implementation uses
urlas a starting string and performs expansion of
%named parameters in that string using the named groups captured in the URL.
If requested by
query_string, it will also append the query string to the generated URL. Subclasses may implement any behavior they wish, as long as the method returns a redirect-ready URL string.