Cukup umum dalam aplikasi jaringan, anda butuh memasang pesan pemberitahuan satu-waktu (juga dikenal sebagai "flash message") pada pengguna setelah pengolahan sebuah formulir aau beberapa jenis lain dari masukan pengguna.
\nUntuk ini, Django menyediakan dukungan penuh untuk oesan berdasarkan-kue dan sesi, untuk kedua pengguna anonim dan terautentifikasi. Kerangka kerja pesan mengizinkan anda secara sementara menyimpan pesan dalam satu permintaan dam mengambil mereka untuk ditampilkan dalam permintaan selanjutnya (biasanya satu selanjutnya). Setiap pesan dietiket dengan level khusus yang menentukan keutamaannya (misalnya, info, warning, atau error).
Pesan diterapkan melalui middleware class dan bersamaan context processor.
\nAwalan settings.py dibuat oleh django-admin startproject sudah mengandung semua pengaturan dibutuhkan untuk mengadakan pesan fungsionalitas:
'django.contrib.messages' di INSTALLED_APPS.
MIDDLEWARE mengandung 'django.contrib.sessions.middleware.SessionMiddleware' dan 'django.contrib.messages.middleware.MessageMiddleware'.
storage backend awalan bergantung pada sessions. Itu mengapa SessionMiddleware harus diadakan dan muncul sebelum MessageMiddleware dalam MIDDLEWARE.
Pilihan 'context_processors' dari backend DjangoTemplates ditentukan di pengaturan TEMPLATES anda mengandung 'django.contrib.messages.context_processors.messages'.
Jika anda tidak ingin menggunakan pesan-pesan, anda dapat memindahkan 'django.contrib.messages' dari INSTALLED_APPS anda, baris MessageMiddleware dari MIDDLEWARE, dan pengolah konteks messages dari TEMPLATES.
Kerangka kerja pesan-pesan dapat menggunakan backend berbeda untuk menyimpan pesan-pesan sementara.
\nDjango menyediakan kelas-kelas penyimpanan siap-pakai di django.contrib.messages:
Kelas ini menyimpan semua pesan didalam sesi permintaan. Karena itu membutuhkan aplikasi contrib.sessions Django.
Kelas ini menyimpan data pesan dalam sebuah kue (ditandai dengan campuran rahasia untuk mencegah perubahan) untuk bertahan pemberitahuan terhadap permintaan. Pesan-pesan lama dibuang jika ukuran data kue akan melebihi 2048 byte.
\nKelas ini pertama menggunakan CookieStorage, dan jatuh kembali menggunakan SessionStorage untuk pesan yang tidak cocok dalam kue tunggal. Itu juga membutuhkan aplikasi contrib.sessions Django.
Perilaku ini menghindari menulis ke sesi bilamana memungkinkan. Itu harus menyediakan penampilan terbaik di kasus umum.
\nFallbackStorage adalah kelas penyimpanan awalan. Jika itu tidak cocok pada kebutuhan anda, anda dapat memilih kelas penyimpanan lain dengan mengatur MESSAGE_STORAGE ke jalur impor penuhnya, sebagai contoh:
MESSAGE_STORAGE = "django.contrib.messages.storage.cookie.CookieStorage"\nUntuk menulis kelas penyimpanan sendiri, subkelas kelas BaseStorage di django.contrib.messages.storage.base dan menerapkan metode _get dan _store.
Kerangka kerja pesan berdasarkan pada tingkat arsitektur dapat dikonfigurasikan mirip pada modul pencatatan Python. Tingkatan pesan mengizinkan anda mengelompokkan pesan berdasarkan jenis sehingga mereka dapat disaring atau ditampilkan berbeda dalam tampilan atau cetakan.
\nTingkat siap-pakai, yang dapat diimpor dari django.contrib.messages secar langsung, adalah:
Ketetapan | \nMaksud | \n
|---|---|
| \nPesan-pesan terkait-pengembangan yang akan diabaikan (atau dipindahkan) dalam penyebaran produksi | \n
| \nPesan informasi untuk pengguna | \n
| \nSebuah tindakan telah berhasil, misalnya "Profil anda telah berhasil diperbaharui". | \n
| \nKegagalan tidak muncul tetapi mungkin sebentar lagi | \n
| \nSebuah tindakan tidak berhasil atau beberapa kegagalan lain muncul | \n
Pengaturan MESSAGE_LEVEL dapat digunakan merubah tingkat perekaman minimal (atau itu dapat berupa changed per request). Usaha-usaha untuk menambahkan pesan-pesan dari tingkatan kurang dari ini akan diabaikan.
Untuk menambahkan pesan, panggil:
\nfrom django.contrib import messages\n\nmessages.add_message(request, messages.INFO, "Hello world.")\nBeberapa metode jalan pintas menyediakan cara standar untuk menambah pesan-pesan dengan umumnya menggunakan etiket-etiket (yang biasanya diwakili sebagai kelas-kelas HTML untuk pesan):
\nmessages.debug(request, "%s SQL statements were executed." % count)\nmessages.info(request, "Three credits remain in your account.")\nmessages.success(request, "Profile details updated.")\nmessages.warning(request, "Your account expires in three days.")\nmessages.error(request, "Document deleted.")\nIn your template, use something like:
\n{% if messages %}\n<ul class="messages">\n {% for message in messages %}\n <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li>\n {% endfor %}\n</ul>\n{% endif %}\nJika anda sedang menggunakan pengolah konteks, cetakan anda harus dibangun dengan RequestContext. Sebaliknya, apstikan messages tersedia pada konteks cetakan.
Even if you know there is only one message, you should still iterate over the\nmessages sequence, because otherwise the message storage will not be\ncleared for the next request.
The context processor also provides a DEFAULT_MESSAGE_LEVELS variable which\nis a mapping of the message level names to their numeric value:
{% if messages %}\n<ul class="messages">\n {% for message in messages %}\n <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>\n {% if message.level == DEFAULT_MESSAGE_LEVELS.ERROR %}Important: {% endif %}\n {{ message }}\n </li>\n {% endfor %}\n</ul>\n{% endif %}\nDiluar Cetakan, anda dapat menggunakan get_messages():
from django.contrib.messages import get_messages\n\nstorage = get_messages(request)\nfor message in storage:\n do_something_with_the_message(message)\nSebagai contoh, anda dapat mengambil semua pesan-pesan untuk mengembalikan mereka di JSONResponseMixin daripada TemplateResponseMixin.
get_messages() akan mengembalikan sebuah instance dari backend penyimpanan dikonfigurasi
MessageLink to this heading#When you loop over the list of messages in a template, what you get are\ninstances of the Message class. They have only a few attributes:
message: Teks sebenarnya dari pesan.
level: Integer menggambarkan jenis dari pesan (lihat bagian message levels diatas).
tags: String memadukan semua etiket pesan (extra_tags dan level_tag) dipisahkan oleh ruang.
extra_tags: Sebuah string mengandung etiket-etiket penyesuaian untuk pesan ini, dipisahkan oleh ruang. Itu kosong secara awalan.
level_tag: Perwakilan string dari tingkatan. Secara awalan, itu adalah versi huruf kecil dari nama dari ketetapan terkait, tetapi ini dapat berubah jika anda butuh dengan menggunakanpengaturan MESSAGE_TAGS.
Tingkatan pesan tidak lebih dari integer, jadi anda dapat menentukan ketetapan tingkat anda sendiri dan menggunakan mereka membuat umpan balik pengguna penyesuaian lagi, misalnya:
\nCRITICAL = 50\n\n\ndef my_view(request):\n messages.add_message(request, CRITICAL, "A serious error occurred.")\nKetika membuat tingkatan-tingkatan pesan penyesuaian anda harus waspada menghindari tingkatan-tingkatan yang ada kelebihan beban. Nilai-nilai untuk tingkatan-tingkatan siap-pakai adalah:
\nTingkat Ketetapan | \nNilai | \n
|---|---|
| \n10 | \n
| \n20 | \n
| \n25 | \n
| \n30 | \n
| \n40 | \n
Jika anda buth mencirikan tingkatan penyesuaian dalam HTML atau CSS, anda butuh menyediakan sebuah pemetaan melalui pengaturan MESSAGE_TAGS.
Tingkat terekam minimal dapat disetel per permintaan melalui metode set_level:
from django.contrib import messages\n\n# Change the messages level to ensure the debug message is added.\nmessages.set_level(request, messages.DEBUG)\nmessages.debug(request, "Test message...")\n\n# In another request, record only messages with a level of WARNING and higher\nmessages.set_level(request, messages.WARNING)\nmessages.success(request, "Your profile was updated.") # ignored\nmessages.warning(request, "Your account is about to expire.") # recorded\n\n# Set the messages level back to default.\nmessages.set_level(request, None)\nMirip, tingkat efektif saat ini dapat diambil dengan get_level:
from django.contrib import messages\n\ncurrent_level = messages.get_level(request)\nUntuk informasi lebih pada bagaimana fungsi tingkat terekam minimal, lihat Message levels diatas.
\nJika anda sedang menulis sebuah aplikasi digunakan kembali (atau potongan lain dari kode) dan ingin menyertakan kegunaan pesan, tetapi tidak ingin membutuhkan pengguna anda mengadakan itu jika mereka tidak ingin, anda mungkin melewatkan sebuah argumen kata kunci tambahan fail_silently=True ke apapun dari keluarga add_message dari metode-metode. Sebagai contoh:
messages.add_message(\n request,\n messages.SUCCESS,\n "Profile details updated.",\n fail_silently=True,\n)\nmessages.info(request, "Hello world.", fail_silently=True)\nMenambah sebuah atribut pesan berhasil pada FormView berdasarkan kelas-kelas
cleaned_data adalah data dibersihkan dari formulir yang digunakan untuk pembentukan string
Contoh views.py:
\nfrom django.contrib.messages.views import SuccessMessageMixin\nfrom django.views.generic.edit import CreateView\nfrom myapp.models import Author\n\n\nclass AuthorCreateView(SuccessMessageMixin, CreateView):\n model = Author\n success_url = "/success/"\n success_message = "%(name)s was created successfully"\nData diberishkan dari form tersedia untuk penambahan string menggunakan sintaksis %(field_name)s. Untuk ModelForms, jika anda butuh mengakses ke bidang-bidang ini dari object tersimpan timpa metode get_success_message().
Contoh views.py untuk ModelForms:
\nfrom django.contrib.messages.views import SuccessMessageMixin\nfrom django.views.generic.edit import CreateView\nfrom myapp.models import ComplicatedModel\n\n\nclass ComplicatedCreateView(SuccessMessageMixin, CreateView):\n model = ComplicatedModel\n success_url = "/success/"\n success_message = "%(calculated_field)s was created successfully"\n\n def get_success_message(self, cleaned_data):\n return self.success_message % dict(\n cleaned_data,\n calculated_field=self.object.calculated_field,\n )\nPesan-pesan ditandai untuk dibersihkan ketika contoh penyimpanan diulangkan (dan dibersihkan ketika tanggapan diolah).
\nUntuk menghindari pesan-pesan sedang dibesihkan, anda dapat menyetel penyimpanan pesan-pesan menjadi False setelah perulangan:
storage = messages.get_messages(request)\nfor message in storage:\n do_something_with(message)\nstorage.used = False\nDisebabkan oleh cara kue (dan karena itu sesi) bekerja, perilaku backend apapun yang menggunakan kue atau sesi tidak ditentukan ketika klien sama membuat banyak permintaan yang mensetel atau mendapatkan pesan-pesan sejajar. Sebagai contoh, jika sebuah klien memulai sebuah permintaan yang membuat sebuah pesan dalam satu jendela (atau tab) dan kemudian yang mengambil pesan-pesan apapun tidak berstatus di jendela lain, sebelum jendela pertama dialihkan, pesan mungkin muncul dalam jendela kedua darpada jendela pertama dimana itu mungkin diharapkan.
\nRingkasnya, ketika permintaan-permintaan terus-menerus banyak dari klien sama dilibatkan, pesan-pesan tidak dijamin untuk dikirimkan ke jendela sama yang maupun membuat mereka, dalam beberapa kasus, sama sekali. Catat bahwa ini adalah khususnya bukan sebuah masalah dalam kebanyakan aplikasi dan akan menjadi bukan-masalah dalam HTML5, dimana setiap jendela/tab akan mempunyai konteks menjelajah milik sendiri.
\nSedikit settings memberikan anda kendali terhadap perilaku pesan:
\n\nUntuk backend yang menggunakan kue, pengaturan untuk kue diambil dari pengaturan kue sesi:
\n\nThis module offers a tailored test assertion method, for testing messages\nattached to an HttpResponse.
To benefit from this assertion, add MessagesTestMixin to the class\nhierarchy:
from django.contrib.messages.test import MessagesTestMixin\nfrom django.test import TestCase\n\n\nclass MsgTestCase(MessagesTestMixin, TestCase):\n pass\nThen, inherit from the MsgTestCase in your tests.
Asserts that messages added to the response matches expected_messages.
expected_messages is a list of\nMessage objects.
By default, the comparison is ordering dependent. You can disable this by\nsetting the ordered argument to False.