Django 2.1 - The Django template language: for Python programmers

Django टेम्पलेट भाषा: पायथन प्रोग्रामर के लिए




django

Django टेम्पलेट भाषा: पायथन प्रोग्रामर के लिए

यह दस्तावेज़ तकनीकी दृष्टिकोण से Django टेम्पलेट सिस्टम की व्याख्या करता है - यह कैसे काम करता है और इसे कैसे बढ़ाया जाए। यदि आप भाषा सिंटैक्स पर संदर्भ ढूंढ रहे हैं , तो Django टेम्पलेट भाषा देखें

यह टेम्प्लेट, संदर्भ, चर, टैग और रेंडरिंग की समझ को मानता है। यदि आप इन अवधारणाओं से परिचित नहीं हैं, तो Django टेम्पलेट भाषा से परिचय के साथ शुरू करें।

अवलोकन

पायथन में टेम्प्लेट सिस्टम का उपयोग करना तीन चरणों वाली प्रक्रिया है:

  1. आप एक Engine कॉन्फ़िगर करें।
  2. आप टेम्पलेट में टेम्पलेट कोड संकलित करते हैं।
  3. आप टेम्पलेट को एक Context साथ प्रस्तुत करते हैं।

Django परियोजनाएं आम तौर पर उच्च स्तर पर निर्भर करती हैं , टेम्पलेट सिस्टम के निचले एपीआई एपीआई के बजाय इन चरणों में से प्रत्येक के लिए अज्ञेय एपीआई का समर्थन करते हैं:

  1. TEMPLATES सेटिंग में प्रत्येक DjangoTemplates बैकएंड के लिए, Django एक Engine तत्काल तैयार करता है। DjangoTemplates Engine लपेटता है और इसे आम टेम्पलेट बैकएंड एपीआई में DjangoTemplates है।
  2. django.template.loader मॉड्यूल लोडिंग टेम्प्लेट के लिए get_template() जैसे फ़ंक्शन प्रदान करता है। वे एक django.template.backends.django.Template जो वास्तविक Template लपेटता है।
  3. पिछले चरण में प्राप्त Template में एक render() विधि है जो एक संदर्भ को संदर्भित करता है और संभवतः एक Context में एक अनुरोध करता है और अंतर्निहित Template को रेंडरिंग को Template

एक इंजन को कॉन्फ़िगर करना

यदि आप केवल DjangoTemplates बैकएंड का उपयोग कर रहे हैं, तो यह संभवतः वह दस्तावेज नहीं है जिसे आप खोज रहे हैं। नीचे वर्णित Engine वर्ग का एक उदाहरण उस बैकएंड के engine विशेषता का उपयोग करके सुलभ है और नीचे बताए गए किसी भी विशेषता डिफॉल्ट को DjangoTemplates द्वारा पारित किया DjangoTemplates

class Engine(dirs=None, app_dirs=False, context_processors=None, debug=False, loaders=None, string_if_invalid='', file_charset='utf-8', libraries=None, builtins=None, autoescape=True) [source]

Engine इंस्टेंट करते समय सभी तर्कों को खोजशब्द तर्क के रूप में पारित किया जाना चाहिए:

  • dirs निर्देशिकाओं की एक सूची है जहाँ इंजन को टेम्पलेट स्रोत फ़ाइलों के लिए देखना चाहिए। इसका उपयोग filesystem.Loader को कॉन्फ़िगर करने के लिए किया filesystem.Loader

    यह एक खाली सूची में चूक करता है।

  • app_dirs केवल loaders के डिफ़ॉल्ट मूल्य को प्रभावित करता है। निचे देखो।

    यह False

  • autoescape नियंत्रित करता है कि क्या HTML ऑटोट्सिंग सक्षम है।

    यह True को डिफॉल्ट करता है।

    चेतावनी

    यदि आप गैर- HTML टेम्पलेट प्रदान कर रहे हैं तो केवल इसे False सेट करें!

  • context_processors उन context_processors को डॉटेड पायथन रास्तों की एक सूची है, जो किसी टेम्पलेट को अनुरोध के साथ प्रस्तुत किए जाने पर संदर्भ को पॉप्युलेट करने के लिए उपयोग किए जाते हैं। ये कॉलबल्स उनके तर्क के रूप में एक अनुरोध ऑब्जेक्ट लेते हैं और संदर्भ में विलय होने के लिए कई मदों को वापस करते हैं।

    यह एक खाली सूची में चूक करता है।

    अधिक जानकारी के लिए RequestContext देखें।

  • debug एक बूलियन है जो टेम्पलेट डिबग मोड को चालू / बंद करता है। यदि यह True , तो टेम्पलेट इंजन अतिरिक्त डीबग जानकारी संग्रहीत करेगा जो टेम्पलेट रेंडरिंग के दौरान उठाए गए किसी भी अपवाद के लिए एक विस्तृत रिपोर्ट प्रदर्शित करने के लिए उपयोग किया जा सकता है।

    यह False

  • loaders टेम्पलेट लोडर वर्गों की एक सूची है, जिसे स्ट्रिंग के रूप में निर्दिष्ट किया गया है। प्रत्येक Loader वर्ग जानता है कि किसी विशेष स्रोत से टेम्पलेट्स को कैसे आयात किया जाए। वैकल्पिक रूप से, एक स्ट्रिंग के बजाय एक टुपल का उपयोग किया जा सकता है। टपल में पहला आइटम Loader वर्ग का नाम होना चाहिए, बाद के आइटम को आरंभीकरण के दौरान Loader को पास किया जाता है।

    इसमें एक सूची से चूक है:

    • 'django.template.loaders.filesystem.Loader'
    • 'django.template.loaders.app_directories.Loader' अगर और केवल अगर app_dirs True

    यदि debug False , तो ये लोडर django.template.loaders.cached.Loader में लिपटे हुए हैं।

    विवरण के लिए लोडर प्रकार देखें।

  • string_if_invalid एक स्ट्रिंग के रूप में आउटपुट है, जिसे टेम्पलेट सिस्टम को अमान्य (जैसे गलत वर्तनी वाले) चर के लिए उपयोग करना चाहिए।

    यह खाली स्ट्रिंग को डिफॉल्ट करता है।

    देखें कि अमान्य चर विवरण के लिए कैसे संभाले जाते हैं

  • file_charset डिस्क पर टेम्प्लेट फ़ाइलों को पढ़ने के लिए उपयोग किया जाने वाला charset है।

    यह 'utf-8' लिए डिफॉल्ट करता है।

  • 'libraries' : लेबल का एक शब्दकोश और टेम्पलेट इंजन के साथ रजिस्टर करने के लिए टेम्प्लेट टैग मॉड्यूल के पाइथन पथ का डॉटेड। इसका उपयोग नए पुस्तकालयों को जोड़ने या मौजूदा लोगों के लिए वैकल्पिक लेबल प्रदान करने के लिए किया जाता है। उदाहरण के लिए:

    Engine(
        libraries={
            'myapp_tags': 'path.to.myapp.tags',
            'admin.urls': 'django.contrib.admin.templatetags.admin_urls',
        },
    )
    

    पुस्तकालयों को {% load %} टैग के लिए संबंधित शब्दकोश कुंजी पास करके लोड किया जा सकता है।

  • 'builtins' : built-ins जोड़ने के लिए टेम्प्लेट टैग मॉड्यूल के बिंदीदार पायथन रास्तों की एक सूची। उदाहरण के लिए:

    Engine(
        builtins=['myapp.builtins'],
    )
    

    अंतर्निहित लाइब्रेरी से टैग और फ़िल्टर का उपयोग पहले {% load %} टैग को कॉल किए बिना किया जा सकता है।

