Django 2.1 - The messages framework

संदेशों की रूपरेखा




django

संदेशों की रूपरेखा

आमतौर पर वेब अनुप्रयोगों में, आपको एक फॉर्म या कुछ अन्य प्रकार के उपयोगकर्ता इनपुट को संसाधित करने के बाद उपयोगकर्ता को एक-बार अधिसूचना संदेश (जिसे "फ्लैश संदेश" भी कहा जाता है) प्रदर्शित करने की आवश्यकता होती है।

इसके लिए, Django गुमनाम और प्रमाणित उपयोगकर्ताओं दोनों के लिए कुकी और सत्र-आधारित संदेश भेजने के लिए पूर्ण समर्थन प्रदान करता है। संदेशों की रूपरेखा आपको संदेशों को एक अनुरोध में अस्थायी रूप से संग्रहीत करने और बाद के अनुरोध में प्रदर्शन के लिए उन्हें पुनः प्राप्त करने की अनुमति देती है (आमतौर पर अगले एक)। प्रत्येक संदेश को एक विशिष्ट level साथ टैग किया जाता level जो उसकी प्राथमिकता (जैसे, info , warning या error ) को निर्धारित करता level

संदेश सक्षम करना

संदेशों को एक middleware क्लास और संबंधित संदर्भ प्रोसेसर के माध्यम से कार्यान्वित किया जाता है।

django-admin startproject द्वारा बनाई गई डिफ़ॉल्ट django-admin startproject पहले से ही संदेश कार्यक्षमता को सक्षम करने के लिए आवश्यक सभी सेटिंग्स हैं:

  • 'django.contrib.messages' INSTALLED_APPS
  • MIDDLEWARE में 'django.contrib.sessions.middleware.SessionMiddleware' और 'django.contrib.messages.middleware.MessageMiddleware'

    डिफ़ॉल्ट भंडारण बैकएंड sessions पर निर्भर करता है। इसलिए SessionMiddleware को सक्षम होना चाहिए और MIDDLEWARE में MessageMiddleware से पहले दिखाई देना चाहिए।

  • आपके TEMPLATES सेटिंग में परिभाषित DjangoTemplates बैकएंड के 'django.contrib.messages.context_processors.messages' में 'django.contrib.messages.context_processors.messages'

यदि आप संदेशों का उपयोग नहीं करना चाहते हैं, तो आप अपने INSTALLED_APPS से 'django.contrib.messages' को हटा सकते हैं, 'django.contrib.messages' से MessageMiddleware लाइन और TEMPLATES से messages संदर्भ प्रोसेसर।

संदेश इंजन को कॉन्फ़िगर करना

भंडारण का समर्थन करता है

संदेशों की रूपरेखा अस्थायी संदेशों को संग्रहीत करने के लिए विभिन्न बैकेंड का उपयोग कर सकती है।

Django django.contrib.messages में तीन बिल्ट-इन स्टोरेज क्लासेस प्रदान करता है:

class storage.session.SessionStorage

यह वर्ग अनुरोध के सत्र के अंदर सभी संदेशों को संग्रहीत करता है। इसलिए इसे Django के contrib.sessions एप्लिकेशन की आवश्यकता है।

class storage.cookie.CookieStorage

यह वर्ग अनुरोध में सूचनाओं को जारी रखने के लिए एक कुकी में संदेश डेटा (हेरफेर को रोकने के लिए एक गुप्त हैश के साथ हस्ताक्षरित) को संग्रहीत करता है। यदि कुकी डेटा का आकार 2048 बाइट से अधिक हो तो पुराने संदेश हटा दिए जाते हैं।

class storage.fallback.FallbackStorage

यह वर्ग पहले CookieStorage का उपयोग करता है, और उन संदेशों के लिए SessionStorage का उपयोग करने के लिए वापस आता है जो एक कुकी में फिट नहीं हो सकते थे। इसके लिए Django के contrib.sessions एप्लिकेशन की भी आवश्यकता होती है।

