5 に答える
クラスをサブクラス化し、特定の場合にget_context_dataなどのメソッドを改良し、残りをそのままにしておくことができます。関数ではそれを行うことはできません。
たとえば、前のビューが行うすべてのことを行う新しいビューを作成する必要があるかもしれませんが、コンテキストに追加の変数を含める必要があります。元のビューをサブクラス化し、get_context_dataメソッドをオーバーライドします。
また、テンプレートをレンダリングするために必要なステップを別々のメソッドに分割すると、コードがより明確になります。メソッドでの実行が少ないほど、理解しやすくなります。通常の表示機能では、すべてが1つの処理装置にダンプされます。
self.args[0]気になる場合は、別の方法は次のとおりです。
urlpatterns = patterns('books.views',
url(r'^books/(?P<slug>\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)
self.kwargs['slug']次に、代わりに使用して、少し読みやすくすることができます。
サンプルの関数とクラスは機能が同じではありません。
クラスベースバージョンは、無料でページ付けを提供し、GET以外のHTTP動詞の使用を禁止します。
これを関数に追加したい場合は、はるかに長くなります。
しかし、それは確かにもっと複雑です。
これは私がこれを聞いた最初のものです-そして私はそれが好きです。
ここで私が見ている利点は、正直なところ、ビューがDjango全体とより一貫していることです。モデルはクラスであり、ビューもそうあるべきだといつも感じていました。私はすべてがそうであるというわけではないことを知っていますが、ビューとモデルは2つの頻繁に使用されるタイプです。
技術的なメリットは？さて、Pythonではすべてがクラス（またはオブジェクト？）です-それで本当に違いはありますか？そもそも99％の糖衣構文ではないですか？
クラスベースのビューについて考える1つの方法は、補助輪がオフになっているDjango管理者のようなものであるため、はるかに柔軟です（ただし、理解するのがより困難です）。
たとえば、管理者のリスト表示は、明らかに汎用のListViewに基づいています。モデルまたはクエリセットのみを定義する最も単純なリストビュー。
class MyExampleView(ListView);
model = ExampleModel
独自のテンプレートを提供する必要がありますが、基本的には最も基本的なModelAdminと同じです。モデル管理者のlist_display属性は、表示するフィールドを指示しますが、ListViewでは、テンプレートでこれを行います。
class SpeciesAdmin(admin.ModelAdmin):
list_display = ['name']
admin.site.register(ExampleModel , ExampleModelAdmin)
管理者にはパラメータがあります
list_per_page = 100
これは、ページごとのオブジェクトの数を定義します。リストビューには
paginate_by = 100
同じことを達成します。同様に、管理者を大幅にカスタマイズすることを検討すると、多くの重複が見られます。
ここにあるこのサイトは、彼らが何をしているのかについてのより良いアイデアをあなたに与えるはずです。