static Engine.get_default() [source]

पहले कॉन्फ़िगर किए गए DjangoTemplates इंजन से अंतर्निहित Engine लौटाता है। यदि कोई इंजन कॉन्फ़िगर नहीं किया गया है तो ImproperlyConfigured जाता है।

यह उन एपीआई को संरक्षित करने के लिए आवश्यक है जो विश्व स्तर पर उपलब्ध, अनुमानित रूप से कॉन्फ़िगर किए गए इंजन पर निर्भर हैं। किसी भी अन्य उपयोग को दृढ़ता से हतोत्साहित किया जाता है।

Django 2.0 में बदला:

पुराने संस्करणों में, यदि पहले इंजन को वापस करने के बजाय कई इंजन कॉन्फ़िगर किए गए हैं, तो ImproperlyConfigured से सुधारता है।

Engine.from_string(template_code) [source]

दिए गए टेम्पलेट कोड को संकलित करता है और एक Template ऑब्जेक्ट देता है।

Engine.get_template(template_name) [source]

दिए गए नाम के साथ एक टेम्पलेट लोड करता है, इसे संकलित करता है और एक Template ऑब्जेक्ट लौटाता है।

Engine.select_template(template_name_list) [source]

जैसे get_template() , इसके अलावा यह नामों की एक सूची लेता है और पहला टेम्पलेट लौटाता है जो मिला था।

एक टेम्पलेट लोड हो रहा है

Template बनाने का अनुशंसित तरीका Engine की फ़ैक्टरी विधियों को कॉल करके है: get_template() , select_template() और from_string()

एक Django परियोजना में जहां DjangoTemplates सेटिंग एक DjangoTemplates इंजन को परिभाषित करता है, यह सीधे एक Template तत्काल संभव है। यदि एक से अधिक DjangoTemplates इंजन परिभाषित किया गया है, तो पहले वाले का उपयोग किया जाएगा।

class Template [source]

यह वर्ग django.template.Template पर django.template.Template । निर्माता एक तर्क लेता है - कच्चा टेम्पलेट कोड:

from django.template import Template

template = Template("My name is {{ my_name }}.")

परदे के पीछे

जब आप Template ऑब्जेक्ट बनाते हैं तो सिस्टम केवल एक बार आपके कच्चे टेम्पलेट कोड को पार्स करता है। तब से, इसे आंतरिक रूप से प्रदर्शन के लिए एक पेड़ की संरचना के रूप में संग्रहीत किया जाता है।

यहां तक ​​कि पार्सिंग भी काफी तेज है। अधिकांश पार्सिंग एक कॉल के माध्यम से एकल, लघु, नियमित अभिव्यक्ति के लिए होता है।

एक प्रसंग का प्रतिपादन

एक बार आपके पास एक संकलित Template ऑब्जेक्ट होने के बाद, आप इसके साथ एक संदर्भ प्रदान कर सकते हैं। आप इसे अलग-अलग संदर्भों के साथ कई बार प्रस्तुत करने के लिए एक ही टेम्पलेट का पुन: उपयोग कर सकते हैं।

class Context(dict_=None) [source]

django.template.Context का django.template.Context एक वैकल्पिक तर्क लेता है - एक शब्दकोश मैपिंग चर नामों को चर मानों के लिए।

विवरण के लिए, नीचे दिए गए संदर्भ वस्तुओं के साथ खेलना देखें।

Template.render(context) [source]

Template ऑब्जेक्ट के render() कॉल करें render() विधि के Context में "टेम्पलेट" भरें:

>>> from django.template import Context, Template
>>> template = Template("My name is {{ my_name }}.")

>>> context = Context({"my_name": "Adrian"})
>>> template.render(context)
"My name is Adrian."

>>> context = Context({"my_name": "Dolores"})
>>> template.render(context)
"My name is Dolores."

चर और लुकअप

परिवर्तनीय नामों में किसी भी अक्षर (AZ), किसी भी अंक (0-9), एक अंडरस्कोर (लेकिन उन्हें अंडरस्कोर से शुरू नहीं होना चाहिए) या एक डॉट शामिल होना चाहिए।

