The following three classes provide much of the functionality needed to create\nDjango views. You may think of them as parent views, which can be used by\nthemselves or inherited from. They may not provide all the capabilities\nrequired for projects, in which case there are Mixins and Generic class-based\nviews.
\nMany of Django's built-in class-based views inherit from other class-based\nviews or various mixins. Because this inheritance chain is very important, the\nancestor classes are documented under the section title of Ancestors (MRO).\nMRO is an acronym for Method Resolution Order.
\nViewLink to this heading#The master class-based base view. All other class-based views inherit from\nthis base class.
\nMethod Flowchart
\n\nExample views.py:
\nfrom django.http import HttpResponse\nfrom django.views.generic import View\n\nclass MyView(View):\n\n def get(self, request, *args, **kwargs):\n return HttpResponse('Hello, World!')\nExample urls.py:
\nfrom django.conf.urls import url\n\nfrom myapp.views import MyView\n\nurlpatterns = [\n url(r'^mine/$', MyView.as_view(), name='my-view'),\n]\nAttributes
\nThe list of HTTP method names that this view will accept.
\nDefault:
\n['get', 'post', 'put', 'patch', 'delete', 'head', 'options', 'trace']\nMethods
\nReturns a callable view that takes a request and returns a response:
\nresponse = MyView.as_view()(request)\nThe returned view has view_class and view_initkwargs\nattributes.
The view part of the view -- the method that accepts a request\nargument plus arguments, and returns a HTTP response.
The default implementation will inspect the HTTP method and attempt to\ndelegate to a method that matches the HTTP method; a GET will be\ndelegated to get(), a POST to post(), and so on.
By default, a HEAD request will be delegated to get().\nIf you need to handle HEAD requests in a different way than GET,\nyou can override the head() method. See\nSupporting other HTTP methods for an example.
If the view was called with a HTTP method it doesn't support, this\nmethod is called instead.
\nThe default implementation returns HttpResponseNotAllowed with a\nlist of allowed methods in plain text.
Handles responding to requests for the OPTIONS HTTP verb. Returns a\nresponse with the Allow header containing a list of the view's\nallowed HTTP method names.
TemplateViewLink to this heading#Renders a given template, with the context containing parameters captured\nin the URL.
\nAncestors (MRO)
\nThis view inherits methods and attributes from the following views:
\nMethod Flowchart
\n\nExample views.py:
\nfrom django.views.generic.base import TemplateView\n\nfrom articles.models import Article\n\nclass HomePageView(TemplateView):\n\n template_name = "home.html"\n\n def get_context_data(self, **kwargs):\n context = super(HomePageView, self).get_context_data(**kwargs)\n context['latest_articles'] = Article.objects.all()[:5]\n return context\nExample urls.py:
\nfrom django.conf.urls import url\n\nfrom myapp.views import HomePageView\n\nurlpatterns = [\n url(r'^$', HomePageView.as_view(), name='home'),\n]\nContext
\nPopulated (through ContextMixin) with\nthe keyword arguments captured from the URL pattern that served the view.
RedirectViewLink to this heading#Redirects to a given URL.
\nThe given URL may contain dictionary-style string formatting, which will be\ninterpolated against the parameters captured in the URL. Because keyword\ninterpolation is always done (even if no arguments are passed in), any\n"%" characters in the URL must be written as "%%" so that Python\nwill convert them to a single percent sign on output.
If the given URL is None, Django will return an HttpResponseGone\n(410).
Ancestors (MRO)
\nThis view inherits methods and attributes from the following view:
\n\nMethod Flowchart
\n\nExample views.py:
\nfrom django.shortcuts import get_object_or_404\nfrom django.views.generic.base import RedirectView\n\nfrom articles.models import Article\n\nclass ArticleCounterRedirectView(RedirectView):\n\n permanent = False\n query_string = True\n pattern_name = 'article-detail'\n\n def get_redirect_url(self, *args, **kwargs):\n article = get_object_or_404(Article, pk=kwargs['pk'])\n article.update_counter()\n return super(ArticleCounterRedirectView, self).get_redirect_url(*args, **kwargs)\nExample urls.py:
\nfrom django.conf.urls import url\nfrom django.views.generic.base import RedirectView\n\nfrom article.views import ArticleCounterRedirectView, ArticleDetail\n\nurlpatterns = [\n url(r'^counter/(?P<pk>[0-9]+)/$', ArticleCounterRedirectView.as_view(), name='article-counter'),\n url(r'^details/(?P<pk>[0-9]+)/$', ArticleDetail.as_view(), name='article-detail'),\n url(r'^go-to-django/$', RedirectView.as_view(url='https://djangoproject.com'), name='go-to-django'),\n]\nAttributes
\nThe URL to redirect to, as a string. Or None to raise a 410 (Gone)\nHTTP error.
The name of the URL pattern to redirect to. Reversing will be done\nusing the same args and kwargs as are passed in for this view.
\nWhether the redirect should be permanent. The only difference here is\nthe HTTP status code returned. If True, then the redirect will use\nstatus code 301. If False, then the redirect will use status code\n302. By default, permanent is False.
Whether to pass along the GET query string to the new location. If\nTrue, then the query string is appended to the URL. If False,\nthen the query string is discarded. By default, query_string is\nFalse.
Methods
\nConstructs the target URL for redirection.
\nThe default implementation uses url as a starting\nstring and performs expansion of % named parameters in that string\nusing the named groups captured in the URL.
If url is not set, get_redirect_url() tries to reverse the\npattern_name using what was captured in the URL (both named and\nunnamed groups are used).
If requested by query_string, it will also append the query\nstring to the generated URL.\nSubclasses may implement any behavior they wish, as long as the method\nreturns a redirect-ready URL string.