I webbapplikationer är det vanligt att du behöver visa ett engångsmeddelande (även kallat ”flashmeddelande”) till användaren efter att ha bearbetat ett formulär eller någon annan typ av användarinmatning.
\nFör detta ger Django fullt stöd för cookie- och sessionsbaserad meddelandehantering, för både anonyma och autentiserade användare. Med meddelanderamen kan du tillfälligt lagra meddelanden i en begäran och hämta dem för visning i en efterföljande begäran (vanligtvis nästa). Varje meddelande är taggat med en specifik ”nivå” som bestämmer dess prioritet (t.ex. ”info”, ”varning” eller ”fel”).
\nMeddelanden implementeras genom en middleware-klass och motsvarande context processor.
\nStandardinställningen settings.py som skapats av django-admin startproject innehåller redan alla inställningar som krävs för att aktivera meddelandefunktionen:
'django.contrib.messages' finns i INSTALLED_APPS.
MIDDLEWARE innehåller 'django.contrib.sessions.middleware.SessionMiddleware' och 'django.contrib.messages.middleware.MessageMiddleware'.
Standard storage backend förlitar sig på sessions. Det är därför SessionMiddleware måste vara aktiverat och visas före MessageMiddleware i MIDDLEWARE.
Alternativet 'context_processors' för backend DjangoTemplates som definieras i din TEMPLATES-inställning innehåller 'django.contrib.messages.context_processors.messages'.
Om du inte vill använda meddelanden kan du ta bort 'django.contrib.messages' från din INSTALLED_APPS, raden MessageMiddleware från MIDDLEWARE och kontextprocessorn messages från TEMPLATES.
Meddelanderamen kan använda olika backends för att lagra tillfälliga meddelanden.
\nDjango tillhandahåller tre inbyggda lagringsklasser i django.contrib.messages:
Den här klassen lagrar alla meddelanden i begäran om session. Därför kräver den Djangos contrib.sessions applikation.
Denna klass lagrar meddelandedata i en cookie (signerad med en hemlig hash för att förhindra manipulation) för att hålla kvar meddelanden över förfrågningar. Gamla meddelanden tas bort om cookiedatastorleken skulle överstiga 2048 byte.
\nDenna klass använder först CookieStorage, och faller tillbaka till att använda SessionStorage för de meddelanden som inte kunde rymmas i en enda cookie. Den kräver också Djangos applikation contrib.sessions.
Detta beteende undviker att skriva till sessionen när det är möjligt. Det bör ge bäst prestanda i det allmänna fallet.
\nFallbackStorage är standardlagringsklassen. Om den inte är lämplig för dina behov kan du välja en annan lagringsklass genom att ange MESSAGE_STORAGE till dess fullständiga importsökväg, till exempel:
MESSAGE_STORAGE = "django.contrib.messages.storage.cookie.CookieStorage"\nFör att skriva din egen lagringsklass, subklassa klassen BaseStorage i django.contrib.messages.storage.base och implementera metoderna _get och _store.
Meddelanderamen bygger på en konfigurerbar nivåarkitektur som liknar den i Pythons loggmodul. Med meddelandenivåer kan du gruppera meddelanden efter typ så att de kan filtreras eller visas på olika sätt i vyer och mallar.
\nDe inbyggda nivåerna, som kan importeras direkt från django.contrib.messages, är:
Konstant | \nSyfte | \n
|---|---|
| \nUtvecklingsrelaterade meddelanden som kommer att ignoreras (eller tas bort) i en produktionsdistribution | \n
| \nInformationsmeddelanden för användaren | \n
| \nEn åtgärd lyckades, t.ex. ”Din profil uppdaterades framgångsrikt” | \n
”VARNING | \nEtt fel inträffade inte men kan vara nära förestående | \n
| \nEn åtgärd lyckades inte eller något annat fel inträffade | \n
Inställningen MESSAGE_LEVEL kan användas för att ändra den lägsta inspelade nivån (eller så kan den ändras på begäran). Försök att lägga till meddelanden på en lägre nivå än denna ignoreras.
För att lägga till ett meddelande, ring:
\nfrom django.contrib import messages\n\nmessages.add_message(request, messages.INFO, "Hello world.")\nVissa genvägsmetoder ger ett standardiserat sätt att lägga till meddelanden med vanligt förekommande taggar (som vanligtvis representeras som HTML-klasser för meddelandet):
\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.")\nI din mall, använd något liknande:
\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 %}\nOm du använder kontextprocessorn bör din mall återges med en RequestContext. Annars ska du se till att messages är tillgängligt för mallkontexten.
Även om du vet att det bara finns ett meddelande bör du ändå iterera över sekvensen messages, eftersom meddelandelagret annars inte kommer att rensas för nästa begäran.
Kontextprocessorn tillhandahåller också variabeln DEFAULT_MESSAGE_LEVELS som är en mappning av meddelandenivåernas namn till deras numeriska värde:
{% 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 %}\nUtanför mallar kan du använda 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)\nDu kan till exempel hämta alla meddelanden för att returnera dem i en JSONResponseMixin istället för en TemplateResponseMixin.
get_messages() kommer att returnera en instans av den konfigurerade lagringsbackend.
Message (meddelande)Link to this heading#När man loopar över listan med meddelanden i en mall får man fram instanser av klassen Message. De har bara ett fåtal attribut:
meddelande: Den faktiska texten i meddelandet.
nivå: Ett heltal som beskriver typen av meddelande (se avsnittet meddelandenivåer ovan).
tags: En sträng som kombinerar alla meddelandets taggar (extra_tags och level_tag) separerade med mellanslag.
extra_tags: En sträng som innehåller anpassade taggar för detta meddelande, separerade med mellanslag. Den är tom som standard.
level_tag: Strängrepresentationen av nivån. Som standard är det den gemena versionen av namnet på den associerade konstanten, men detta kan ändras om du behöver genom att använda inställningen MESSAGE_TAGS.
Meddelandenivåerna är inget annat än heltal, så du kan definiera dina egna nivåkonstanter och använda dem för att skapa mer anpassad användaråterkoppling, t.ex:
\nCRITICAL = 50\n\n\ndef my_view(request):\n messages.add_message(request, CRITICAL, "A serious error occurred.")\nNär du skapar egna meddelandenivåer bör du vara försiktig så att du inte överbelastar befintliga nivåer. Värdena för de inbyggda nivåerna är:
\nNivå Konstant | \nVärde | \n
|---|---|
| \n10 | \n
| \n20 | \n
| \n25 | \n
”VARNING | \n30 | \n
| \n40 | \n
Om du behöver identifiera de anpassade nivåerna i din HTML eller CSS måste du tillhandahålla en mappning via inställningen MESSAGE_TAGS.
Den lägsta registrerade nivån kan ställas in per begäran via metoden 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)\nPå samma sätt kan den aktuella effektiva nivån hämtas med get_level:
from django.contrib import messages\n\ncurrent_level = messages.get_level(request)\nFör mer information om hur den lägsta inspelningsnivån fungerar, se Meddelandenivåer ovan.
\nOm du skriver en återanvändbar app (eller annan kod) och vill inkludera meddelandefunktionalitet, men inte vill kräva att dina användare aktiverar det om de inte vill, kan du skicka ett ytterligare nyckelordsargument fail_silently=True till någon av metoderna i add_message-familjen. Till exempel:
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)\nLägger till ett attribut för framgångsmeddelande till FormView-baserade klasser
cleaned_data är de rensade data från formuläret som används för strängformatering
Exempel på 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"\nDe rensade uppgifterna från formuläret är tillgängliga för stränginterpolering med syntaxen %(field_name)s. För ModelForms, om du behöver tillgång till fält från det sparade objektet åsidosätt metoden get_success_message().
Exempel på views.py för 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 )\nMeddelandena markeras för att rensas när lagringsinstansen itereras (och rensas när svaret bearbetas).
\nFör att undvika att meddelandena rensas kan du ställa in meddelandelagringen till False efter iteration:
storage = messages.get_messages(request)\nfor message in storage:\n do_something_with(message)\nstorage.used = False\nPå grund av hur cookies (och därmed sessioner) fungerar, är beteendet hos alla backends som använder cookies eller sessioner odefinierat när samma klient gör flera begäranden som ställer in eller hämtar meddelanden parallellt. Om en klient t.ex. initierar en begäran som skapar ett meddelande i ett fönster (eller en flik) och sedan en annan som hämtar alla oitererade meddelanden i ett annat fönster, innan det första fönstret omdirigeras, kan meddelandet visas i det andra fönstret i stället för i det första fönstret där det kan förväntas.
\nKort sagt, när flera samtidiga förfrågningar från samma klient är inblandade, är det inte garanterat att meddelanden levereras till samma fönster som skapade dem eller, i vissa fall, inte alls. Observera att detta normalt inte är ett problem i de flesta tillämpningar och att det kommer att bli ett icke-problem i HTML5, där varje fönster/flik kommer att ha sin egen webbläsarkontext.
\nNågra inställningar ger dig kontroll över meddelandets beteende:
\n\nFör backends som använder cookies hämtas inställningarna för cookien från inställningarna för sessionscookien:
\n\nDenna modul erbjuder en skräddarsydd testmetod för att testa meddelanden som är kopplade till en HttpResponse.
För att dra nytta av denna försäkran, lägg till MessagesTestMixin i klasshierarkin:
from django.contrib.messages.test import MessagesTestMixin\nfrom django.test import TestCase\n\n\nclass MsgTestCase(MessagesTestMixin, TestCase):\n pass\nÄrv sedan från MsgTestCase i dina tester.
Säkerställer att messages som lagts till i response matchar expected_messages.
expected_messages är en lista med Message-objekt.
Som standard är jämförelsen beroende av ordningsföljd. Du kan inaktivera detta genom att ställa in argumentet ordered till False.