Base views¶
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 inheritence chain is very important, the ancestor classes are documented under the section title of Ancestors (MRO). MRO is an acronym for Method Resolution Order.
View¶
-
class
django.views.generic.base.
View
¶ The master class-based base view. All other class-based views inherit from this base class.
Method Flowchart
Example views.py:
from django.http import HttpResponse from django.views.generic import View class MyView(View): def get(self, request, *args, **kwargs): return HttpResponse('Hello, World!')
Example urls.py:
from django.conf.urls import patterns, url from myapp.views import MyView urlpatterns = patterns('', url(r'^mine/$', MyView.as_view(), name='my-view'), )
Attributes
-
http_method_names
¶ The list of HTTP method names that this view will accept.
Default:
['get', 'post', 'put', 'delete', 'head', 'options', 'trace']
Methods
-
classmethod
as_view
(**initkwargs)¶ Returns a callable view that takes a request and returns a response:
response = MyView.as_view()(request)
-
dispatch
(request, *args, **kwargs)¶ The
view
part of the view – the method that accepts arequest
argument plus arguments, and returns a HTTP response.The default implementation will inspect the HTTP method and attempt to delegate to a method that matches the HTTP method; a
GET
will be delegated toget()
, aPOST
topost()
, and so on.By default, a
HEAD
request will be delegated toget()
. If you need to handleHEAD
requests in a different way thanGET
, you can override thehead()
method. See Supporting other HTTP methods for an example.The default implementation also sets
request
,args
andkwargs
as instance variables, so any method on the view can know the full details of the request that was made to invoke the view.
-
http_method_not_allowed
(request, *args, **kwargs)¶ If the view was called with a HTTP method it doesn’t support, this method is called instead.
The default implementation returns
HttpResponseNotAllowed
with a list of allowed methods in plain text.
-
options
(request, *args, **kwargs)¶ Handles responding to requests for the OPTIONS HTTP verb. Returns a list of the allowed HTTP method names for the view.
-
TemplateView¶
-
class
django.views.generic.base.
TemplateView
¶ Renders a given template, with the context containing parameters captured in the URL.
The context used to be populated with a{{ params }}
dictionary of the parameters captured in the URL. Now those parameters are first-level context variables.Ancestors (MRO)
This view inherits methods and attributes from the following views:
django.views.generic.base.TemplateView
django.views.generic.base.TemplateResponseMixin
django.views.generic.base.View
Method Flowchart
Example views.py:
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(HomePageView, self).get_context_data(**kwargs) context['latest_articles'] = Article.objects.all()[:5] return context
Example urls.py:
from django.conf.urls import patterns, url from myapp.views import HomePageView urlpatterns = patterns('', url(r'^$', HomePageView.as_view(), name='home'), )
Context
params
: The dictionary of keyword arguments captured from the URL pattern that served the view.
RedirectView¶
-
class
django.views.generic.base.
RedirectView
¶ 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 anHttpResponseGone
(410).Ancestors (MRO)
This view inherits methods and attributes from the following view:
Method Flowchart
Example views.py:
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 def get_redirect_url(self, pk): article = get_object_or_404(Article, pk=pk) article.update_counter() return reverse('product_detail', args=(pk,))
Example urls.py:
from django.conf.urls import patterns, url from django.views.generic.base import RedirectView from article.views import ArticleCounterRedirectView urlpatterns = patterns('', url(r'r^(?P<pk>\d+)/$', ArticleCounterRedirectView.as_view(), name='article-counter'), url(r'^go-to-django/$', RedirectView.as_view(url='http://djangoproject.com'), name='go-to-django'), )
Attributes
-
url
¶ The URL to redirect to, as a string. Or
None
to raise a 410 (Gone) HTTP error.
-
permanent
¶ 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. IfFalse
, then the redirect will use status code 302. By default,permanent
isTrue
.
-
query_string
¶ Whether to pass along the GET query string to the new location. If
True
, then the query string is appended to the URL. IfFalse
, then the query string is discarded. By default,query_string
isFalse
.
Methods
-
get_redirect_url
(**kwargs)¶ Constructs the target URL for redirection.
The default implementation uses
url
as a starting string, performs expansion of%
parameters in that string, as well as the appending of query string if requested byquery_string
. Subclasses may implement any behavior they wish, as long as the method returns a redirect-ready URL string.
-