ビューはリクエストを受けてレスポンスを返す callable です。これは単なる関数以上のものになる可能性があり、Django ではビューとして使用できるいくつかのクラスの例を提供しています。これらのクラスは、継承やミックスインを利用してビューを構造化し、コードを再利用することを可能にします。後ほど説明するタスクのための汎用的なビューもありますが、あなたのユースケースに合った再利用可能なビューの構造を独自に設計したいと思うかもしれません。詳細については、クラスベースのビューの リファレンスドキュメント を参照してくださ
\nDjango は、さまざまなアプリケーションに広く適用できるベースビュークラスを用意しています。 View クラスを継承したすべてのビューは、指定した URL へのビューのリンクや、送り出す HTTP メソッド、その他よく使われる機能をハンドリングします。 RedirectView は HTTP リダイレクトを行うビュークラス、 TemplateView はベースビューを拡張してテンプレートレンダリングの機能をもたせたビュークラスです。
ジェネリックビューを使用する最もダイレクトな方法は、URLconf 内で直接オブジェクトを作成することです。クラスベースビューの属性をいくつか変更するだけなら、 as_view() のメソッド呼び出しに渡せばよいのです。
from django.urls import path\nfrom django.views.generic import TemplateView\n\nurlpatterns = [\n path("about/", TemplateView.as_view(template_name="about.html")),\n]\nas_view() に渡されたすべての引数は、クラスで設定された属性を上書きします。次の例では TemplateView の template_name を設定しています。同様の上書きのパターンは、RedirectView の url 属性でも使えます。
次に、ジェネリックビューのもっと強力な使用例として、既存のビューを継承して、新しい値やメソッドを提供するために、 template_name などの属性や get_context_data などのメソッドをサブクラスで上書きする方法を紹介します。たとえば、1つのテンプレート about.html だけを表示するビューを作ることを考えてみてください。Django には、このために利用できるジェネリックビュー TemplateView があるので、これをサブクラス化し、テンプレート名を上書きすることで実装できます。
# some_app/views.py\nfrom django.views.generic import TemplateView\n\n\nclass AboutView(TemplateView):\n template_name = "about.html"\nあとは、URLconf にこの新しいビューを追加する必要があります。 TemplateView は1つのクラスであって、関数ではありません。そのため、指定する URL に対して、代わりに as_view() クラスメソッドを設定しています。これによって、クラスベースビューに対する関数ライクな要素を指定できます。
# urls.py\nfrom django.urls import path\nfrom some_app.views import AboutView\n\nurlpatterns = [\n path("about/", AboutView.as_view()),\n]\n組み込みの汎用ビューの使用方法の詳細については、次のトピック 汎用のクラスベースビュー を参照してください。
\n誰かが私たちのライブラリに HTTP 経由でアクセスして、ビューを API として使用したいという状況を考えてください。API クライアントはたびたびコネクションを張り、最終訪問日時以降に出版された本のデータをダウンロードするとします。しかし、新しい本の情報が存在しない場合には、データベースから本のデータを取得し、レスポンステキストをレンダリングし、クライアントに送信し返すための CPU タイムとバンド幅は無駄になってしまいます。最新の本が出版された時点で API に問い合わせた方が好ましいかもしれません。
\nそのために、URLconf 内で、本のリストビューへの URL を次のようにマッピングします。
\nfrom django.urls import path\nfrom books.views import BookListView\n\nurlpatterns = [\n path("books/", BookListView.as_view()),\n]\nそして、ビューには次のように書きます。
\nfrom django.http import HttpResponse\nfrom django.views.generic import ListView\nfrom books.models import Book\n\n\nclass BookListView(ListView):\n model = Book\n\n def head(self, *args, **kwargs):\n last_book = self.get_queryset().latest("publication_date")\n response = HttpResponse(\n # RFC 1123 date format.\n headers={\n "Last-Modified": last_book.publication_date.strftime(\n "%a, %d %b %Y %H:%M:%S GMT"\n )\n },\n )\n return response\nビューが GET リクエストからアクセスされた場合、レスポンスにはオブジェクトリストが返されます( book_list.html テンプレートを使用しています)。しかし、クライアントがHEADリクエストを発行した場合、レスポンスは空のボディを持ち、 Last-Modified ヘッダーは最新の書籍がいつ発行されたかを示します。この情報に基づいて、クライアントは完全なオブジェクトリストをダウンロードするかどうかを判断します。
既に示した同期 (def) メソッドハンドラと同様に、 View サブクラスは await: を使用して非同期 (async def) メソッドハンドラを定義できます:
import asyncio\nfrom django.http import HttpResponse\nfrom django.views import View\n\n\nclass AsyncView(View):\n async def get(self, request, *args, **kwargs):\n # Perform io-blocking view logic using await, sleep for example.\n await asyncio.sleep(1)\n return HttpResponse("Hello async world!")\n1つのビュークラス内では、すべてのユーザー定義メソッドハンドラは def を使用した同期的なものか、 async def を使用した非同期的なものでなければなりません。 def と async def が混在している場合、 as_view() で ImproperlyConfigured 例外が発生します。
Django は自動的に非同期ビューを検出し、非同期コンテキストで実行します。Django の非同期サポートや、非同期ビューの最適な使い方については、 非同期サポート を参照してください。
\n