टेम्पलेट रेंडरिंग में डॉट्स का एक विशेष अर्थ है। एक चर नाम में एक डॉट लुकअप को दर्शाता है। विशेष रूप से, जब टेम्पलेट सिस्टम एक चर नाम में एक डॉट का सामना करता है, तो यह इस क्रम में निम्नलिखित लुकअप की कोशिश करता है:

  • शब्दकोश खोज। उदाहरण: foo["bar"]
  • देखने का गुण। उदाहरण: foo.bar
  • सूची-सूचकांक लुकअप। उदाहरण: foo[bar]

ध्यान दें कि {{ foo.bar }} जैसे टेम्पलेट अभिव्यक्ति में "बार" की व्याख्या एक शाब्दिक स्ट्रिंग के रूप में की जाएगी और यदि टेम्पलेट संदर्भ में मौजूद है तो "बार" के मान का उपयोग नहीं किया जाएगा।

टेम्पलेट सिस्टम पहले लुकअप प्रकार का उपयोग करता है जो काम करता है। यह शॉर्ट-सर्किट लॉजिक है। कुछ उदाहरण निम्नलिखित हैं:

>>> from django.template import Context, Template
>>> t = Template("My name is {{ person.first_name }}.")
>>> d = {"person": {"first_name": "Joe", "last_name": "Johnson"}}
>>> t.render(Context(d))
"My name is Joe."

>>> class PersonClass: pass
>>> p = PersonClass()
>>> p.first_name = "Ron"
>>> p.last_name = "Nasty"
>>> t.render(Context({"person": p}))
"My name is Ron."

>>> t = Template("The first stooge in the list is {{ stooges.0 }}.")
>>> c = Context({"stooges": ["Larry", "Curly", "Moe"]})
>>> t.render(c)
"The first stooge in the list is Larry."

यदि चर का कोई भी भाग कॉल करने योग्य है, तो टेम्पलेट सिस्टम इसे कॉल करने का प्रयास करेगा। उदाहरण:

>>> class PersonClass2:
...     def name(self):
...         return "Samantha"
>>> t = Template("My name is {{ person.name }}.")
>>> t.render(Context({"person": PersonClass2}))
"My name is Samantha."

कॉल करने योग्य चर वैरिएबल की तुलना में थोड़ा अधिक जटिल होते हैं जिनके लिए केवल सीधे लुकअप की आवश्यकता होती है। यहाँ कुछ बातों का ध्यान रखना है:

  • यदि चर को बुलाया जाने पर कोई अपवाद नहीं उठाया जाता है, तो अपवाद को प्रचारित किया जाएगा, जब तक कि अपवाद में एक विशेषता silent_variable_failure है। यदि अपवाद में एक silent_variable_failure विशेषता है जिसका मान True , तो चर इंजन के string_if_invalid कॉन्फ़िगरेशन विकल्प (डिफ़ॉल्ट रूप से एक रिक्त स्ट्रिंग) के मान के रूप में प्रस्तुत करेगा। उदाहरण:

    >>> t = Template("My name is {{ person.first_name }}.")
    >>> class PersonClass3:
    ...     def first_name(self):
    ...         raise AssertionError("foo")
    >>> p = PersonClass3()
    >>> t.render(Context({"person": p}))
    Traceback (most recent call last):
    ...
    AssertionError: foo
    
    >>> class SilentAssertionError(Exception):
    ...     silent_variable_failure = True
    >>> class PersonClass4:
    ...     def first_name(self):
    ...         raise SilentAssertionError
    >>> p = PersonClass4()
    >>> t.render(Context({"person": p}))
    "My name is ."
    

    ध्यान दें कि django.core.exceptions.ObjectDoesNotExist , जो सभी Django डेटाबेस API DoesNotExist अपवादों के लिए आधार वर्ग है, में silent_variable_failure = True । इसलिए यदि आप Django मॉडल ऑब्जेक्ट्स के साथ Django टेम्प्लेट का उपयोग कर रहे हैं, तो कोई भी DoesNotExist अपवाद चुपचाप विफल हो जाएगा।

  • एक चर को केवल तभी कहा जा सकता है जब उसके पास कोई आवश्यक तर्क न हो। अन्यथा, सिस्टम इंजन के string_if_invalid विकल्प का मान लौटा देगा।
  • जाहिर है, कुछ चरों को कॉल करते समय साइड इफेक्ट्स हो सकते हैं, और यह या तो मूर्ख होगा या टेम्पलेट सिस्टम को एक्सेस करने की अनुमति देने के लिए एक सुरक्षा छेद होगा।

    एक अच्छा उदाहरण प्रत्येक Django मॉडल ऑब्जेक्ट पर delete() विधि है। टेम्प्लेट सिस्टम को ऐसा कुछ करने की अनुमति नहीं दी जानी चाहिए:

    I will now delete this valuable data. {{ data.delete }}
    

    इसे रोकने के लिए, alters_data करने योग्य चर पर एक alters_data विशेषता सेट करें। अगर यह alters_data=True सेट है, तो टेम्प्लेट सिस्टम एक वैरिएबल को कॉल नहीं करेगा, और इसके बजाय बिना string_if_invalid साथ वेरिएबल को बदल देगा। Django मॉडल ऑब्जेक्ट्स पर डायनामिक रूप से जेनरेट किए गए delete() और save() तरीके स्वचालित रूप से alters_data=True प्राप्त alters_data=True । उदाहरण:

    def sensitive_function(self):
        self.database_record.delete()
    sensitive_function.alters_data = True
    
  • कभी-कभी आप अन्य कारणों से इस सुविधा को बंद करना चाहते हैं, और टेम्प्लेट सिस्टम को यह बता सकते हैं कि एक चर को छोड़ दिया जाए, इससे कोई फर्क नहीं पड़ता। ऐसा करने के लिए, मान True साथ do_not_call_in_templates करने योग्य पर do_not_call_in_templates विशेषता सेट करें। टेम्प्लेट सिस्टम तब कार्य करेगा जैसे कि आपका वैरिएबल कॉल करने योग्य नहीं है (उदाहरण के लिए, आपको कॉल करने योग्य गुणों को एक्सेस करने की अनुमति देता है)।

