Writing web applications can be monotonous, because we repeat certain patterns\nagain and again. Django tries to take away some of that monotony at the model\nand template layers, but web developers also experience this boredom at the view\nlevel.
\ntampilan umum Django dikembangkan untuk memudahkan sakit itu. Mereka mengambil dialek umum tertentu dan pola ditemukan di pengembangan tampilan dan meringkaskan mereka sehingga anda dapat dengan cepat menulis tampilan umum dari data tanpa harus menulis kode terlalu banyak.
\nKami dapat mengenali tugas-tugas umum, seperti memperlihatkan daftar dari obyek, dan menulis kode yang memperlihatkan daftar dari obyek apapun. Kemudian model di pertanyaan dapat dilewatkan sebagai sebuah argumen tambahan pada URLconf.
\nDjango dibungkus dengan tampilan umum untuk melakukan berikut:
\nMemperlihatkan daftar dan halaman rincian untuk obyek tunggal. Jika kami sedang membuat sebuah aplikasi untuk mengelola pertemuan kemudian TalkListView dan RegisteredUserListView akan menjadi contoh dari daftar tampilan. Halaman percakapan tunggal adalah sebuah contoh dari apa kami sebut tampilan "detail".
Obyek berdasarkan-tanggal sekarang di halaman arsip tahun/bulan/hari, rincian terkait, dan halaman "latest".
Mengizinkan untuk membuat, memperbaharui, dan menghapus obyek -- dengan atau tanpa otorisasi.
Taken together, these views provide interfaces to perform the most common tasks\ndevelopers encounter.
\nTidak ada pertanyaan yang menggunakan tampilan umum yang dapat mempercepat pengembangan besar. Dalam kebanyakan proyek, bagaimanapun, ada datang saat ketika tampilan umum tidak lagi cukup. Memang, pertanyaan paling umum ditanyakan oleh pengembang Django baru adalah bagaimana membuat tampilan umum menangangi larik lebih lebar dari keadaan.
\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.
\nItu dikatakan, tampilan umum akan mempunyai sebuah batasan. Jika anda menemukan anda sedang berjuang menerapkan tampilan anda sebagai sebuah subkelas dari tampilan umum, kemudian anda mungkin menemukan itu lebih efektif untuk menulis hanya kode anda butuhkan, menggunakan berdasarkan-kelas anda sendiri atau tampilan kegunaan.
\nContoh-contoh lebih dari tampilan umum tersedia di beberapa aplikasi pihak ketiga, atau anda dapat menulis anda sendiri sesuai kebutuhan.
\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.
Mari kita mulai dengan mencari beberapa contoh dari menunjukkan daftar dari obyek atau obyek tersendiri.
\nKami akan menggunakan model ini
\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()\nSekarang kami butuh menentukan sebuah tampilan:
\n# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\nclass PublisherListView(ListView):\n model = Publisher\nAkhirnya kaitkan tampilan itu kedalam url anda
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherListView\n\nurlpatterns = [\n path('publishers/', PublisherListView.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 %}\nItu semua benar-benar ada adalah pada itu. Semua fitur-fitur keren dari tampilan umum datang dari merubah atribut disetel pada tampilan umum. generic views reference mendokumentasikan semua tampilan umum dan pilihan mereka di rincian; sisa dari dokumen ini akan dianggap beberapa dari cara umum anda mungkin menyesuaikan dan memperpanjang tampilan umum.
\nAnda mungkin telah memperhatikan bahwa contoh cetakan daftar penerbit kami menyimpan semua penerbit dalam sebuah variabel bernama object_list. Selagi ini bekerja baik, itu tidak semua yang "friendly" pada cetakan penulis: mereka harus "just know" bahwa mereka sedang berurusan dengan penerbit disini.
Well, 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.
Jika ini masih tidak kecocokan baik, anda dapat manual menyetel nama dari variabel konteks. Atribut context_object_name pada tampilan umum menentukan variabel konteks untuk digunakan:
# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\nclass PublisherListView(ListView):\n model = Publisher\n context_object_name = 'my_favorite_publishers'\nMenyediakan sebuah context_object_name berguna selalu ide bagus. Rekan kerja anda yang merancang cetakan akan berterima kasih.
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 PublisherDetailView(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\nSekarang mari kita lebih dekat melihat pada argumen model kami telah sepanjang gunakan. Argumen model, yang menentukan model basisdata yang tampilan akan beroperasi, tersedia pada seua tampilan umum yang beroperasi pada obyek tunggal atau kumpulan dari obyek. Bagaimanapun, argumen model tidak hanya cara untuk menentukan obyek yang tampilan akan beroperasi -- anda dapat juga menentukan daftar dari obyek menggunakan argumen queryset:
from django.views.generic import DetailView\nfrom books.models import Publisher\n\nclass PublisherDetailView(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 Membuat query for more information about\nQuerySet objects, and see the\nclass-based views reference for the\ncomplete details).
Untuk mengambil sebuah contoh, kami mungkin ingin memesan buku berdasarkan tanggal terbitan, dengan yang paling baru dahulu:
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass BookListView(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. You'll\nusually want to do more than just reorder objects. If you want to present a\nlist of books by a particular publisher, you can use the same technique:
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass AcmeBookListView(ListView):\n\n context_object_name = 'book_list'\n queryset = Book.objects.filter(publisher__name='ACME Publishing')\n template_name = 'books/acme_list.html'\nikan bahwa selama dengan queryset disaring, kami juga menggunakan nama cetakan penyesuaian. Jika kami tidak, tampilan umum akan menggunakan cetakan sama seperti daftar obyek "vanilla", yang mungkin tidak kita inginkan.
Juga perharikan bahwa ini bukan cara sangat elegan dari melakukan buku khusus-penerbit. Jika kami ingin menambah halaman penerbit lain, kami butuh bantuan lain dari baris di URLconf, dan lebih dari sedikit penerbit akan mendapatkan alasan tidak masuk akal. Kami akan berurusan dengan masalah ini di bagian selanjutnya.
\n\nKebutuhan umum lain adalah menyaring kebawah obyek yang diberikan di halaman daftar dengan beberapa kunci di URL. Awalnya kami mengkode-keraskan nama penerbit di URLconf, tetapi apa jika kami ingin menulis sebuah tampilan yang menampilkan semua buku oleh beberapa penerbit berubah-ubah?
\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.
Bagian kunci membiat ini bekerja adalah bahwa ketika tampilan berdasarkan-kelas dipanggil, beragam hal-hal berguna disimpan di self; sama halnya permintaan (self.request) ini menyertakan penempatan (self.args) dan argumen (self.kwargs) berdasarkan-nama menurut URLconf.
Disini, kami mempunyai URLconf dengan kelompok ditangkap tunggal:
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherBookListView\n\nurlpatterns = [\n path('books/<publisher>/', PublisherBookListView.as_view()),\n]\nNext, we'll write the PublisherBookListView view itself:
# views.py\nfrom django.shortcuts import get_object_or_404\nfrom django.views.generic import ListView\nfrom books.models import Book, Publisher\n\nclass PublisherBookListView(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.
Kami dapat juga menambahkan penerbit kedalam konteks pada waktu bersamaan, jadi kami dapat menggunakannya di cetakan:
\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\nPola umum terakhir kami akan lihat pada melibatkan melakukan beberapa pekerjaan tambahan sebelum atau sesudah memanggil tampilan umum.
\nBayangkan kami mempunyai sebuah bidang last_accessed di model Author kami yang kami sedang gunakanuntuk menjaga lintas dari waktu terakhir siapapun mencari penulis itu:
# 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()\nThe generic DetailView class wouldn't know anything about this field, but\nonce again we could write a custom view to keep that field updated.
Pertama, kami butuh menambah rincian seorang penulis sedikit dalam URLconf untuk menunjuk pada tampilan penyesuaian:
\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