यह व्यवहार जब भी संभव हो सत्र को लिखने से बचता है। यह सामान्य मामले में सबसे अच्छा प्रदर्शन प्रदान करना चाहिए।

FallbackStorage डिफ़ॉल्ट स्टोरेज क्लास है। यदि यह आपकी आवश्यकताओं के लिए उपयुक्त नहीं है, तो आप इसके पूर्ण आयात पथ के लिए MESSAGE_STORAGE सेट करके एक अन्य संग्रहण वर्ग का चयन कर सकते हैं, उदाहरण के लिए:

MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie.CookieStorage'
class storage.base.BaseStorage

अपनी खुद की स्टोरेज क्लास लिखने के लिए, BaseStorage में BaseStorage क्लास को django.contrib.messages.storage.base और _get और _store तरीकों को लागू करें।

संदेश का स्तर

संदेशों की रूपरेखा अजगर के लॉगिंग मॉड्यूल के समान एक विन्यास स्तर की वास्तुकला पर आधारित है। संदेश का स्तर आपको संदेशों को समूह द्वारा टाइप करने की अनुमति देता है ताकि वे दृश्य और टेम्पलेट्स में अलग-अलग फ़िल्टर किए जा सकें या प्रदर्शित किए जा सकें।

अंतर्निहित स्तर, जो सीधे django.contrib.messages से आयात किए जा सकते हैं, वे हैं:

स्थिर उद्देश्य
DEBUG विकास-संबंधी संदेश जिन्हें उत्पादन परिनियोजन में अनदेखा (या हटा दिया जाएगा) किया जाएगा
INFO उपयोगकर्ता के लिए सूचनात्मक संदेश
SUCCESS एक कार्यवाही सफल रही, जैसे "आपका प्रोफ़ाइल सफलतापूर्वक अपडेट किया गया"
WARNING एक विफलता नहीं हुई लेकिन आसन्न हो सकती है
ERROR एक कार्रवाई सफल नहीं थी या कुछ अन्य विफलता हुई

MESSAGE_LEVEL सेटिंग का उपयोग न्यूनतम दर्ज स्तर को बदलने के लिए किया जा सकता है (या इसे अनुरोध के अनुसार बदला जा सकता है)। इससे कम स्तर के संदेशों को जोड़ने के प्रयासों को अनदेखा किया जाएगा।

संदेश टैग

संदेश टैग संदेश स्तर के साथ-साथ किसी भी अतिरिक्त टैग का एक स्ट्रिंग प्रतिनिधित्व है जो सीधे दृश्य में जोड़े गए थे (अधिक विवरण के लिए नीचे अतिरिक्त संदेश टैग जोड़ना )। टैग को एक स्ट्रिंग में संग्रहीत किया जाता है और रिक्त स्थान द्वारा अलग किया जाता है। आमतौर पर, संदेश टैग का उपयोग सीएसएस कक्षाओं के रूप में संदेश प्रकार के आधार पर संदेश शैली को अनुकूलित करने के लिए किया जाता है। डिफ़ॉल्ट रूप से, प्रत्येक स्तर में एक एकल टैग होता है जो अपने स्वयं के निरंतर संस्करण का निचला संस्करण होता है:

स्तर लगातार टैग
DEBUG debug
INFO info
SUCCESS success
WARNING warning
ERROR error

संदेश स्तर (या तो कस्टम या कस्टम) के लिए डिफ़ॉल्ट टैग बदलने के लिए, MESSAGE_TAGS सेटिंग को किसी ऐसे शब्दकोश में सेट करें जिसमें आप जिस स्तर को बदलना चाहते हैं। जैसे ही यह डिफ़ॉल्ट टैग बढ़ाता है, आपको केवल उन स्तरों के लिए टैग प्रदान करने की आवश्यकता होती है जिन्हें आप ओवरराइड करना चाहते हैं:

from django.contrib.messages import constants as messages
MESSAGE_TAGS = {
    messages.INFO: '',
    50: 'critical',
}

विचारों और टेम्पलेट्स में संदेशों का उपयोग करना

