Class-based views provide an alternative way to implement views as Python\nobjects instead of functions. They do not replace function-based views, but\nhave certain differences and advantages when compared to function-based views:
\nOrganization of code related to specific HTTP methods (GET, POST,\netc.) can be addressed by separate methods instead of conditional branching.
Object oriented techniques such as mixins (multiple inheritance) can be\nused to factor code into reusable components.
In the beginning there was only the view function contract, Django passed your\nfunction an HttpRequest and expected back an\nHttpResponse. This was the extent of what Django provided.
Early on it was recognized that there were common idioms and patterns found in\nview development. Function-based generic views were introduced to abstract\nthese patterns and ease view development for the common cases.
\nThe problem with function-based generic views is that while they covered the\nsimple cases well, there was no way to extend or customize them beyond some\nconfiguration options, limiting their usefulness in many real-world\napplications.
\nClass-based generic views were created with the same objective as\nfunction-based generic views, to make view development easier. However, the way\nthe solution is implemented, through the use of mixins, provides a toolkit that\nresults in class-based generic views being more extensible and flexible than\ntheir function-based counterparts.
\nIf you have tried function based generic views in the past and found them\nlacking, you should not think of class-based generic views as a class-based\nequivalent, but rather as a fresh approach to solving the original problems\nthat generic views were meant to solve.
\nThe toolkit of base classes and mixins that Django uses to build class-based\ngeneric views are built for maximum flexibility, and as such have many hooks in\nthe form of default method implementations and attributes that you are unlikely\nto be concerned with in the simplest use cases. For example, instead of\nlimiting you to a class-based attribute for form_class, the implementation\nuses a get_form method, which calls a get_form_class method, which in\nits default implementation returns the form_class attribute of the class.\nThis gives you several options for specifying what form to use, from an\nattribute, to a fully dynamic, callable hook. These options seem to add hollow\ncomplexity for simple situations, but without them, more advanced designs would\nbe limited.
At its core, a class-based view allows you to respond to different HTTP request\nmethods with different class instance methods, instead of with conditionally\nbranching code inside a single view function.
\nSo where the code to handle HTTP GET in a view function would look\nsomething like:
from django.http import HttpResponse\n\n\ndef my_view(request):\n if request.method == "GET":\n # <view logic>\n return HttpResponse("result")\nIn a class-based view, this would become:
\nfrom django.http import HttpResponse\nfrom django.views import View\n\n\nclass MyView(View):\n def get(self, request):\n # <view logic>\n return HttpResponse("result")\nBecause Django’s URL resolver expects to send the request and associated\narguments to a callable function, not a class, class-based views have an\nas_view() class method which returns a\nfunction that can be called when a request arrives for a URL matching the\nassociated pattern. The function creates an instance of the class, calls\nsetup() to initialize its attributes, and\nthen calls its dispatch() method.\ndispatch looks at the request to determine whether it is a GET,\nPOST, etc, and relays the request to a matching method if one is defined,\nor raises HttpResponseNotAllowed if not:
# urls.py\nfrom django.urls import path\nfrom myapp.views import MyView\n\nurlpatterns = [\n path("about/", MyView.as_view()),\n]\nIt is worth noting that what your method returns is identical to what you\nreturn from a function-based view, namely some form of\nHttpResponse. This means that\nhttp shortcuts or\nTemplateResponse objects are valid to use\ninside a class-based view.
While a minimal class-based view does not require any class attributes to\nperform its job, class attributes are useful in many class-based designs,\nand there are two ways to configure or set class attributes.
\nThe first is the standard Python way of subclassing and overriding attributes\nand methods in the subclass. So that if your parent class had an attribute\ngreeting like this:
from django.http import HttpResponse\nfrom django.views import View\n\n\nclass GreetingView(View):\n greeting = "Good Day"\n\n def get(self, request):\n return HttpResponse(self.greeting)\nYou can override that in a subclass:
\nclass MorningGreetingView(GreetingView):\n greeting = "Morning to ya"\nAnother option is to configure class attributes as keyword arguments to the\nas_view() call in the URLconf:
urlpatterns = [\n path("about/", GreetingView.as_view(greeting="G'day")),\n]\nMixins are a form of multiple inheritance where behaviors and attributes of\nmultiple parent classes can be combined.
\nFor example, in the generic class-based views there is a mixin called\nTemplateResponseMixin whose primary purpose\nis to define the method\nrender_to_response().\nWhen combined with the behavior of the View\nbase class, the result is a TemplateView\nclass that will dispatch requests to the appropriate matching methods (a\nbehavior defined in the View base class), and that has a\nrender_to_response()\nmethod that uses a\ntemplate_name\nattribute to return a TemplateResponse\nobject (a behavior defined in the TemplateResponseMixin).
Mixins are an excellent way of reusing code across multiple classes, but they\ncome with some cost. The more your code is scattered among mixins, the harder\nit will be to read a child class and know what exactly it is doing, and the\nharder it will be to know which methods from which mixins to override if you\nare subclassing something that has a deep inheritance tree.
\nNote also that you can only inherit from one generic view - that is, only one\nparent class may inherit from View and\nthe rest (if any) should be mixins. Trying to inherit from more than one class\nthat inherits from View - for example, trying to use a form at the top of a\nlist and combining ProcessFormView and\nListView - won’t work as expected.
A basic function-based view that handles forms may look something like this:
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import MyForm\n\n\ndef myview(request):\n if request.method == "POST":\n form = MyForm(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect("/success/")\n else:\n form = MyForm(initial={"key": "value"})\n\n return render(request, "form_template.html", {"form": form})\nA similar class-based view might look like:
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\nfrom django.views import View\n\nfrom .forms import MyForm\n\n\nclass MyFormView(View):\n form_class = MyForm\n initial = {"key": "value"}\n template_name = "form_template.html"\n\n def get(self, request, *args, **kwargs):\n form = self.form_class(initial=self.initial)\n return render(request, self.template_name, {"form": form})\n\n def post(self, request, *args, **kwargs):\n form = self.form_class(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect("/success/")\n\n return render(request, self.template_name, {"form": form})\nThis is a minimal case, but you can see that you would then have the option\nof customizing this view by overriding any of the class attributes, e.g.\nform_class, via URLconf configuration, or subclassing and overriding one or\nmore of the methods (or both!).
The extension of class-based views isn’t limited to using mixins. You can also\nuse decorators. Since class-based views aren’t functions, decorating them works\ndifferently depending on if you’re using as_view() or creating a subclass.
You can adjust class-based views by decorating the result of the\nas_view() method. The easiest place to do\nthis is in the URLconf where you deploy your view:
from django.contrib.auth.decorators import login_required, permission_required\nfrom django.views.generic import TemplateView\n\nfrom .views import VoteView\n\nurlpatterns = [\n path("about/", login_required(TemplateView.as_view(template_name="secret.html"))),\n path("vote/", permission_required("polls.can_vote")(VoteView.as_view())),\n]\nThis approach applies the decorator on a per-instance basis. If you\nwant every instance of a view to be decorated, you need to take a\ndifferent approach.
\nTo decorate every instance of a class-based view, you need to decorate\nthe class definition itself. To do this you apply the decorator to the\ndispatch() method of the class.
A method on a class isn’t quite the same as a standalone function, so you can’t\njust apply a function decorator to the method – you need to transform it into\na method decorator first. The method_decorator decorator transforms a\nfunction decorator into a method decorator so that it can be used on an\ninstance method. For example:
from django.contrib.auth.decorators import login_required\nfrom django.utils.decorators import method_decorator\nfrom django.views.generic import TemplateView\n\n\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n\n @method_decorator(login_required)\n def dispatch(self, *args, **kwargs):\n return super().dispatch(*args, **kwargs)\nOr, more succinctly, you can decorate the class instead and pass the name\nof the method to be decorated as the keyword argument name:
@method_decorator(login_required, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\nIf you have a set of common decorators used in several places, you can define\na list or tuple of decorators and use this instead of invoking\nmethod_decorator() multiple times. These two classes are equivalent:
decorators = [never_cache, login_required]\n\n\n@method_decorator(decorators, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n\n\n@method_decorator(never_cache, name="dispatch")\n@method_decorator(login_required, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\nThe decorators will process a request in the order they are passed to the\ndecorator. In the example, never_cache() will process the request before\nlogin_required().
In this example, every instance of ProtectedView will have login\nprotection. These examples use login_required, however, the same behavior\ncan be obtained by using\nLoginRequiredMixin.