अमान्य चर को कैसे संभाला जाता है

आम तौर पर, यदि कोई चर मौजूद नहीं है, तो टेम्पलेट सिस्टम इंजन के string_if_invalid कॉन्फ़िगरेशन विकल्प का मूल्य सम्मिलित करता है, जो डिफ़ॉल्ट रूप से '' (खाली स्ट्रिंग) पर सेट है।

अमान्य चर पर लागू होने वाले फ़िल्टर तभी लागू होंगे जब string_if_invalid '' (खाली स्ट्रिंग) पर सेट हो। यदि string_if_invalid को किसी अन्य मान पर सेट किया जाता है, तो चर फ़िल्टर को अनदेखा किया जाएगा।

टेम्प्लेट टैग के for , के for यह व्यवहार थोड़ा अलग है। यदि इन टेम्प्लेट टैग में से एक को अमान्य चर प्रदान किया जाता है, तो चर की व्याख्या किसी के रूप में None । इन टेम्प्लेट टैग में फ़िल्टर हमेशा अमान्य चर पर लागू होते हैं।

यदि string_if_invalid में '%s' , तो प्रारूप मार्कर को अमान्य चर के नाम से बदल दिया जाएगा।

केवल डिबग उद्देश्यों के लिए!

जबकि string_if_invalid एक उपयोगी डिबगिंग टूल हो सकता है, इसे 'विकास डिफ़ॉल्ट' के रूप में चालू करना एक बुरा विचार है।

कई टेम्पलेट, व्यवस्थापक साइट के उन लोगों सहित, टेम्पलेट सिस्टम की चुप्पी पर भरोसा करते हैं जब कोई भी न होने वाला चर सामने आता है। यदि आप string_if_invalid को '' अलावा कोई मान असाइन करते हैं, तो आप इन टेम्प्लेट और साइट्स के साथ रेंडरिंग समस्याओं का अनुभव करेंगे।

आम तौर पर, string_if_invalid को केवल एक विशिष्ट टेम्प्लेट समस्या को डीबग करने के लिए सक्षम किया जाना चाहिए, फिर डीबगिंग पूर्ण होने के बाद साफ़ किया गया।

निर्मित चर

हर प्रसंग में True , False और None । जैसा कि आप उम्मीद करेंगे, ये चर संबंधित पिस्टन ऑब्जेक्ट्स के लिए हल होते हैं।

स्ट्रिंग शाब्दिक के साथ सीमाएं

Django की टेम्पलेट भाषा के पास अपने स्वयं के सिंटैक्स के लिए उपयोग किए गए वर्णों से बचने का कोई तरीका नहीं है। उदाहरण के लिए, templatetag टैग की आवश्यकता है यदि आपको {% और %} जैसे चरित्र अनुक्रमों को आउटपुट करने की आवश्यकता है।

एक समान समस्या मौजूद है यदि आप इन अनुक्रमों को टेम्पलेट फ़िल्टर या टैग तर्कों में शामिल करना चाहते हैं। उदाहरण के लिए, ब्लॉक टैग को पार्स करते समय, Django के टेम्पलेट पार्सर एक {% बाद %} की पहली घटना के लिए दिखता है। यह एक स्ट्रिंग शाब्दिक के रूप में "%}" के उपयोग को रोकता है। उदाहरण के लिए, एक TemplateSyntaxError निम्नलिखित भावों के लिए उठाया जाएगा:

{% include "template.html" tvar="Some string literal with %} in it." %}

{% with tvar="Some string literal with %} in it." %}{% endwith %}

फ़िल्टर तर्क में आरक्षित अनुक्रम का उपयोग करके समान समस्या को ट्रिगर किया जा सकता है:

{{ some.variable|default:"}}" }}

यदि आपको इन अनुक्रमों के साथ तार का उपयोग करने की आवश्यकता है, तो उन्हें टेम्पलेट चर में संग्रहीत करें या सीमा को हल करने के लिए एक कस्टम टेम्पलेट टैग या फ़िल्टर का उपयोग करें।

Context वस्तुओं के साथ खेलना

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

>>> from django.template import Context
>>> c = Context({"foo": "bar"})
>>> c['foo']
'bar'
>>> del c['foo']
>>> c['foo']
Traceback (most recent call last):
...
KeyError: 'foo'
>>> c['newvariable'] = 'hello'
>>> c['newvariable']
'hello'
Context.get(key, otherwise=None)

key लिए मान देता है यदि key संदर्भ में है, तो otherwise वापस आती otherwise

Context.setdefault(key, default=None)

यदि key संदर्भ में है, तो उसका मान लौटाता है। अन्यथा key को default मान के साथ सम्मिलित करता है और default लौटाता default

Context.pop()
Context.push()
exception ContextPopException [source]

एक Context वस्तु एक स्टैक है। यही है, आप इसे push() दे सकते हैं push() और pop() । यदि आप बहुत अधिक pop() करते हैं, तो यह django.template.ContextPopException :

>>> c = Context()
>>> c['foo'] = 'first level'
>>> c.push()
{}
>>> c['foo'] = 'second level'
>>> c['foo']
'second level'
>>> c.pop()
{'foo': 'second level'}
>>> c['foo']
'first level'
>>> c['foo'] = 'overwritten'
>>> c['foo']
'overwritten'
>>> c.pop()
Traceback (most recent call last):
...
ContextPopException

मिलान pop() को सुनिश्चित करने के लिए आप संदर्भ प्रबंधक के रूप में push() का भी उपयोग कर सकते हैं।

>>> c = Context()
>>> c['foo'] = 'first level'
>>> with c.push():
...     c['foo'] = 'second level'
...     c['foo']
'second level'
>>> c['foo']
'first level'

push() करने के push() पारित सभी तर्क push() नए संदर्भ स्तर के निर्माण के लिए उपयोग किए जाने वाले dict को पारित किए जाएंगे।

