Perkenalan ke tampilan berdasarkan-kelas

Hubungan dan riwayat dari tampilan umum, tampilan berdasarkan-kelas, dan tampilan umum berdasarkan-kelas

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.

The problem with function-based generic views is that while they covered the simple cases well, there was no way to extend or customize them beyond some configuration options, limiting their usefulness in many real-world applications.

Tampilan 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.

If you have tried function based generic views in the past and found them lacking, you should not think of class-based generic views as a class-based equivalent, but rather as a fresh approach to solving the original problems that generic views were meant to solve.

Toolkit dari kelas dasar dan mixin yang digunakan Django untuk membangun tampilan generik berbasis kelas dibangun untuk fleksibilitas maksimum, dan dengan demikian memiliki banyak pengait dalam bentuk penerapan metode standar dan atribut yang tidak mungkin anda pedulikan dalam penggunaan yang paling sederhana kasus. Misalnya, alih-alih membatasi anda pada atribut berbasis kelas untuk form_class, implementasinya menggunakan metode get_form, yang memanggil metode get_form_class, yang dalam implementasi defaultnya mengembalikan `` atribut form_class`` dari kelas. Ini memberi anda beberapa opsi untuk menentukan formulir apa yang akan digunakan, dari atribut, hingga hook yang dapat dipanggil dan sepenuhnya dinamis. Pilihan ini tampaknya menambah kerumitan kosong untuk situasi sederhana, tetapi tanpanya, rancangan yang lebih canggih akan terbatas.

Menggunakan tampilan berdasarkan-kelas

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.

Jadi dimana kode untuk menangani HTTP GET di sebuah fungsi tampilan akan terlihat seperti:

from django.http import HttpResponse


def my_view(request):
    if request.method == "GET":
        # <view logic>
        return HttpResponse("result")

Di tampilan berdasarkan-kelas, ini akan menjadi:

from django.http import HttpResponse
from django.views import View


class MyView(View):
    def get(self, request):
        # <view logic>
        return HttpResponse("result")

Karena penyelesai URL Django berharap mengirim permintaan dan argumen terkait ke fungsi yang dapat dipanggil, bukan kelas, tampilan berbasis kelas memiliki metode kelas as_view() yang mengembalikan fungsi yang dapat dipanggil saat permintaan tiba untuk URL yang cocok dengan pola terkait. Fungsi membuat turunan dari kelas, memanggil setup() untuk menginisialisasi atributnya, dan kemudian memanggil dis(). dis melihat permintaan untuk menentukan apakah itu GET, POST, dll, dan meneruskan permintaan ke metode yang cocok jika ada yang ditentukan, atau memunculkan HttpResponseNotAllowed jika tidak:

# urls.py
from django.urls import path
from myapp.views import MyView

urlpatterns = [
    path("about/", MyView.as_view()),
]

Itu 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.

Pertama 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
from django.views import View


class GreetingView(View):
    greeting = "Good Day"

    def get(self, request):
        return HttpResponse(self.greeting)

Anda dapat menimpa itu di subkelas:

class MorningGreetingView(GreetingView):
    greeting = "Morning to ya"

Pilihan lain adalah mengkonfigurasi atribut kelas sebagai argumen kata kunci pada panggailan as_view() di URLconf:

urlpatterns = [
    path("about/", GreetingView.as_view(greeting="G'day")),
]

Menggunakan mixin

Mixin adalah sebuah formulit dari banyak warisan dimana perilaku dan atribut dari banyak kelas-kelas induk dapat dipadukan

Sebagai 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.

Catat 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.

Menangani formulir dengan tampilan berdasarkan-kelas

Sebuah dasar tampilan berdasarkan-fungsi yang menangani formulir mungkin terlihat sesuatu seperti ini:

from django.http import HttpResponseRedirect
from django.shortcuts import render

from .forms import MyForm


def myview(request):
    if request.method == "POST":
        form = MyForm(request.POST)
        if form.is_valid():
            # <process form cleaned data>
            return HttpResponseRedirect("/success/")
    else:
        form = MyForm(initial={"key": "value"})

    return render(request, "form_template.html", {"form": form})

Tampilan berdasarkan-kelas yang mirip mungkin terlihat seperti:

from django.http import HttpResponseRedirect
from django.shortcuts import render
from django.views import View

from .forms import MyForm


class MyFormView(View):
    form_class = MyForm
    initial = {"key": "value"}
    template_name = "form_template.html"

    def get(self, request, *args, **kwargs):
        form = self.form_class(initial=self.initial)
        return render(request, self.template_name, {"form": form})

    def post(self, request, *args, **kwargs):
        form = self.form_class(request.POST)
        if form.is_valid():
            # <process form cleaned data>
            return HttpResponseRedirect("/success/")

        return render(request, self.template_name, {"form": form})

Ini adalah kasus minimal, tetapi anda dapat melihat bahwa anda akan memiliki opsi untuk menyesuaikan tampilan ini dengan mengganti salah satu atribut kelas, mis. form_class, melalui konfigurasi URLconf, atau membuat subkelas dan mengganti satu atau lebih metode (atau keduanya!).

Menghias tampilan berdasarkan-kelas

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.

from django.contrib.auth.decorators import login_required, permission_required
from django.views.generic import TemplateView

from .views import VoteView

urlpatterns = [
    path("about/", login_required(TemplateView.as_view(template_name="secret.html"))),
    path("vote/", permission_required("polls.can_vote")(VoteView.as_view())),
]

from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator
from django.views.generic import TemplateView


class ProtectedView(TemplateView):
    template_name = "secret.html"

    @method_decorator(login_required)
    def dis(self, *args, **kwargs):
        return super().dis(*args, **kwargs)

@method_decorator(login_required, name="dis")
class ProtectedView(TemplateView):
    template_name = "secret.html"

decorators = [never_cache, login_required]


@method_decorator(decorators, name="dis")
class ProtectedView(TemplateView):
    template_name = "secret.html"


@method_decorator(never_cache, name="dis")
@method_decorator(login_required, name="dis")
class ProtectedView(TemplateView):
    template_name = "secret.html"