add_message(request, level, message, extra_tags='', fail_silently=False) [source]

एक संदेश जोड़ना

संदेश जोड़ने के लिए, कॉल करें:

from django.contrib import messages
messages.add_message(request, messages.INFO, 'Hello world.')

कुछ शॉर्टकट तरीके आमतौर पर उपयोग किए जाने वाले टैग के साथ संदेश जोड़ने के लिए एक मानक तरीका प्रदान करते हैं (जो आमतौर पर संदेश के लिए HTML कक्षाओं के रूप में दर्शाए जाते हैं):

messages.debug(request, '%s SQL statements were executed.' % count)
messages.info(request, 'Three credits remain in your account.')
messages.success(request, 'Profile details updated.')
messages.warning(request, 'Your account expires in three days.')
messages.error(request, 'Document deleted.')

संदेश प्रदर्शित करना

get_messages(request) [source]

अपने टेम्पलेट में , कुछ का उपयोग करें:

{% if messages %}
<ul class="messages">
    {% for message in messages %}
    <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li>
    {% endfor %}
</ul>
{% endif %}

यदि आप संदर्भ प्रोसेसर का उपयोग कर रहे हैं, तो आपके टेम्पलेट को RequestContext साथ प्रस्तुत किया जाना चाहिए। अन्यथा, सुनिश्चित करें कि messages टेम्प्लेट के संदर्भ में उपलब्ध हैं।

यहां तक ​​कि अगर आपको पता है कि केवल एक संदेश है, तो आपको अभी भी messages अनुक्रम पर पुनरावृत्त होना चाहिए, क्योंकि अन्यथा संदेश का अनुरोध अगले अनुरोध के लिए साफ़ नहीं किया जाएगा।

संदर्भ प्रोसेसर एक DEFAULT_MESSAGE_LEVELS चर भी प्रदान करता है जो उनके सांख्यिक स्तर पर संदेश स्तर के नामों की मैपिंग है:

{% if messages %}
<ul class="messages">
    {% for message in messages %}
    <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>
        {% if message.level == DEFAULT_MESSAGE_LEVELS.ERROR %}Important: {% endif %}
        {{ message }}
    </li>
    {% endfor %}
</ul>
{% endif %}

टेम्पलेट्स के बाहर , आप get_messages() उपयोग कर सकते हैं:

from django.contrib.messages import get_messages

storage = get_messages(request)
for message in storage:
    do_something_with_the_message(message)

उदाहरण के लिए, आप उन्हें JSONResponseMixin बजाय TemplateResponseMixin बदले सभी संदेश लाने के लिए कर सकते हैं।

get_messages() कॉन्फ़िगर किए गए संग्रहण बैकेंड का एक उदाहरण लौटाएगा।

Message वर्ग

class storage.base.Message

जब आप किसी टेम्प्लेट में संदेशों की सूची पर लूप करते हैं, तो आपको जो मिलता है वह Message वर्ग के उदाहरण हैं। यह केवल कुछ विशेषताओं के साथ काफी सरल वस्तु है:

  • message : message का वास्तविक पाठ।
  • level : एक पूर्णांक संदेश के प्रकार का वर्णन करता है (ऊपर संदेश स्तर अनुभाग देखें)।
  • tags : सभी संदेशों के टैग ( extra_tags और level_tag ) को जोड़कर एक स्ट्रिंग रिक्त स्थान से अलग हो जाती है।
  • extra_tags : रिक्त स्थान द्वारा अलग किए गए इस संदेश के लिए कस्टम टैग युक्त स्ट्रिंग। यह डिफ़ॉल्ट रूप से खाली है।
  • level_tag : स्तर का स्ट्रिंग प्रतिनिधित्व। डिफ़ॉल्ट रूप से, यह संबंधित स्थिरांक के नाम का निचला संस्करण है, लेकिन यदि आपको MESSAGE_TAGS सेटिंग का उपयोग करके आवश्यकता हो तो इसे बदला जा सकता है।