>>> c = Context()
>>> c['foo'] = 'first level'
>>> with c.push(foo='second level'):
...     c['foo']
'second level'
>>> c['foo']
'first level'
Context.update(other_dict) [source]

push() और pop() , Context ऑब्जेक्ट भी एक update() विधि को परिभाषित करता है। यह push() तरह काम करता है push() लेकिन एक डिक्शनरी के रूप में एक डिक्शनरी लेता है और उस डिक्शनरी को स्टैक पर खाली करने के बजाय पुश करता है।

>>> c = Context()
>>> c['foo'] = 'first level'
>>> c.update({'foo': 'updated'})
{'foo': 'updated'}
>>> c['foo']
'updated'
>>> c.pop()
{'foo': 'updated'}
>>> c['foo']
'first level'

push() तरह push() , आप मैचिंग pop() को सुनिश्चित करने के लिए संदर्भ प्रबंधक के रूप में update() उपयोग कर सकते हैं।

>>> c = Context()
>>> c['foo'] = 'first level'
>>> with c.update({'foo': 'second level'}):
...     c['foo']
'second level'
>>> c['foo']
'first level'

एक कस्टम के रूप में एक Context का उपयोग करना कुछ कस्टम टेम्पलेट टैग में काम आता है।

Context.flatten()

flatten() विधि का उपयोग करके आप बिल्ट चर सहित एक शब्दकोश के रूप में पूरे Context ढेर प्राप्त कर सकते हैं।

>>> c = Context()
>>> c['foo'] = 'first level'
>>> c.update({'bar': 'second level'})
{'bar': 'second level'}
>>> c.flatten()
{'True': True, 'None': None, 'foo': 'first level', 'False': False, 'bar': 'second level'}

flatten() वस्तुओं को तुलनीय बनाने के लिए एक flatten() विधि का भी आंतरिक रूप से उपयोग किया जाता है।

>>> c1 = Context()
>>> c1['foo'] = 'first level'
>>> c1['bar'] = 'second level'
>>> c2 = Context()
>>> c2.update({'bar': 'second level', 'foo': 'first level'})
{'foo': 'first level', 'bar': 'second level'}
>>> c1 == c2
True

चपटे से परिणाम flatten() इकाई परीक्षणों में उपयोगी हो सकता है Context खिलाफ Context तुलना करने के लिए:

class ContextTest(unittest.TestCase):
    def test_against_dictionary(self):
        c1 = Context()
        c1['update'] = 'value'
        self.assertEqual(c1.flatten(), {
            'True': True,
            'None': None,
            'False': False,
            'update': 'value',
        })

RequestContext का उपयोग करना

class RequestContext(request, dict_=None, processors=None) [source]

Django एक विशेष Context वर्ग, django.template.RequestContext साथ आता है, जो सामान्य django.template.Context से थोड़ा अलग कार्य करता है। पहला अंतर यह है कि यह HttpRequest को इसके पहले तर्क के रूप में लेता है। उदाहरण के लिए:

c = RequestContext(request, {
    'foo': 'bar',
})

दूसरा अंतर यह है कि यह इंजन के context_processors कॉन्फ़िगरेशन विकल्प के अनुसार स्वचालित रूप से कुछ चर के साथ संदर्भ को पॉप्युलेट करता है।

context_processors विकल्प context_processors की एक सूची है - जिसे संदर्भ प्रोसेसर कहा जाता है - जो कि एक अनुरोध वस्तु को उनके तर्क के रूप में लेते हैं और संदर्भ में विलय होने के लिए आइटम का एक शब्दकोश लौटाते हैं। डिफ़ॉल्ट जनरेट की गई सेटिंग फ़ाइल में, डिफ़ॉल्ट टेम्पलेट इंजन में निम्नलिखित संदर्भ प्रोसेसर होते हैं:

[
    'django.template.context_processors.debug',
    'django.template.context_processors.request',
    'django.contrib.auth.context_processors.auth',
    'django.contrib.messages.context_processors.messages',
]

इनके अतिरिक्त, RequestContext हमेशा 'django.template.context_processors.csrf' सक्षम करता है। यह एक सुरक्षा से संबंधित संदर्भ प्रोसेसर है जो व्यवस्थापक और अन्य कंट्रिब एप्लिकेशन द्वारा आवश्यक है, और आकस्मिक गलतफहमी के मामले में, इसे जानबूझकर हार्डकोड किया गया है और इसे context_processors विकल्प में बंद नहीं किया जा सकता है।

प्रत्येक प्रोसेसर क्रम में लागू किया जाता है। इसका मतलब है, यदि एक प्रोसेसर संदर्भ में एक चर जोड़ता है और दूसरा प्रोसेसर एक ही नाम के साथ एक चर जोड़ता है, तो दूसरा पहले को ओवरराइड करेगा। डिफ़ॉल्ट प्रोसेसर नीचे दिए गए हैं।

जब संदर्भ प्रोसेसर लागू होते हैं

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

यदि आप संदर्भ प्रोसेसर पर प्राथमिकता लेने के लिए संदर्भ डेटा चाहते हैं, तो निम्न पैटर्न का उपयोग करें:

from django.template import RequestContext

request_context = RequestContext(request)
request_context.push({"my_name": "Adrian"})

Django ऐसा करता है कि संदर्भ डेटा को APIs में संदर्भ प्रोसेसर जैसे render() और TemplateResponse को ओवरराइड करने की अनुमति मिलती है।

इसके अलावा, आप वैकल्पिक, तीसरे स्थितीय तर्क, processors का उपयोग करके RequestContext को अतिरिक्त प्रोसेसर की एक सूची दे सकते हैं। इस उदाहरण में, RequestContext उदाहरण को एक ip_address चर मिलता है:

from django.http import HttpResponse
from django.template import RequestContext, Template

def ip_address_processor(request):
    return {'ip_address': request.META['REMOTE_ADDR']}

