Quite commonly in web applications, you need to display a one-time\nnotification message (also known as "flash message") to the user after\nprocessing a form or some other types of user input.
\nFor this, Django provides full support for cookie- and session-based\nmessaging, for both anonymous and authenticated users. The messages framework\nallows you to temporarily store messages in one request and retrieve them for\ndisplay in a subsequent request (usually the next one). Every message is\ntagged with a specific level that determines its priority (e.g., info,\nwarning, or error).
Messages are implemented through a middleware\nclass and corresponding 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'.
The default storage backend relies on\nsessions. That's why SessionMiddleware\nmust be enabled and appear before MessageMiddleware in\nMIDDLEWARE.
Pilihan 'context_processors' dari backend DjangoTemplates ditentukan di pengaturan TEMPLATES anda mengandung 'django.contrib.messages.context_processors.messages'.
If you don't want to use messages, you can remove\n'django.contrib.messages' from your INSTALLED_APPS, the\nMessageMiddleware line from MIDDLEWARE, and the messages\ncontext processor from 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:
This class stores all messages inside of the request's session. Therefore\nit requires Django's contrib.sessions application.
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.
\nThis class first uses CookieStorage, and falls back to using\nSessionStorage for the messages that could not fit in a single cookie.\nIt also requires Django's contrib.sessions application.
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.
The messages framework is based on a configurable level architecture similar\nto that of the Python logging module. Message levels allow you to group\nmessages by type so they can be filtered or displayed differently in views and\ntemplates.
\nTingkat siap-pakai, yang dapat diimpor dari django.contrib.messages secar langsung, adalah:
Ketetapan | \nMaksud | \n
|---|---|
| \nDevelopment-related messages that will be ignored (or removed) in a production deployment | \n
| \nPesan informasi untuk pengguna | \n
| \nSebuah tindakan telah berhasil, sebagai contoh "Profil anda telah berhasil diperbaharui". | \n
| \nKegagalan tidak muncul tetapi mungkin sebentar lagi | \n
| \nSebuah tindakan tidak berhasil atau beberapa kegagalan lain muncul | \n
The MESSAGE_LEVEL setting can be used to change the minimum recorded level\n(or it can be changed per request). Attempts to add messages of a level less\nthan this will be ignored.
Untuk menambahkan pesan, panggil:
\nfrom django.contrib import messages\nmessages.add_message(request, messages.INFO, 'Hello world.')\nSome shortcut methods provide a standard way to add messages with commonly\nused tags (which are usually represented as HTML classes for the message):
\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.')\nDi cetakan anda, gunakan sesuatu seperti:
\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 %}\nIf you're using the context processor, your template should be rendered with a\nRequestContext. Otherwise, ensure messages is available to\nthe template context.
Even if you know there is only just one message, you should still iterate over\nthe messages sequence, because otherwise the message storage will not be cleared\nfor 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)\nFor instance, you can fetch all the messages to return them in a\nJSONResponseMixin instead of a\nTemplateResponseMixin.
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. It's quite a simple object, with only a\nfew attributes:
message: Teks sebenarnya dari pesan.
level: An integer describing the type of the message (see the\nmessage levels section above).
tags: A string combining all the message's tags (extra_tags and\nlevel_tag) separated by spaces.
extra_tags: A string containing custom tags for this message,\nseparated by spaces. It's empty by default.
level_tag: The string representation of the level. By default, it's\nthe lowercase version of the name of the associated constant, but this\ncan be changed if you need by using the MESSAGE_TAGS setting.
Messages levels are nothing more than integers, so you can define your own\nlevel constants and use them to create more customized user feedback, e.g.:
\nCRITICAL = 50\n\ndef my_view(request):\n messages.add_message(request, CRITICAL, 'A serious error occurred.')\nWhen creating custom message levels you should be careful to avoid overloading\nexisting levels. The values for the built-in levels are:
\nTingkat Ketetapan | \nNilai | \n
|---|---|
| \n10 | \n
| \n20 | \n
| \n25 | \n
| \n30 | \n
| \n40 | \n
If you need to identify the custom levels in your HTML or CSS, you need to\nprovide a mapping via the MESSAGE_TAGS setting.
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\ncurrent_level = messages.get_level(request)\nUntuk informasi lebih pada bagaimana fungsi tingkat terekam minimal, lihat Message levels diatas.
\nIf you're writing a reusable app (or other piece of code) and want to include\nmessaging functionality, but don't want to require your users to enable it\nif they don't want to, you may pass an additional keyword argument\nfail_silently=True to any of the add_message family of methods. For\nexample:
messages.add_message(\n request, messages.SUCCESS, '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\nclass AuthorCreate(SuccessMessageMixin, CreateView):\n model = Author\n success_url = '/success/'\n success_message = "%(name)s was created successfully"\nThe cleaned data from the form is available for string interpolation using\nthe %(field_name)s syntax. For ModelForms, if you need access to fields\nfrom the saved object override the\nget_success_message()\nmethod.
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\nclass ComplicatedCreate(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 )\nThe messages are marked to be cleared when the storage instance is iterated\n(and cleared when the response is processed).
\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\nDue to the way cookies (and hence sessions) work, the behavior of any\nbackends that make use of cookies or sessions is undefined when the same\nclient makes multiple requests that set or get messages in parallel. For\nexample, if a client initiates a request that creates a message in one window\n(or tab) and then another that fetches any uniterated messages in another\nwindow, before the first window redirects, the message may appear in the\nsecond window instead of the first window where it may be expected.
\nIn short, when multiple simultaneous requests from the same client are\ninvolved, messages are not guaranteed to be delivered to the same window that\ncreated them nor, in some cases, at all. Note that this is typically not a\nproblem in most applications and will become a non-issue in HTML5, where each\nwindow/tab will have its own browsing context.
\nSedikit settings memberikan anda kendali terhadap perilaku pesan:
\n\nUntuk backend yang menggunakan kue, pengaturan untuk kue diambil dari pengaturan kue sesi:
\n\n