कस्टम संदेश स्तर बनाना

संदेश का स्तर पूर्णांक से अधिक कुछ भी नहीं है, इसलिए आप अपने स्वयं के स्तर के स्थिरांक को परिभाषित कर सकते हैं और अधिक अनुकूलित उपयोगकर्ता प्रतिक्रिया बनाने के लिए उनका उपयोग कर सकते हैं, जैसे:

CRITICAL = 50

def my_view(request):
    messages.add_message(request, CRITICAL, 'A serious error occurred.')

कस्टम संदेश स्तर बनाते समय आपको मौजूदा स्तरों को ओवरलोड करने से बचने के लिए सावधान रहना चाहिए। अंतर्निहित स्तरों के लिए मान निम्न हैं:

स्तर लगातार मूल्य
DEBUG 10
INFO 20
SUCCESS 25
WARNING 30
ERROR 40

यदि आपको अपने HTML या CSS में कस्टम स्तरों की पहचान करने की आवश्यकता है, तो आपको MESSAGE_TAGS सेटिंग के माध्यम से मानचित्रण प्रदान करना होगा।

ध्यान दें

यदि आप एक पुन: प्रयोज्य अनुप्रयोग बना रहे हैं, तो यह केवल अंतर्निहित संदेश स्तरों का उपयोग करने के लिए अनुशंसित है और किसी भी कस्टम स्तर पर निर्भर नहीं है।

न्यूनतम दर्ज स्तर प्रति-अनुरोध को बदलना

न्यूनतम दर्ज स्तर set_level विधि के माध्यम से प्रति अनुरोध सेट किया जा सकता है:

from django.contrib import messages

# Change the messages level to ensure the debug message is added.
messages.set_level(request, messages.DEBUG)
messages.debug(request, 'Test message...')

# In another request, record only messages with a level of WARNING and higher
messages.set_level(request, messages.WARNING)
messages.success(request, 'Your profile was updated.') # ignored
messages.warning(request, 'Your account is about to expire.') # recorded

# Set the messages level back to default.
messages.set_level(request, None)

इसी तरह, वर्तमान प्रभावी स्तर get_level साथ पुनर्प्राप्त किया जा सकता है:

from django.contrib import messages
current_level = messages.get_level(request)

न्यूनतम रिकॉर्ड स्तर के कार्यों के बारे में अधिक जानकारी के लिए, ऊपर संदेश स्तर देखें।

अतिरिक्त संदेश टैग जोड़ना

संदेश टैग पर अधिक प्रत्यक्ष नियंत्रण के लिए, आप वैकल्पिक रूप से किसी भी अतिरिक्त तरीके से अतिरिक्त टैग युक्त स्ट्रिंग प्रदान कर सकते हैं:

messages.add_message(request, messages.INFO, 'Over 9000!', extra_tags='dragonball')
messages.error(request, 'Email box full', extra_tags='email')

उस स्तर के लिए डिफ़ॉल्ट टैग से पहले अतिरिक्त टैग जोड़े जाते हैं और स्थान अलग कर दिए जाते हैं।

संदेश की रूपरेखा अक्षम होने पर चुपचाप असफल होना

यदि आप एक पुन: प्रयोज्य एप्लिकेशन (या कोड का अन्य टुकड़ा) लिख रहे हैं और मैसेजिंग कार्यक्षमता को शामिल करना चाहते हैं, लेकिन अपने उपयोगकर्ताओं को इसे सक्षम करने की आवश्यकता नहीं चाहते हैं यदि वे नहीं चाहते हैं, तो आप एक अतिरिक्त कीवर्ड तर्क को fail_silently=True विधियों के किसी भी add_message परिवार के लिए सही। उदाहरण के लिए:

messages.add_message(
    request, messages.SUCCESS, 'Profile details updated.',
    fail_silently=True,
)
messages.info(request, 'Hello world.', fail_silently=True)

ध्यान दें