def client_ip_view(request):
    template = Template('{{ title }}: {{ ip_address }}')
    context = RequestContext(request, {
        'title': 'Your IP Address',
    }, [ip_address_processor])
    return HttpResponse(template.render(context))

अंतर्निहित टेम्पलेट संदर्भ प्रोसेसर

यहां प्रत्येक अंतर्निहित प्रोसेसर क्या करता है:

django.contrib.auth.context_processors.auth

[source] auth() [source]

यदि यह प्रोसेसर सक्षम है, तो प्रत्येक RequestContext में ये चर होंगे:

  • user - वर्तमान में लॉग-इन उपयोगकर्ता (या क्लाइंट का लॉग इन नहीं होने पर एक AnonymousUser auth.User प्रतिनिधित्व करने वाली एक auth.User
  • perms - django.contrib.auth.context_processors.PermWrapper का एक उदाहरण, उन अनुमतियों का प्रतिनिधित्व करता है जो वर्तमान में लॉग-इन उपयोगकर्ता के पास है।

django.template.context_processors.debug

debug() [source]

यदि यह प्रोसेसर सक्षम है, तो प्रत्येक RequestContext में ये दो चर होंगे - लेकिन केवल तब जब आपकी DEBUG सेटिंग सही पर सेट हो और अनुरोध का IP पता ( request.META['REMOTE_ADDR'] ) INTERNAL_IPS सेटिंग में हो:

  • debug - True । आप परीक्षण में इसका उपयोग कर सकते हैं कि क्या आप DEBUG मोड में हैं या नहीं।
  • sql_queries - {'sql': ..., 'time': ...} की एक सूची {'sql': ..., 'time': ...} शब्दकोश, अनुरोध के दौरान अब तक हुई प्रत्येक SQL क्वेरी का प्रतिनिधित्व करता है और इसमें कितना समय लगा। सूची डेटाबेस उपनाम और फिर क्वेरी द्वारा क्रम में है। यह आलस्य से उत्पन्न होता है।

django.template.context_processors.i18n

i18n() [source]

यदि यह प्रोसेसर सक्षम है, तो प्रत्येक RequestContext में ये चर होंगे:

  • LANGUAGES - LANGUAGES सेटिंग का मूल्य।
  • LANGUAGE_BIDI - True यदि वर्तमान भाषा दाईं से बाईं ओर की भाषा है, जैसे हिब्रू, अरबी। अगर यह एक बाएं से दाएं भाषा है, जैसे कि अंग्रेजी, फ्रेंच, जर्मन।
  • LANGUAGE_CODE - request.LANGUAGE_CODE , यदि यह मौजूद है। अन्यथा, LANGUAGE_CODE सेटिंग का मान।

समान मूल्यों को उत्पन्न करने वाले टेम्प्लेट टैग के लिए i18n टेम्प्लेट टैग देखें।

django.template.context_processors.media

यदि यह प्रोसेसर सक्षम है, तो हर RequestContext में एक चर MEDIA_URL , जो MEDIA_URL सेटिंग का मान प्रदान करेगा।

django.template.context_processors.static

static() [source]

यदि यह प्रोसेसर सक्षम है, तो हर RequestContext में एक वैरिएबल STATIC_URL , जो STATIC_URL सेटिंग का मान प्रदान करेगा।

django.template.context_processors.csrf

यह प्रोसेसर क्रॉस साइट रिक्वेस्ट फोर्सेज के खिलाफ सुरक्षा के लिए csrf_token टेम्प्लेट टैग द्वारा आवश्यक टोकन जोड़ता है।

django.template.context_processors.request

यदि यह प्रोसेसर सक्षम है, तो प्रत्येक RequestContext में एक चर request , जो वर्तमान HttpRequest

django.template.context_processors.tz

tz() [source]

यदि यह प्रोसेसर सक्षम है, तो प्रत्येक RequestContext में एक चर TIME_ZONE , जो वर्तमान में सक्रिय समय क्षेत्र का नाम प्रदान करता है।

django.contrib.messages.context_processors.messages

यदि यह प्रोसेसर सक्षम है, तो प्रत्येक RequestContext में ये दो चर होंगे:

अपने खुद के संदर्भ प्रोसेसर लेखन

एक संदर्भ प्रोसेसर का एक बहुत ही सरल इंटरफ़ेस है: यह एक पायथन फ़ंक्शन है जो एक तर्क, एक HttpRequest ऑब्जेक्ट लेता है, और एक शब्दकोश देता है जो टेम्पलेट संदर्भ में जोड़ा जाता है। प्रत्येक संदर्भ प्रोसेसर को एक शब्दकोश वापस करना होगा

कस्टम संदर्भ प्रोसेसर आपके कोड बेस में कहीं भी रह सकते हैं। सभी Django के बारे में परवाह है कि आपके कस्टम संदर्भ प्रोसेसर आपके TEMPLATES सेटिंग में 'context_processors' विकल्प द्वारा इंगित किए जाते हैं - या यदि आप इसे सीधे उपयोग कर रहे हैं, तो context_processors तर्क।

लोड हो रहा है टेम्पलेट्स

आमतौर पर, आप निम्न-स्तरीय Template API का उपयोग करने के बजाय अपने फ़ाइल सिस्टम पर फ़ाइलों में टेम्पलेट संग्रहीत करते हैं। टेम्प्लेट निर्देशिका के रूप में निर्दिष्ट निर्देशिका में टेम्प्लेट सहेजें।

Django आपके टेम्पलेट लोडिंग सेटिंग्स (नीचे "लोडर प्रकार देखें") के आधार पर कई स्थानों पर टेम्पलेट निर्देशिकाओं की खोज करता है, लेकिन DIRS विकल्प का उपयोग करके टेम्पलेट निर्देशिकाओं को निर्दिष्ट करने का सबसे मूल तरीका है।

DIRS विकल्प

Django को बताएं कि आपकी सेटिंग फ़ाइल में TEMPLATES सेटिंग में DIRS विकल्प का उपयोग करके आपके टेम्पलेट निर्देशिकाएं क्या हैं - या Engine के dirs तर्क। इसे उन स्ट्रिंग्स की सूची पर सेट किया जाना चाहिए, जिनमें आपकी टेम्पलेट निर्देशिकाओं के लिए पूरे रास्ते हैं:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            '/home/html/templates/lawrence.com',
            '/home/html/templates/default',
        ],
    },
]

