ウェブアプリケーションを書くのは、特定のパターンを何度も繰り返すことになるため、単調になりがちです。Django はモデルとテンプレート層で単調さを取り除くことを試みてきましたが、ウェブ開発者はビューレベルでもこの種の退屈な繰り返しを経験してきました。
\nDjango の ジェネリックビュー は、この苦痛を軽減するために開発されました。ビューの開発には共通のイディオムとパタンが存在するため、それらを抽象化することで、共通のビューデータを少ないコードで素早く記述することができます。
\n私たちはオブジェクトのリスト表示のような特定の共通タスクを認識することで、任意の オブジェクトのリストを表示するコードを書きます。そして、対象のモデルを URLconf から追加の引数として渡します。
\nDjango のジェネリックビューを使うと、以下のことが可能になります。
\nオブジェクトのリストと、1つのオブジェクトに対する詳細ページの表示。カンファレンスを管理するアプリケーションを作っている場合、リストビューの例としては、TalkListView や RegisteredUserListView といったものが考えられます。1つのトークの情報を表示するページが、いわゆる「詳細」ビューの一例です。
日付を基本とするオブジェクトと、年・月・日のアーカイブページ、関連する詳細ページと「最新」ページの表示。
ユーザーにオブジェクトの作成、更新、削除を可能にする (認証のあり・なしいずれでも)。
Taken together, these views provide interfaces to perform the most common tasks\ndevelopers encounter.
\n言うまでもなく、ジェネリックビューは実質的に開発をスピードアップさせてくれます。しかし、多くのプロジェクトでは遅かれ早かれジェネリックビューだけでは十分ではなくなる瞬間が訪れます。実際、新しい Django 開発者から最もよく聞かれる質問は、幅広い状況に対処するためにジェネリックビューを拡張するにはどうすれば良いのか、というものです。
\nThis is one of the reasons generic views were redesigned for the 1.3 release -\npreviously, they were view functions with a bewildering array of options; now,\nrather than passing in a large amount of configuration in the URLconf, the\nrecommended way to extend generic views is to subclass them, and override their\nattributes or methods.
\n上で述べたように、ジェネリックビューには限界があります。自作のビューをジェネリックビューのサブクラスとして実装することに四苦八苦していると、それよりも自作のクラスベースまたは関数ベースのビューを使った方が効率的なのではないかと思うかもしれません。
\nジェネリックビューの例はサードパーティアプリケーションでも利用できます。あるいは、自分で必要に応じてアプリケーションを作ることもできます。
\nTemplateView certainly is useful, but\nDjango's generic views really shine when it comes to presenting views of your\ndatabase content. Because it's such a common task, Django comes with a handful\nof built-in generic views to help generate list and detail views of objects.
オブジェクトのリストや個々のオブジェクトを表示する例から見てみましょう。
\nここでは、以下のようなモデルを使用します。
\n# models.py\nfrom django.db import models\n\nclass Publisher(models.Model):\n name = models.CharField(max_length=30)\n address = models.CharField(max_length=50)\n city = models.CharField(max_length=60)\n state_province = models.CharField(max_length=30)\n country = models.CharField(max_length=50)\n website = models.URLField()\n\n class Meta:\n ordering = ["-name"]\n\n def __str__(self):\n return self.name\n\nclass Author(models.Model):\n salutation = models.CharField(max_length=10)\n name = models.CharField(max_length=200)\n email = models.EmailField()\n headshot = models.ImageField(upload_to='author_headshots')\n\n def __str__(self):\n return self.name\n\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n authors = models.ManyToManyField('Author')\n publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)\n publication_date = models.DateField()\n次に、ビューを定義しましょう。
\n# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\nclass PublisherList(ListView):\n model = Publisher\n最後に、このビューを URL にフックさせます。
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherList\n\nurlpatterns = [\n path('publishers/', PublisherList.as_view()),\n]\nThat's all the Python code we need to write. We still need to write a template,\nhowever. We could explicitly tell the view which template to use by adding a\ntemplate_name attribute to the view, but in the absence of an explicit\ntemplate Django will infer one from the object's name. In this case, the\ninferred template will be "books/publisher_list.html" -- the "books" part\ncomes from the name of the app that defines the model, while the "publisher"\nbit is the lowercased version of the model's name.
This template will be rendered against a context containing a variable called\nobject_list that contains all the publisher objects. A template might look\nlike this:
{% extends "base.html" %}\n\n{% block content %}\n <h2>Publishers</h2>\n <ul>\n {% for publisher in object_list %}\n <li>{{ publisher.name }}</li>\n {% endfor %}\n </ul>\n{% endblock %}\nThat's really all there is to it. All the cool features of generic views come\nfrom changing the attributes set on the generic view. The\ngeneric views reference documents all the\ngeneric views and their options in detail; the rest of this document will\nconsider some of the common ways you might customize and extend generic views.
\nコード例の出版社をリストするテンプレートが、すべての出版社を``object_list`` という名前の変数に格納していたことに気づいたかもしれません。これでもたしかに機能的には正しく動作しますが、テンプレートを書く人にとっては、とてもではありませんが「親切」とは言えません。ここではこの変数には出版社のリストが入っているのだと「事実として知らなければならない」わけです。
\nWell, if you're dealing with a model object, this is already done for you. When\nyou are dealing with an object or queryset, Django is able to populate the\ncontext using the lowercased version of the model class' name. This is provided\nin addition to the default object_list entry, but contains exactly the same\ndata, i.e. publisher_list.
しかし、この名前でも良くないと感じるなら、コンテキストの変数名を手動で設定することもできます。次のように、ジェネリックビューの context_object_name 属性を設定すると、コンテキスト変数の名前として使えるようになります。
# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\nclass PublisherList(ListView):\n model = Publisher\n context_object_name = 'my_favorite_publishers'\n分かりやすい context_object_name を設定するのはいつでも良い考えです。テンプレートのデザイン担当の同僚に、きっと感謝されるでしょう。
Often you need to present some extra information beyond that provided by the\ngeneric view. For example, think of showing a list of all the books on each\npublisher detail page. The DetailView\ngeneric view provides the publisher to the context, but how do we get\nadditional information in that template?
The answer is to subclass DetailView\nand provide your own implementation of the get_context_data method.\nThe default implementation adds the object being displayed to the template, but\nyou can override it to send more:
from django.views.generic import DetailView\nfrom books.models import Book, Publisher\n\nclass PublisherDetail(DetailView):\n\n model = Publisher\n\n def get_context_data(self, **kwargs):\n # Call the base implementation first to get a context\n context = super().get_context_data(**kwargs)\n # Add in a QuerySet of all the books\n context['book_list'] = Book.objects.all()\n return context\nそれでは次に、すべての場所で使っていた model 引数について詳しく見ていきましょう。model 引数は、ビューの操作対象となるデータベースのモデルを指定します。この引数は、1オブジェクトまたは複数オブジェクトを操作するすべてのジェネリックビューで使用可能です。しかし、model 引数は操作対象のオブジェクトを指定する唯一の方法ではありません。次のように、queryset 引数を使ってオブジェクトを指定することもできます。
from django.views.generic import DetailView\nfrom books.models import Publisher\n\nclass PublisherDetail(DetailView):\n\n context_object_name = 'publisher'\n queryset = Publisher.objects.all()\nSpecifying model = Publisher is shorthand for saying queryset =\nPublisher.objects.all(). However, by using queryset to define a filtered\nlist of objects you can be more specific about the objects that will be visible\nin the view (see クエリを作成する for more information about\nQuerySet objects, and see the\nclass-based views reference for the\ncomplete details).
To pick an example, we might want to order a list of books by publication date,\nwith the most recent first:
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass BookList(ListView):\n queryset = Book.objects.order_by('-publication_date')\n context_object_name = 'book_list'\nThat's a pretty minimal example, but it illustrates the idea nicely. Of course,\nyou'll usually want to do more than just reorder objects. If you want to\npresent a list of books by a particular publisher, you can use the same\ntechnique:
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass AcmeBookList(ListView):\n\n context_object_name = 'book_list'\n queryset = Book.objects.filter(publisher__name='ACME Publishing')\n template_name = 'books/acme_list.html'\nqueryset がフィルタリングされただけではなく、テンプレート名も変更されているのがわかります。そうしないと、ジェネリックビューは「素の」オブジェクトリストと同じテンプレートを使ってしまいます。しかし、それは意図したものではないはずです。
同時に注意しておきたいのは、この方法は特定の出版社の本をリストアップするにはあまりエレガントな方法ではないということです。新しく出版社のページを追加する必要が生じるたびにURLconf に数行を追加する必要があるので、これでは数社以上追加するとなるとすでに無理があると分かるでしょう。この問題の解決策は、次のセクションで議論します。
\n\nもう一つのよくあるニーズは、リストページの URL に指定した何らかのキーを使って、表示するオブジェクトをフィルタリングすることです。上の例では、出版社名を URLconf にハードコーディングしてしまっていましたが、もし任意の出版社に対するすべての書籍を表示するようなビューを書きたい場合には、どうすればいいでしょうか？
\nHandily, the ListView has a\nget_queryset() method we\ncan override. By default, it returns the value of the queryset attribute,\nbut we can use it to add more logic.
この機能がうまく動作するキーポイントは、クラスベースのビューが呼ばれる段階で self 内には様々な便利な値が格納されていることです。request (self.request)、位置引数 (self.args)、そして、キーワード引数 (self.kwargs) が、URLconf からキャプチャされてきています。
ここでは、次のように URLconf に1つのキャプチャグループがあるとしましょう。
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherBookList\n\nurlpatterns = [\n path('books/<publisher>/', PublisherBookList.as_view()),\n]\n次に、PublisherBookList ビュー本体を書きます。
# views.py\nfrom django.shortcuts import get_object_or_404\nfrom django.views.generic import ListView\nfrom books.models import Book, Publisher\n\nclass PublisherBookList(ListView):\n\n template_name = 'books/books_by_publisher.html'\n\n def get_queryset(self):\n self.publisher = get_object_or_404(Publisher, name=self.kwargs['publisher'])\n return Book.objects.filter(publisher=self.publisher)\nUsing get_queryset to add logic to the queryset selection is as convenient\nas it is powerful. For instance, if we wanted, we could use\nself.request.user to filter using the current user, or other more complex\nlogic.
次のようにすれば、テンプレートで使えるように、出版社の情報を同時にコンテキストに追加することもできます。
\n# ...\n\ndef get_context_data(self, **kwargs):\n # Call the base implementation first to get a context\n context = super().get_context_data(**kwargs)\n # Add in the publisher\n context['publisher'] = self.publisher\n return context\n最後に見る共通パタンは、ジェネリックビューの呼び出しの前後で追加の処理を実行するというものです。
\nAuthor モデルに last_accessed フィールドがあり、誰かが最後に著者の情報を見た時刻をトラッキングするのに使用しているとします。
# models.py\nfrom django.db import models\n\nclass Author(models.Model):\n salutation = models.CharField(max_length=10)\n name = models.CharField(max_length=200)\n email = models.EmailField()\n headshot = models.ImageField(upload_to='author_headshots')\n last_accessed = models.DateTimeField()\nもちろん DetailView クラスはこのフィールドの存在について何も知りません。しかし、繰り返しになりますが、フィールドの更新を維持するカスタムビューを書くのは簡単なことです。
まず、著者の詳細ビューを追加して、URLconf にカスタムビューを使うようにする必要があります。
\nfrom django.urls import path\nfrom books.views import AuthorDetailView\n\nurlpatterns = [\n #...\n path('authors/<int:pk>/', AuthorDetailView.as_view(), name='author-detail'),\n]\nThen we'd write our new view -- get_object is the method that retrieves the\nobject -- so we override it and wrap the call:
from django.utils import timezone\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\nclass AuthorDetailView(DetailView):\n\n queryset = Author.objects.all()\n\n def get_object(self):\n obj = super().get_object()\n # Record the last accessed date\n obj.last_accessed = timezone.now()\n obj.save()\n return obj\n