fail_silently=True सेट करना fail_silently=True केवल MessageFailure छुपाता है जो अन्यथा तब होता है जब संदेश ढाँचा अक्षम हो जाता है और कोई एक add_message परिवार के तरीकों का उपयोग करने का प्रयास करता है। यह विफलताओं को नहीं छिपाता है जो अन्य कारणों से हो सकता है।

क्लास-आधारित विचारों में संदेश जोड़ना

class views.SuccessMessageMixin

एक सफल संदेश विशेषता को FormView आधारित कक्षाओं में जोड़ता है

get_success_message(cleaned_data)

cleaned_data उस स्वरूप से साफ किया गया डेटा है जो स्ट्रिंग स्वरूपण के लिए उपयोग किया जाता है

उदाहरण

from django.contrib.messages.views import SuccessMessageMixin
from django.views.generic.edit import CreateView
from myapp.models import Author

class AuthorCreate(SuccessMessageMixin, CreateView):
    model = Author
    success_url = '/success/'
    success_message = "%(name)s was created successfully"

form से साफ़ किया गया डेटा %(field_name)s सिंटैक्स का उपयोग करके स्ट्रिंग प्रक्षेप के लिए उपलब्ध है। ModelForms के लिए, यदि आपको सहेजे गए object से फ़ील्ड तक पहुंच की आवश्यकता है तो get_success_message() विधि को ओवरराइड करें।

ModelForms के लिए उदाहरण view.py

from django.contrib.messages.views import SuccessMessageMixin
from django.views.generic.edit import CreateView
from myapp.models import ComplicatedModel

class ComplicatedCreate(SuccessMessageMixin, CreateView):
    model = ComplicatedModel
    success_url = '/success/'
    success_message = "%(calculated_field)s was created successfully"

    def get_success_message(self, cleaned_data):
        return self.success_message % dict(
            cleaned_data,
            calculated_field=self.object.calculated_field,
        )

संदेशों की समाप्ति

संग्रहण आवृत्ति के पुनरावृत्त होने पर संदेशों को साफ़ किया जाना चाहिए (और प्रतिक्रिया संसाधित होने पर साफ़ किया गया)।

संदेशों को हटाए जाने से बचने के लिए, आप संदेशों को स्टोर करने के बाद False स्टोरेज सेट कर सकते हैं:

storage = messages.get_messages(request)
for message in storage:
    do_something_with(message)
storage.used = False

समानांतर अनुरोधों का व्यवहार

कुकीज़ (और इसलिए सत्र) काम करने के तरीके के कारण, किसी भी बैकएंड का व्यवहार जो कुकीज़ या सत्र का उपयोग करता है, अपरिभाषित होता है जब एक ही ग्राहक कई अनुरोध करता है जो समानांतर में संदेश सेट या प्राप्त करते हैं । उदाहरण के लिए, यदि कोई ग्राहक एक अनुरोध करता है जो एक विंडो (या टैब) में एक संदेश बनाता है और फिर एक अन्य विंडो में कोई भी अनपेक्षित संदेश लाता है, तो पहली विंडो रीडायरेक्ट होने से पहले के बजाय दूसरी विंडो में संदेश दिखाई दे सकता है खिड़की जहां यह उम्मीद की जा सकती है।

संक्षेप में, जब एक ही क्लाइंट से एक साथ कई अनुरोध शामिल होते हैं, तो संदेशों को उसी विंडो पर वितरित करने की गारंटी नहीं दी जाती है जो उन्हें बनाया गया हो और न ही कुछ मामलों में। ध्यान दें कि यह आमतौर पर अधिकांश अनुप्रयोगों में कोई समस्या नहीं है और HTML5 में एक गैर-मुद्दा बन जाएगा, जहां प्रत्येक विंडो / टैब में इसका ब्राउज़िंग संदर्भ होगा।

सेटिंग्स

कुछ settings आपको संदेश व्यवहार पर नियंत्रण देती हैं:

कुकीज़ का उपयोग करने वाले बैकएंड्स के लिए, कुकी के लिए सेटिंग्स सत्र कुकी सेटिंग्स से ली गई हैं: