Tampilan berdasarkan-kelas menyediakan cara alternatif untuk menerapkan tampilan sebagai obyek Python daripada fungsi. Mereka tidak mengganti tampilan berdasarkan-fungsi, tetapi mempunyai perbedaan dan keuntungan tertentu ketika dibandingkan pada tampilan berdasarkan-fungsi:
\nKode organisasi terkait pada metode HTTP tertentu (GET, POST, dll.) dapat dialamatkan oleh metode terpisah sebagai gantinya dari percabangan bersyarat.
Teknik-teknik berorientasi obyek seperti mixin (banyak warisan) dapat digunakan pada kode faktor kedalam komponen digunakan kembali.
Dalam permulaan ada hanya kontrak fungsi tampilan, Django melewatkan fungsi anda sebuah HttpRequest dan berharap kembali sebuah HttpResponse. Ini adalah perpanjangan dari apa Django sediakan.
Lebih awal pada itu telah dikenali dimana ada dialek umum dan pola ditemukan di pengembangan tampilan. Tampilan umum berdasarkan-fungsi telah diperkenalkan untuk meringkas pola ini dan pengembangan tampilan mudah untuk kasus-kasus umum.
\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.
\nTampilan umum berdasarkan-kelas telah dibuat dengan tujuan sama sebagai tampilan umum berdasarkan-fungsi, untuk membuat tampilan pengembangan lebih mudah. Bagaimanapun, cara pemecahan diterapkan, melalui penggunaan dari mixin, menyediakan sebuah alat bantu yang menghasilkan di tampilan umum berdasarkan-kelas menjadi lebih diperpanjang dan lentur daripada pasangan berdasarkan-fungsi mereka.
\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.
Pada intinya, tampilan berdasarkan-kelas mengizinkan anda menanggapi ke permintaan HTTP berbeda dengan metode instance kelas berbeda, daripada dengan kode cabang bersyarat didalam fungsi tampilan tunggal.
\nJadi dimana kode untuk menangani HTTP GET di sebuah fungsi tampilan akan terlihat seperti:
from django.http import HttpResponse\n\ndef my_view(request):\n if request.method == 'GET':\n # <view logic>\n return HttpResponse('result')\nDi tampilan berdasarkan-kelas, ini akan menjadi:
\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]\nItu perlu dicatat bahwa apa metode anda kembalikan mirip ke apa anda kembalikan dari tampilan berdasarkan-fungsi, yaitu beberapa formulir dari HttpResponse. Ini berarti bahwa obyek http shortcuts atau TemplateResponse sah digunakan didalam tampilan berdasarkan-kelas.
Selagi tampilan berdasarkan-kelas paling rendah tidak membutuhkan atribut kelas apapun untuk melakukan pekerjaannya, atribut kelas berguna di banyak perancangan berdasarkan-kelas, dan ada dua cara mengkonfigurasi atau mensetel atribut kelas.
\nPertama adalah cara Python standar dari mensubkelaskan dan menimpa atribut dan metode di subkelas. Sehingga jika induk anda mempunyai sebuah atribut greeting seperti ini:
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)\nAnda dapat menimpa itu di subkelas:
\nclass MorningGreetingView(GreetingView):\n greeting = "Morning to ya"\nPilihan lain adalah mengkonfigurasi atribut kelas sebagai argumen kata kunci pada panggailan as_view() di URLconf:
urlpatterns = [\n path('about/', GreetingView.as_view(greeting="G'day")),\n]\nMixin adalah sebuah formulit dari banyak warisan dimana perilaku dan atribut dari banyak kelas-kelas induk dapat dipadukan
\nSebagai contoh, di tampilan berdasarkan-kelas umum adalah sebuah mixin dipanggil TemplateResponseMixin yang tujuan utamanya adalah menentukan metode render_to_response(). Ketika memadukan dengan perilaku dari kelas dasar View, hasil adalah kelas TemplateView yang akan mengirim permintaan ke metode pencocokan sesuai (sebuah perilaku ditentukan di kelas dasar View), dan itu mempunyai sebuah metode render_to_response() yang menggunakan sebuah atribut template_name untuk mengembalikan sebuah obyek TemplateResponse (sebuah perilaku ditentukan di TemplateResponseMixin).
Mixin adalah sebuah cara istimewa dari menggunakan kembali kode terhadap banyak kelas, tetapi mereka datang dengan beberapa biaya. Semakin kode anda tersebar diantara mixin, semakin keras itu akan dibaca kelas anak dan mengetahui apa yang sebenarnya itu lakukan, dan semakin keras itu akan diketahui metode mana dari mixin mana untuk ditimpa jika anda mensubkelaskan sesuatu yang mempunyai pohon warisan dalam.
\nCatat juga bahwa anda dapat hanya mewarisi dari satu tampilan umum - yaitu, hanya satu kelas induk mungkin mewarisi dari View dan sisa (jika ada) harus berupa mixin. Mencoba mewarisi lebih dari satu kelas yang mewarisi dari View - sebagai contoh, mencoba menggunakan sebuah formulir pada atas dari daftar dan memadukan ProcessFormView dan ListView - tidak bekerja sesuai harapan.
Sebuah dasar tampilan berdasarkan-fungsi yang menangani formulir mungkin terlihat sesuatu seperti ini:
\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})\nTampilan berdasarkan-kelas yang mirip mungkin terlihat seperti:
\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!).
Tambahan dari tampilan berdasarkan-kelas tidak terbatas menggunakan mixin. Anda dapat juga menggunakan penghias. Sejak tampilan berdasarkan-kelas bukan fungsi, mengias mereka bekerja secara berbeda tergantung pada jika anda sedang menggunakan as_view() atau membuat sebuah subkelas.
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]\nPendekatan ini memberlakukan penghias pada dasar per-instance. Jika anda ingin setiap instance dari tampilan dihias, anda butuh mengambil pendekatan berbeda.
\nUntuk menghias setiap instance dari tampilan berdasarkan-kelas, anda butuh menghias pengertian kelas itu sendiri. Untuk melakukan ini anda berlakukan penghias ke metode dispatch() dari kelas.
Sebuah metode pada sebuah kelas tidak agak sama seperti fungsi berdiri sendiri, jadi anda tidak hanya memberlakukan penghias fungsi ke metode -- anda butuh merubah itu menjadi penghias metode dahulu. Penghias method_decorator merubah sebuah penghias fungsi kedalam penghias metode sehingga itu dapat digunakan pada metode instance. Sebagai contoh:
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)\nAtau, lebih ringkas, anda dapat menghias kelas dan melewatkan nama dari metode untuk di hias sebagai argumen kata kunci name:
@method_decorator(login_required, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\nJika anda mempunyai sekumpulan penghias umum digunakan di beberapa tempat, anda dapat menentukan daftar atau tuple dari penghias dan menggunakan ini sebagai gantinya meminta method_decorator() berulang kali. Kedua kelas ini adalah setara:
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'\nPenghias akan mengolah sebuah permintaan dalam urutan mereka dilewatkan ke penghias. Dalam contoh, never_cache() akan mengolah permintaan sebelum 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.