जब तक निर्देशिकाएं और टेम्पलेट वेब सर्वर द्वारा पठनीय हैं, तब तक आपके टेम्पलेट कहीं भी जा सकते हैं। उनके पास कोई भी एक्सटेंशन हो सकता है, जैसे कि .html या .txt , या उनका कोई एक्सटेंशन नहीं हो सकता है।

ध्यान दें कि इन रास्तों को विंडोज पर भी यूनिक्स-स्टाइल फॉरवर्ड स्लैश का उपयोग करना चाहिए।

लोडर प्रकार

डिफ़ॉल्ट रूप से, Django एक फाइल-सिस्टम-आधारित टेम्पलेट लोडर का उपयोग करता है, लेकिन Django कुछ अन्य टेम्पलेट लोडर के साथ आता है, जो अन्य स्रोतों से टेम्पलेट लोड करना जानते हैं।

इनमें से कुछ अन्य लोडर डिफ़ॉल्ट रूप से अक्षम होते हैं, लेकिन आप Engine loaders तर्क स्थापित करने या पास करने के लिए अपने DjangoTemplates बैकएंड में एक 'loaders' विकल्प जोड़कर उन्हें सक्रिय कर सकते हैं। loaders स्ट्रिंग्स या ट्यूपल्स की एक सूची होनी चाहिए, जहां प्रत्येक टेम्पलेट लोडर वर्ग का प्रतिनिधित्व करता है। यहाँ टेम्पलेट लोडर हैं जो Django के साथ आते हैं:

django.template.loaders.filesystem.Loader

class filesystem.Loader

फ़ाइल सिस्टम से लोड टेम्पलेट, DIRS अनुसार।

यह लोडर डिफ़ॉल्ट रूप से सक्षम है। जब तक आप DIRS को गैर-रिक्त सूची में सेट नहीं करते हैं, तब तक यह कोई भी टेम्प्लेट नहीं होगा:

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [os.path.join(BASE_DIR, 'templates')],
}]

आप 'DIRS' को भी ओवरराइड कर सकते हैं और किसी विशेष फाइलसिस्टम लोडर के लिए विशिष्ट निर्देशिकाओं को निर्दिष्ट कर सकते हैं:

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'OPTIONS': {
        'loaders': [
            (
                'django.template.loaders.filesystem.Loader',
                [os.path.join(BASE_DIR, 'templates')],
            ),
        ],
    },
}]

django.template.loaders.app_directories.Loader

class app_directories.Loader

फाइल सिस्टम पर Django ऐप्स के लोड टेम्प्लेट। INSTALLED_APPS में प्रत्येक ऐप के लिए, लोडर एक templates उपनिर्देशिका की तलाश करता है। यदि निर्देशिका मौजूद है, तो Django वहाँ के टेम्पलेट्स की तलाश करता है।

इसका मतलब है कि आप अपने व्यक्तिगत ऐप्स के साथ टेम्प्लेट स्टोर कर सकते हैं। यह डिफ़ॉल्ट टेम्पलेट के साथ Django एप्लिकेशन को वितरित करना भी आसान बनाता है।

उदाहरण के लिए, इस सेटिंग के लिए:

INSTALLED_APPS = ['myproject.polls', 'myproject.music']

... तो get_template('foo.html') इन निर्देशिकाओं में foo.html लिए इस क्रम में दिखेगा:

  • /path/to/myproject/polls/templates/
  • /path/to/myproject/music/templates/

... और इसका उपयोग वह पहले पाता है।

INSTALLED_APPS का क्रम महत्वपूर्ण है! उदाहरण के लिए, यदि आप Django व्यवस्थापक को अनुकूलित करना चाहते हैं, तो आप myproject.polls में अपने स्वयं के admin/base_site.html साथ django.contrib.admin से मानक admin/base_site.html टेम्पलेट को ओवरराइड करना चुन सकते हैं। फिर आपको यह सुनिश्चित करना चाहिए कि आपका myproject.polls django.contrib.admin से पहले INSTALLED_APPS में आता है, अन्यथा django.contrib.admin पहले लोड किया जाएगा और आपकी अनदेखी की जाएगी।

ध्यान दें कि लोडर एक अनुकूलन करता है जब यह पहली बार चलता है: यह एक सूची को कैश करता है जिसमें INSTALLED_APPS पैकेज का एक templates उपनिर्देशिका है।

आप इस लोडर को केवल True APP_DIRS सेट करके सक्षम कर सकते हैं:

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'APP_DIRS': True,
}]

django.template.loaders.cached.Loader

class cached.Loader

डिफ़ॉल्ट रूप से (जब DEBUG True ), टेम्प्लेट सिस्टम हर बार आपके टेम्पलेट को पढ़ता और संकलित करता है। जबकि Django टेम्पलेट सिस्टम काफी तेज़ है, पढ़ने और संकलन करने वाले ओवरहेड को जोड़ सकते हैं।

आप कैश्ड टेम्पलेट लोडर को अन्य लोडर की सूची के साथ कॉन्फ़िगर करते हैं जिसे इसे लपेटना चाहिए। लिपटे लोडर का उपयोग अज्ञात टेम्प्लेट का पता लगाने के लिए किया जाता है जब वे पहली बार सामने आते हैं। कैश्ड लोडर फिर मेमोरी में संकलित Template को संग्रहीत करता है। कैश्ड Template उदाहरण उसी टेम्पलेट को लोड करने के लिए बाद के अनुरोधों के लिए वापस आ गया है।

