Tampilan berdasarkan-kelas siap-pakai Django menyediakan banyak fungsionalitas, tetapi beberapa dari itu anda mungkin ingin menggunakannya terpisah. Sebagai contoh, anda mungkin ingin menulis sebuah tampilan yang membangun cetakan untuk membuat tanggapan HTTP, tetapi anda tidak dapat menggunakan TemplateView; mungkin anda butuh membangun cetakan hanya pada POST, dengan GET melakukan sesuatu lain seluruhnya. Selagi anda dapat menggunakan TemplateResponse langsung, ini akan kemungkinan hasil di kode ganda.
Untuk alasan ini, Django juga menyediakan sejumlah mixin yang menyediakan fungsionalitas diskrit lebih. Pembangunan cetakan, sebagai contoh, dienkapsulasi di TemplateResponseMixin. Dokumentasi acuan Django mengandung full documentation of all the mixins.
Dua mixin pusat disediakan yang membantu dalam antarmuka tetap untuk bekerja dengan cetakan di tampilan berdasarkan-kelas.
\nTemplateResponseMixinEvery built in view which returns a\nTemplateResponse will call the\nrender_to_response()\nmethod that TemplateResponseMixin provides. Most of the time this\nwill be called for you (for instance, it is called by the get() method\nimplemented by both TemplateView and\nDetailView); similarly, it's unlikely\nthat you'll need to override it, although if you want your response to\nreturn something not rendered via a Django template then you'll want to do\nit. For an example of this, see the JSONResponseMixin example.
render_to_response() itself calls\nget_template_names(),\nwhich by default will look up\ntemplate_name on\nthe class-based view; two other mixins\n(SingleObjectTemplateResponseMixin\nand\nMultipleObjectTemplateResponseMixin)\noverride this to provide more flexible defaults when dealing with actual\nobjects.
ContextMixinEvery built in view which needs context data, such as for rendering a\ntemplate (including TemplateResponseMixin above), should call\nget_context_data() passing\nany data they want to ensure is in there as keyword arguments.\nget_context_data() returns a dictionary; in ContextMixin it\nreturns its keyword arguments, but it is common to override this to add\nmore members to the dictionary. You can also use the\nextra_context attribute.
Mari kita lihat bagaimana tampilan berdasarkan-kelas umum Django adalah membangun dari mixin disediakan fungsionalitas diskrit. Kami akan mempertimbangkan DetailView, yang membangun tampilan "detail" dari sebuah obyek, dan ListView, yang akan membangun sebuah daftar dari obyek, khususnya dari queryset, dan pilihannya memberi nomor mereka. Ini akan memperkenalkan kita untuk empat mixin yang diantara mereka menyediakan fungsionalitas berguna dengan antara obyek Django tunggal, atau banyak obyek.
Ada juga mixin terlibat di tampilan sunting umum (FormView, dan tampilan model-tertentu CreateView, UpdateView dan DeleteView), dan di tampilan umum berdasarkan-tanggal. Ini dicakupi di mixin reference documentation.
DetailView: bekerja dengan obyek tunggal DjangoLink to this heading#Untuk menunjukkan rincian dari sebuah obyek, kami dasarnya butuh melakukan dua hal: kami butuh mencari obyek dan kemudian kami butuh membuat TemplateResponse dengan cetakan yang cocok, dan obyek itu sebagai konteks.
To get the object, DetailView\nrelies on SingleObjectMixin,\nwhich provides a\nget_object()\nmethod that figures out the object based on the URL of the request (it\nlooks for pk and slug keyword arguments as declared in the\nURLConf, and looks the object up either from the\nmodel attribute\non the view, or the\nqueryset\nattribute if that's provided). SingleObjectMixin also overrides\nget_context_data(),\nwhich is used across all Django's built in class-based views to supply\ncontext data for template renders.
To then make a TemplateResponse,\nDetailView uses\nSingleObjectTemplateResponseMixin, which\nextends TemplateResponseMixin, overriding\nget_template_names() as\ndiscussed above. It actually provides a fairly sophisticated set of options,\nbut the main one that most people are going to use is\n<app_label>/<model_name>_detail.html. The _detail part can be changed\nby setting\ntemplate_name_suffix\non a subclass to something else. (For instance, the generic edit views use _form for create and\nupdate views, and _confirm_delete for delete views.)
ListView: bekerja dengan banyak obyek DjangoLink to this heading#Daftar dari obyek mengikuti kurang lebih pola sama: kami butuh sebuah (kemungkinan diberikan nomor) daftar obyek, khususnya sebuah QuerySet, dan kemudian kami butuh membuat sebuah TemplateResponse dengan cetakan cocok menggunakan daftar itu dari obyek.
Untuk mendapatkan objek, ListView menggunakan MultipleObjectMixin, yang menyediakan get_queryset() dan paginate_queryset(). Berbeda dengan SingleObjectMixin, tidak perlu untuk mengunci bagian dari URL untuk mengetahui kumpulan permintaan yang akan digunakan, jadi awalan menggunakan queryset atau model pada kelas tampilan. Alasan umum untuk mengesampingkan get_queryset() di sini adalah untuk memvariasikan objek secara dinamis, seperti bergantung pada pengguna saat ini atau untuk mengecualikan kiriman di masa mendatang untuk blog.
MultipleObjectMixin also overrides\nget_context_data() to\ninclude appropriate context variables for pagination (providing\ndummies if pagination is disabled). It relies on object_list being\npassed in as a keyword argument, which ListView arranges for\nit.
To make a TemplateResponse,\nListView then uses\nMultipleObjectTemplateResponseMixin.\nAs with SingleObjectTemplateResponseMixin\nabove, this overrides\nget_template_names()\nto provide a range of options, with the most commonly-used being\n<app_label>/<model_name>_list.html, with the _list part again\nbeing taken from the\ntemplate_name_suffix\nattribute. (The date based generic views use suffixes such as _archive,\n_archive_year and so on to use different templates for the various\nspecialized date-based list views.)
Now we've seen how Django's generic class-based views use the provided mixins,\nlet's look at other ways we can combine them. We're still going to be combining\nthem with either built-in class-based views, or other generic class-based\nviews, but there are a range of rarer problems you can solve than are provided\nfor by Django out of the box.
\n\nSingleObjectMixin dengan ViewLink to this heading#If we want to write a class-based view that responds only to POST, we'll\nsubclass View and write a post() method\nin the subclass. However if we want our processing to work on a particular\nobject, identified from the URL, we'll want the functionality provided by\nSingleObjectMixin.
We'll demonstrate this with the Author model we used in the generic\nclass-based views introduction.
views.pyfrom django.http import HttpResponseForbidden, HttpResponseRedirect\nfrom django.urls import reverse\nfrom django.views import View\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Author\n\n\nclass RecordInterestView(SingleObjectMixin, View):\n """Records the current user's interest in an author."""\n\n model = Author\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n\n # Look up the author we're interested in.\n self.object = self.get_object()\n # Actually record interest somehow here!\n\n return HttpResponseRedirect(\n reverse("author-detail", kwargs={"pk": self.object.pk})\n )\nIn practice you'd probably want to record the interest in a key-value\nstore rather than in a relational database, so we've left that bit\nout. The only bit of the view that needs to worry about using\nSingleObjectMixin is where we want to\nlook up the author we're interested in, which it does with a call to\nself.get_object(). Everything else is taken care of for us by the mixin.
Kami dapat menghubungkan kedalam URL kami dengan cukup mudah:
\nurls.pyfrom django.urls import path\nfrom books.views import RecordInterestView\n\nurlpatterns = [\n # ...\n path(\n "author/<int:pk>/interest/",\n RecordInterestView.as_view(),\n name="author-interest",\n ),\n]\nCatat kelompok bernama pk, yang get_object() menggunakan untuk mencari instance Author. Anda dapat juga menggunakan sebuah keong, atau apapun dari fitur-fitur lain dari SingleObjectMixin.
SingleObjectMixin dengan ListViewLink to this heading#ListView menyediakan penomoran siap-pakai, tetapi anda mungkin ingin memberi nomor daftar dari obyek yang semua terkait (oleh foreign key) ke obyek lain. Di contoh penerbitan kami, anda mungkin ingin memberi nomor melalui semua buku-buku oleh penerbit tertentu.
Satu cara melakukan ini adalah memadukan ListView dengan SingleObjectMixin, sehingga queryset untuk memberi nomor halaman dari buku dapat menggantung penerbit ditemukan sebagai obyek tunggal. Untuk melakukan ini, kami butuh memiliki dua queryset berbeda:
Book untuk digunakan oleh ListViewSince we have access to the Publisher whose books we want to list, we\noverride get_queryset() and use the Publisher’s reverse\nforeign key manager.
Publisher queryset for use in get_object()Kami akan bergantung pada penerapan awalan dari get_object() untuk mengambil obyek Publisher benar. Bagaimanapun, kami butuh jelas melewatkan sebuah argumen queryset karena jika tidak penerapan awalan dari get_object() akan memanggil get_queryset() yang kami telah timpa untuk mengembalikan obyek Book daripada Publisher.
Sekarang kami dapat menulis PublisherDetailView baru:
from django.views.generic import ListView\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Publisher\n\n\nclass PublisherDetailView(SingleObjectMixin, ListView):\n paginate_by = 2\n template_name = "books/publisher_detail.html"\n\n def get(self, request, *args, **kwargs):\n self.object = self.get_object(queryset=Publisher.objects.all())\n return super().get(request, *args, **kwargs)\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context["publisher"] = self.object\n return context\n\n def get_queryset(self):\n return self.object.book_set.all()\nPerhatikan bagaimana kami menyetel self.object dalam get() jadi kami dapat menggunakan itu kembali kemudian dalam get_context_data() dan get_queryset(). Jika anda tidak menyetel template_name, cetakan akan awalan menjadi pilihan ListView biasa, yang dalam kasus ini akan menjadi "books/book_list.html" karena itu adalah daftar dari buku-buku; ListView tidak mengetahui apapun tentang SingleObjectMixin, jadi itu tidak mempunyai petunjuk tampilan ini adalah hubungannya dengan Publisher.
paginate_by sengaja kecil dalam contoh sehingga anda tidak perlu membuat banyak buku untuk melihat penomoran halaman bekerja! Ini adalah cetakan anda ingin gunakan:
{% extends "base.html" %}\n\n{% block content %}\n <h2>Publisher {{ publisher.name }}</h2>\n\n <ol>\n {% for book in page_obj %}\n <li>{{ book.title }}</li>\n {% endfor %}\n </ol>\n\n <div class="pagination">\n <span class="step-links">\n {% if page_obj.has_previous %}\n <a href="?page={{ page_obj.previous_page_number }}">previous</a>\n {% endif %}\n\n <span class="current">\n Page {{ page_obj.number }} of {{ paginator.num_pages }}.\n </span>\n\n {% if page_obj.has_next %}\n <a href="?page={{ page_obj.next_page_number }}">next</a>\n {% endif %}\n </span>\n </div>\n{% endblock %}\nUmumnya anda dapat gunakan TemplateResponseMixin dan SingleObjectMixin ketika anda butuh fungsionalitas mereka. Seperti ditunjukkan diatas, dengan sedikit perawatan anda dapat bahkan memadukan SingleObjectMixin dengan ListView. Bagaimanapun hal-hal meningkat semakin rumit ketika anda mencoba melakukannya, dan aturan bagus dari ibu jari adalah:
Untuk menunjukkan apa yang terjadi ketika anda mencoba mendapatkan lebih mutakhir, kami menunjukkan sebuah contoh yang mengorbankan kesiapan dan rawatan ketika ada pemecahan termudah. Pertama, mari kita lihat usaha naif untuk memadukan DetailView dengan FormMixin untuk mengadakan kami pada POST sebuah Form Django ke URL sama ketika kami sedang memperlihatkan sebuah obyek menggunakan DetailView.
FormMixin dengan DetailViewLink to this heading#Berpikir kembali ke contoh paling awal dari menggunakan View dan SingleObjectMixin bersama-sama. Kami sedang merekam sebuah minat pengguna dalam penulis tertentu; katakan sekarang yang kami ingin membiarkan mereka meninggalkan pesan mengatakan mengapa mereka menyukainya. Kembali, mari kita anggap tidak menyimpan ini dalam basisdata hubungan tetapi sebagai gantinya di lebih esoterik yang kami tidak akan khawatir disini.
Pada titik ini itu adalah alamiah mencapai untuk Form untuk mengenkapsulasi informasi dikirim dari peramban pengguna pada Django. Katakan juga bahwa kami melakukan investasi di REST, jadi kami ingin menggunakan URL sama untuk memperlihatkan penulis sebagai untuk menangkap pesan dar pengguna. Mari kita menulis kembali AuthorDetailView kami untuk melakukan itu.
Kami akan menjaga penanganan GET dari DetailView, meskipun kami akan harus menambah Form kedalam data konteks jadi kami dapat mengirim itu dalam cetakan. Kami akan juga ingin menarik dalam pengolahan formulir FormMixin, dan menulis sedikit kode sehingga pada POST formulir mendapatkan panggilan yang sesuai.
AuthorDetailView kami yang baru terlihat seperti ini:
# CAUTION: you almost certainly do not want to do this.\n# It is provided as part of a discussion of problems you can\n# run into when combining different generic class-based view\n# functionality that is not designed to be used together.\n\nfrom django import forms\nfrom django.http import HttpResponseForbidden\nfrom django.urls import reverse\nfrom django.views.generic import DetailView\nfrom django.views.generic.edit import FormMixin\nfrom books.models import Author\n\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\n\nclass AuthorDetailView(FormMixin, DetailView):\n model = Author\n form_class = AuthorInterestForm\n\n def get_success_url(self):\n return reverse("author-detail", kwargs={"pk": self.object.pk})\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n self.object = self.get_object()\n form = self.get_form()\n if form.is_valid():\n return self.form_valid(form)\n else:\n return self.form_invalid(form)\n\n def form_valid(self, form):\n # Here, we would record the user's interest using the message\n # passed in form.cleaned_data['message']\n return super().form_valid(form)\nget_success_url() provides somewhere to redirect to, which gets used\nin the default implementation of form_valid(). We have to provide our\nown post() as noted earlier.
The number of subtle interactions between\nFormMixin and DetailView is\nalready testing our ability to manage things. It's unlikely you'd want to\nwrite this kind of class yourself.
In this case, you could write the post() method yourself, keeping\nDetailView as the only generic functionality, although writing\nForm handling code involves a lot of duplication.
Alternatively, it would still be less work than the above approach to\nhave a separate view for processing the form, which could use\nFormView distinct from\nDetailView without concerns.
Apa kami sedang coba lakukan disini adalah menggunakan dua kelas bebeda berdasarkan tampilan dari URL sama. Jadi mengapa tidak lakukan hal itu? Kami mempunyai pembagian sangat jelas disini: permintaan GET harus mendapatkan DetailView (dengan Form ditambahkan ke data konteks), dan permintaan POST harus mendapatkan FormView. Mari kita menyetek tampilan tersebut dahulu.
The AuthorDetailView view is almost the same as when we\nfirst introduced AuthorDetailView; we have to\nwrite our own get_context_data() to make the\nAuthorInterestForm available to the template. We'll skip the\nget_object() override from before for clarity:
from django import forms\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\n\nclass AuthorDetailView(DetailView):\n model = Author\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context["form"] = AuthorInterestForm()\n return context\nThen the AuthorInterestFormView is a FormView, but we have to\nbring in SingleObjectMixin so we can find\nthe author we're talking about, and we have to remember to set\ntemplate_name to ensure that form errors will render the same template as\nAuthorDetailView is using on GET:
from django.http import HttpResponseForbidden\nfrom django.urls import reverse\nfrom django.views.generic import FormView\nfrom django.views.generic.detail import SingleObjectMixin\n\n\nclass AuthorInterestFormView(SingleObjectMixin, FormView):\n template_name = "books/author_detail.html"\n form_class = AuthorInterestForm\n model = Author\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n self.object = self.get_object()\n return super().post(request, *args, **kwargs)\n\n def get_success_url(self):\n return reverse("author-detail", kwargs={"pk": self.object.pk})\nFinally we bring this together in a new AuthorView view. We\nalready know that calling as_view() on\na class-based view gives us something that behaves exactly like a function\nbased view, so we can do that at the point we choose between the two subviews.
You can pass through keyword arguments to\nas_view() in the same way you\nwould in your URLconf, such as if you wanted the AuthorInterestFormView\nbehavior to also appear at another URL but using a different template:
from django.views import View\n\n\nclass AuthorView(View):\n def get(self, request, *args, **kwargs):\n view = AuthorDetailView.as_view()\n return view(request, *args, **kwargs)\n\n def post(self, request, *args, **kwargs):\n view = AuthorInterestFormView.as_view()\n return view(request, *args, **kwargs)\nPendekatan ini dapat juga digunakan dengan tampilan berdasarkan-kelas umum lainnya diwarisi langsung dari View or TemplateView, ketika itu menjaga tampilan berbeda sebagai terpisah mungkin.
Dimana bersinar tampilan berdasarkan-kelas adalah ketika anda ingin melakukan hal sama sebanyak kali. Kiranya anda sedang menulis sebuah API, dan setiap tampilan harus mengembalikan JSON daripada membangun HTML.
\nKami dapat membuat sebuah kelas mixin untuk digunakan di semua dari tampilan kami, menangani perubahan pada JSON sekali.
\nSebagai contoh, mixin JSON mungkin terlihat seperti ini:
\nfrom django.http import JsonResponse\n\n\nclass JSONResponseMixin:\n """\n A mixin that can be used to render a JSON response.\n """\n\n def render_to_json_response(self, context, **response_kwargs):\n """\n Returns a JSON response, transforming 'context' to make the payload.\n """\n return JsonResponse(self.get_data(context), **response_kwargs)\n\n def get_data(self, context):\n """\n Returns an object that will be serialized as JSON by json.dumps().\n """\n # Note: This is *EXTREMELY* naive; in reality, you'll need\n # to do much more complex handling to ensure that arbitrary\n # objects -- such as Django model instances or querysets\n # -- can be serialized as JSON.\n return context\nThis mixin provides a render_to_json_response() method with the same\nsignature as\nrender_to_response().\nTo use it, we need to mix it into a TemplateView for example, and override\nrender_to_response() to call render_to_json_response() instead:
from django.views.generic import TemplateView\n\n\nclass JSONView(JSONResponseMixin, TemplateView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nEqually we could use our mixin with one of the generic views. We can make our\nown version of DetailView by mixing\nJSONResponseMixin with the\nBaseDetailView -- (the\nDetailView before template\nrendering behavior has been mixed in):
from django.views.generic.detail import BaseDetailView\n\n\nclass JSONDetailView(JSONResponseMixin, BaseDetailView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nTampilan ini dapat kemudian disebarkan dalam cara sama seperti lainnya DetailView, dengan persi perilaku sama -- kecuali untuk bentuk dari tanggapan.
If you want to be really adventurous, you could even mix a\nDetailView subclass that is able\nto return both HTML and JSON content, depending on some property of\nthe HTTP request, such as a query argument or an HTTP header. Mix in both the\nJSONResponseMixin and a\nSingleObjectTemplateResponseMixin,\nand override the implementation of\nrender_to_response()\nto defer to the appropriate rendering method depending on the type of response\nthat the user requested:
from django.views.generic.detail import SingleObjectTemplateResponseMixin\n\n\nclass HybridDetailView(\n JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView\n):\n def render_to_response(self, context):\n # Look for a 'format=json' GET argument\n if self.request.GET.get("format") == "json":\n return self.render_to_json_response(context)\n else:\n return super().render_to_response(context)\nBecause of the way that Python resolves method overloading, the call to\nsuper().render_to_response(context) ends up calling the\nrender_to_response()\nimplementation of TemplateResponseMixin.