クラスベースビューはビューを実装するもう一つの手段で、関数の代わりに Python のオブジェクトとしてビューを定義します。クラスベースビューは関数ベースのビューを完全に置き換えるものではありませんが、関数ベースのビューと比較して、以下のような違いと利点があります。
\n特定の HTTP メソッド (GET、POST など) に関連するコードの集まりを、条件分岐を使ってかき分けるのではなく、それぞれに独立したメソッドを割り当てることができる。
ミックスイン (多重継承) などのオブジェクト指向のテクニックを使って、コードを再利用可能なコンポーネントに分解できる。
まず初めに存在したのは、ビュー関数の規約だけでした。Django は、定義された関数に HttpRequest を渡して、HttpResponse が返ってくることを期待していました。Django が提供する機能はこの範囲まででした。
早い内に、ビューの開発には共通のイディオムやパターンが存在することが認識されるようになりました。こうしたパターンを抽象化し、共通ケースに当てはまるようなビューの開発を楽にするために導入されたのが、関数ベースのジェネリックビューでした。
\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.
\nクラスベースのジェネリックビューは関数ベースのジェネリックビューと同様に、ビューの開発を楽にすることを目的に作成されました。しかし、ミックスインを使用するなどの実装方法の工夫により、ツールキットを提供することができ、結果として、関数ベースのジェネリックビューに比べて、より拡張性が高く、柔軟なものにすることができました。
\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.
中核となる機能として、クラスベースのビューでは、HTTP リクエストのメソッドに応じてクラスインスタンスの異なるメソッドを呼び出させることができるため、1つのビュー関数の内部で条件分岐を使わずにすみます。
\nそのため、ビュー関数の場合に HTTP GET をハンドリングするコードが次のようになるとすると、
from django.http import HttpResponse\n\ndef my_view(request):\n if request.method == 'GET':\n # <view logic>\n return HttpResponse('result')\nクラスベースのビューでは以下のようになります。
\nfrom django.http import HttpResponse\nfrom django.views import View\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]\nメソッドが関数ベースのビューが返すもの、つまり何らかの形の HttpResponse と同等のものしか返せないなら意味はありません。これが意味するのは、http shortcuts ` や :class:`~django.template.response.TemplateResponse オブジェクトはクラスベースのビューの内部でも使えるということです。
最小限のクラスベースのビューでは、ジョブを実行するのにどんなクラス属性も必要としませんが、クラスベースの設計をする場合にはクラス属性が役に立つことが多いです。クラス属性のカスタマイズと設定を行うには2つの方法があります。
\n第1の方法は、通常の Python のサブクラス化を行い、サブクラス上で属性やメソッドを上書きするという方法です。たとえば、次のように親クラスが greeting という属性を持っていたとすると、
from django.http import HttpResponse\nfrom django.views import View\n\nclass GreetingView(View):\n greeting = "Good Day"\n\n def get(self, request):\n return HttpResponse(self.greeting)\nサブクラスでは次のように属性を上書きできます。
\nclass MorningGreetingView(GreetingView):\n greeting = "Morning to ya"\nもう一つの方法は、URLconf 内での as_view() の呼び出し時に、クラス属性をキーワード引数として指定する方法です。
urlpatterns = [\n path('about/', GreetingView.as_view(greeting="G'day")),\n]\nミックスインは、複数の親クラスのメソッドや属性を混合することができる多重継承の形式の1つです。
\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.
フォームを扱う基本の関数ベースのビューは、次のようなコードになります。
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import MyForm\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})\n同等のクラスベースのビューは、次のようになるでしょう。
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\nfrom django.views import View\n\nfrom .forms import MyForm\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!).
クラスベースのビューを拡張する方法は、ミックスインの使用にとどまりません。デコレータも使用できます。クラスベースのビューは関数ではないので、as_view() を使用した場合とサブクラスを作成した場合では、デコレータは違った動作をします。
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]\nこのアプローチではデコレータはインスタンスごとに適用されます。もしあるビューのすべてのインスタンスをデコレーションしたいばあいは、別のアプローチを取る必要があります。
\nクラスベースのビューのすべてのインスタンスをデコレーションするには、クラスの定義自体をデコレーションする必要があります。そのためには、クラスの dispatch() メソッドにデコレータを付けます。
クラス上のメソッドはスタンドアロンの関数と完全に同じではないため、関数デコレータを単純にそのままメソッドに適用することはできません。適用前にメソッドデコレータに変換する必要があります。method_decorator デコレータを使えば、関数デコレータをメソッドデコレータに変換し、インスタンスのメソッドのデコレーションに使えるようにできます。たとえば、次のように使用します。
from django.contrib.auth.decorators import login_required\nfrom django.utils.decorators import method_decorator\nfrom django.views.generic import TemplateView\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)\nあるいは、より簡潔に、クラスを代わりにデコレートして、デコレーション対象のメソッド名をキーワード引数 name に渡すという方法もあります。
@method_decorator(login_required, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\n共通のデコレータ群が複数の場所で呼ばれる場合には、デコレータのリストまたはタプルを定義して、これを method_decorator() を複数回呼ぶ代わりに使用できます。以下の2つのクラスは同じになります。
decorators = [never_cache, login_required]\n\n@method_decorator(decorators, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\n\n@method_decorator(never_cache, name='dispatch')\n@method_decorator(login_required, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\nデコレータは、デコレータに渡された順番でリクエストを処理します。上の例では、never_cache() が login_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.