यह लोडर स्वचालित रूप से सक्षम है यदि OPTIONS['loaders'] निर्दिष्ट नहीं है और OPTIONS['loaders'] False ( DEBUG के मूल्य के लिए बाद वाला विकल्प DEBUG )।

आप इस तरह सेटिंग्स का उपयोग करके कुछ कस्टम टेम्पलेट लोडर के साथ टेम्पलेट कैशिंग को भी सक्षम कर सकते हैं:

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [os.path.join(BASE_DIR, 'templates')],
    'OPTIONS': {
        'loaders': [
            ('django.template.loaders.cached.Loader', [
                'django.template.loaders.filesystem.Loader',
                'django.template.loaders.app_directories.Loader',
                'path.to.custom.Loader',
            ]),
        ],
    },
}]

ध्यान दें

बिल्ट-इन Django टेम्प्लेट टैग के सभी कैश्ड लोडर के साथ उपयोग करने के लिए सुरक्षित हैं, लेकिन यदि आप कस्टम टेम्पलेट टैग का उपयोग कर रहे हैं जो तीसरे पक्ष के पैकेज से आते हैं, या जिसे आपने खुद लिखा है, तो आपको यह सुनिश्चित करना चाहिए कि प्रत्येक टैग के लिए Node कार्यान्वयन धागा सुरक्षित है। अधिक जानकारी के लिए, टेम्प्लेट टैग थ्रेड सुरक्षा विचार देखें

django.template.loaders.locmem.Loader

class locmem.Loader

एक पायथन शब्दकोश से लोड टेम्पलेट्स। यह परीक्षण के लिए उपयोगी है।

यह लोडर पहले तर्क के रूप में टेम्पलेट्स का शब्दकोश लेता है:

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'OPTIONS': {
        'loaders': [
            ('django.template.loaders.locmem.Loader', {
                'index.html': 'content here',
            }),
        ],
    },
}]

यह लोडर डिफ़ॉल्ट रूप से अक्षम है।

Django 'loaders' विकल्प के अनुसार टेम्पलेट लोडर का उपयोग करता है। यह प्रत्येक लोडर का उपयोग करता है जब तक कि एक लोडर एक मैच नहीं पाता है।

कस्टम लोडर

कस्टम टेम्पलेट लोडर का उपयोग करके अतिरिक्त स्रोतों से टेम्प्लेट लोड करना संभव है। कस्टम Loader वर्गों को django.template.loaders.base.Loader से इनहेरिट करना चाहिए और get_contents() और get_template_sources() विधियों को परिभाषित करना चाहिए।

लोडर के तरीके

class Loader [source]

किसी दिए गए स्रोत से लोड हो जाता है, जैसे कि फाइलसिस्टम या डेटाबेस।

get_template_sources(template_name) [source]

एक विधि जो एक template_name लेती है और प्रत्येक संभावित स्रोत के लिए Origin उदाहरण देती है।

उदाहरण के लिए, फ़ाइलसिस्टम लोडर को 'index.html' एक template_name तर्क के रूप में प्राप्त हो सकता है। यह विधि index.html के पूर्ण पथ के लिए उत्पन्न होती है क्योंकि यह प्रत्येक टेम्प्लेट निर्देशिका में लोडर को दिखता है।

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

get_contents(origin)

Origin उदाहरण दिए गए टेम्पलेट के लिए सामग्री लौटाता है।

यह वह जगह है जहां एक फाइलसिस्टम लोडर फाइलसिस्टम से सामग्री पढ़ेगा, या एक डेटाबेस लोडर डेटाबेस से पढ़ेगा। यदि कोई मेल खाने वाला टेम्प्लेट मौजूद नहीं है, तो इसे TemplateDoesNotExist त्रुटि को उठाना चाहिए।

get_template(template_name, skip=None) [source]

get_template_sources() और कॉल get_contents() से परिणाम के माध्यम से पाशन करके किसी दिए गए template_name लिए एक Template ऑब्जेक्ट लौटाता है। यह पहला मिलान टेम्पलेट लौटाता है। यदि कोई टेम्पलेट नहीं मिला है, तो TemplateDoesNotExist उठाया जाता है।

वैकल्पिक skip तर्क टेम्प्लेट करते समय अनदेखी करने के लिए उत्पत्ति की सूची है। इससे टेम्प्लेट समान नाम के अन्य टेम्प्लेट का विस्तार कर सकते हैं। यह भी पुनरावृत्ति त्रुटियों से बचने के लिए इस्तेमाल किया।

सामान्य तौर पर, यह कस्टम टेम्पलेट लोडर के लिए get_template_sources() और get_contents() को परिभाषित करने के लिए पर्याप्त है। get_template() को आमतौर पर ओवरराइड करने की आवश्यकता नहीं होगी।

टेम्प्लेट की उत्पत्ति

टेम्प्लेट में एक origin विशेषता होती है, जिस स्रोत से वे लोड किए जाते हैं, उसके आधार पर।

class Origin(name, template_name=None, loader=None) [source]
name

टेम्प्लेट लोडर द्वारा लौटाए गए टेम्प्लेट का पथ। लोडर के लिए जो फ़ाइल सिस्टम से पढ़ा जाता है, यह टेम्पलेट का पूर्ण पथ है।

यदि टेम्प्लेट को लोडर के माध्यम से सीधे <unknown_source> जाता है, तो यह <unknown_source> का एक स्ट्रिंग मान है।

template_name

टेम्प्लेट लोडर में दिए गए टेम्प्लेट के सापेक्ष पथ।

यदि टेम्प्लेट को लोडर के माध्यम से सीधे चलाया जाता है, तो यह None

loader

टेम्पलेट लोडर इंस्टेंस जिसने इस Origin निर्माण किया।

यदि टेम्प्लेट को लोडर के माध्यम से सीधे चलाया जाता है, तो यह None

django.template.loaders.cached.Loader को अपने सभी लिपटे लोडरों को यह विशेषता सेट करने की आवश्यकता होती है, आमतौर पर loader=self साथ Origin को तत्काल करके।

Original text