Django 2.1

Templates




django

Templates

वेब फ्रेमवर्क होने के नाते, Django को गतिशील रूप से HTML उत्पन्न करने के लिए एक सुविधाजनक तरीका चाहिए। सबसे आम दृष्टिकोण टेम्पलेट्स पर निर्भर करता है। एक टेम्पलेट में वांछित HTML आउटपुट के स्थिर भागों के साथ-साथ कुछ विशेष वाक्यविन्यास शामिल हैं जो यह बताता है कि गतिशील सामग्री कैसे डाली जाएगी। टेम्पलेट के साथ HTML पेज बनाने के लिए एक हैंड्स-ऑन उदाहरण के लिए, ट्यूटोरियल 3 देखें।

एक Django परियोजना को एक या कई टेम्पलेट इंजन (या यहां तक ​​कि अगर आप टेम्पलेट का उपयोग नहीं करते हैं तो भी शून्य) के साथ कॉन्फ़िगर किया जा सकता है। Django के जहाज अपने स्वयं के टेम्पलेट सिस्टम के लिए बैकएंड में निर्मित होते हैं, जिसे रचनात्मक रूप से Django टेम्पलेट भाषा (DTL) कहा जाता है, और लोकप्रिय वैकल्पिक Jinja2 । अन्य टेम्प्लेट भाषाओं के बैकएंड तृतीय-पक्ष से उपलब्ध हो सकते हैं।

Django बैकएंड की परवाह किए बिना टेम्प्लेट लोड करने और रेंडर करने के लिए एक मानक एपीआई को परिभाषित करता है। लोडिंग में किसी दिए गए पहचानकर्ता के लिए खाका ढूंढना और उसे पूर्वप्रक्रमित करना, आमतौर पर इन-मेमोरी प्रतिनिधित्व को संकलित करना शामिल है। रेंडरिंग का अर्थ है संदर्भ डेटा के साथ टेम्पलेट को इंटरपोल करना और परिणामी स्ट्रिंग को वापस करना।

Django टेम्पलेट भाषा Django की अपनी टेम्पलेट प्रणाली है। Django 1.8 तक यह एकमात्र निर्मित विकल्प था। यह एक अच्छा खाका पुस्तकालय है, भले ही यह काफी हद तक रायशुमारी और खेल है। यदि आपके पास एक और बैकएंड चुनने का दबाव नहीं है, तो आपको DTL का उपयोग करना चाहिए, खासकर यदि आप एक प्लग करने योग्य एप्लिकेशन लिख रहे हैं और आप टेम्पलेट वितरित करने का इरादा रखते हैं। Django के django.contrib.admin ऐप्स जिनमें django.contrib.admin जैसे टेम्पलेट शामिल हैं, DTL का उपयोग करते हैं।

ऐतिहासिक कारणों से, टेम्पलेट इंजनों के लिए सामान्य समर्थन और Django टेम्प्लेट भाषा के कार्यान्वयन दोनों django.template नामस्थान में रहते हैं।

चेतावनी

टेम्प्लेट सिस्टम बिना अविश्वसनीय टेम्पलेट लेखकों के सुरक्षित नहीं है। उदाहरण के लिए, एक साइट को अपने उपयोगकर्ताओं को अपने स्वयं के टेम्प्लेट प्रदान करने की अनुमति नहीं देनी चाहिए, क्योंकि टेम्प्लेट लेखक XSS हमलों और टेम्पलेट वेरिएबल्स की पहुंच गुणों जैसी चीजें कर सकते हैं जिनमें संवेदनशील जानकारी हो सकती है।

टेम्पलेट इंजन के लिए समर्थन

विन्यास

टेम्प्लेट इंजन को टेम्प्लेट सेटिंग के साथ कॉन्फ़िगर किया गया है। यह विन्यास की एक सूची है, प्रत्येक इंजन के लिए एक। डिफ़ॉल्ट मान रिक्त है। startproject कमांड द्वारा उत्पन्न settings.py startproject अधिक उपयोगी मूल्य को परिभाषित करता है:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            # ... some options here ...
        },
    },
]

BACKEND , Django के टेम्पलेट बैकएंड एपीआई को लागू करने वाले एक टेम्पलेट इंजन वर्ग के लिए एक बिंदीदार पायथन पथ है। अंतर्निहित बैकएंड django.template.backends.django.DjangoTemplates और django.template.backends.jinja2.Jinja2

चूंकि अधिकांश इंजन फाइलों से टेम्प्लेट लोड करते हैं, प्रत्येक इंजन के लिए शीर्ष-स्तरीय कॉन्फ़िगरेशन में दो सामान्य सेटिंग्स होती हैं:

  • DIRS उन निर्देशिकाओं की एक सूची को परिभाषित करता है जहां इंजन को खोज क्रम में टेम्पलेट स्रोत फ़ाइलों की तलाश करनी चाहिए।
  • APP_DIRS बताता है कि क्या इंजन को स्थापित अनुप्रयोगों के अंदर खाके की तलाश करनी चाहिए। प्रत्येक बैकएंड अनुप्रयोगों के अंदर उपनिर्देशिका के लिए एक पारंपरिक नाम को परिभाषित करता है जहां इसके टेम्पलेट संग्रहीत किए जाने चाहिए।

असामान्य होने पर, विभिन्न विकल्पों के साथ एक ही बैकएंड के कई उदाहरणों को कॉन्फ़िगर करना संभव है। उस स्थिति में आपको प्रत्येक इंजन के लिए एक अद्वितीय NAME को परिभाषित करना चाहिए।

OPTIONS में बैकएंड-विशिष्ट सेटिंग्स शामिल हैं।

प्रयोग

django.template.loader मॉड्यूल टेम्पलेट लोड करने के लिए दो कार्यों को परिभाषित करता है।

get_template(template_name, using=None) [source]

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

रिटर्न मान का सटीक प्रकार टेम्पलेट को लोड करने वाले बैकएंड पर निर्भर करता है। प्रत्येक बैकएंड का अपना Template क्लास होता है।

get_template() क्रम में प्रत्येक टेम्पलेट इंजन की कोशिश करता है जब तक कि एक सफल न हो। यदि टेम्पलेट नहीं मिल सकता है, तो यह TemplateDoesNotExist बढ़ाता है। यदि टेम्पलेट पाया जाता है, लेकिन इसमें अवैध सिंटैक्स होता है, तो यह TemplateSyntaxError बढ़ाता है।

टेम्प्लेट कैसे खोजे और लोड किए गए हैं, यह प्रत्येक इंजन के बैकएंड और कॉन्फ़िगरेशन पर निर्भर करता है।

यदि आप किसी विशेष टेम्प्लेट इंजन में खोज को प्रतिबंधित करना चाहते हैं, तो इंजन के NAME का using तर्क में करें।

select_template(template_name_list, using=None) [source]

select_template() बस select_template() की तरह है, सिवाय इसके कि यह टेम्प्लेट नामों की सूची लेता है। यह क्रम में प्रत्येक नाम की कोशिश करता है और पहले मौजूद टेम्पलेट को वापस करता है।

यदि कोई टेम्प्लेट लोड करना विफल रहता है, तो django.template में परिभाषित निम्नलिखित दो अपवाद उठाए जा सकते हैं:

exception TemplateDoesNotExist(msg, tried=None, backend=None, chain=None) [source]

यह अपवाद तब उठाया जाता है जब कोई टेम्पलेट नहीं मिल सकता है। यह डीबग पृष्ठ पर टेम्पलेट पोस्टमॉर्टम को पॉप्युलेट करने के लिए निम्नलिखित वैकल्पिक तर्क स्वीकार करता है:

backend
टेम्पलेट बैकएंड उदाहरण है जिसमें से अपवाद उत्पन्न हुआ है।
tried
उन स्रोतों की सूची, जिन्हें टेम्प्लेट ढूंढते समय आज़माया गया था यह tuples युक्त (origin, status) की एक सूची के रूप में स्वरूपित किया गया है, जहां origin एक origin-like वस्तु है और status एक स्ट्रिंग है जिसके कारण टेम्पलेट नहीं मिला।
chain
TemplateDoesNotExist लोड करने का प्रयास करते समय उठाए गए मध्यवर्ती TemplateDoesNotExist अपवादों की एक सूची। यह get_template() जैसे फ़ंक्शंस द्वारा उपयोग किया जाता है, जो किसी दिए गए टेम्पलेट को कई इंजनों से लोड करने का प्रयास करता है।
exception TemplateSyntaxError(msg) [source]

यह अपवाद तब उठाया जाता है जब एक टेम्प्लेट पाया गया था लेकिन उसमें त्रुटियां हैं।

Template ऑब्जेक्ट get_template() और select_template() द्वारा get_template() गए निम्न हस्ताक्षर के साथ एक render() विधि प्रदान करना चाहिए:

Template.render(context=None, request=None)

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

यदि context प्रदान किया जाता है, तो यह एक dict होना चाहिए। यदि यह प्रदान नहीं किया जाता है, तो इंजन खाली संदर्भ के साथ टेम्पलेट को प्रस्तुत करेगा।

यदि request प्रदान किया गया है, तो यह एक HttpRequest होना चाहिए। फिर इंजन को इसे बनाना होगा, साथ ही सीएसआरएफ टोकन, टेम्पलेट में उपलब्ध होना चाहिए। यह कैसे प्राप्त किया जाता है यह प्रत्येक बैकएंड तक है।

यहाँ खोज एल्गोरिथ्म का एक उदाहरण है। इस उदाहरण के लिए TEMPLATES सेटिंग है:

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

यदि आप get_template('story_detail.html') कॉल get_template('story_detail.html') हैं, तो यहां फाइलें हैं जो Django के लिए, क्रम में देखेंगे:

  • /home/html/example.com/story_detail.html ( 'django' इंजन)
  • /home/html/default/story_detail.html ( 'django' इंजन)
  • /home/html/jinja2/story_detail.html ( 'jinja2' इंजन)

यदि आप select_template(['story_253_detail.html', 'story_detail.html']) कॉल select_template(['story_253_detail.html', 'story_detail.html']) , तो यहां Django क्या दिखेगा:

  • /home/html/example.com/story_253_detail.html ( 'django' इंजन)
  • /home/html/default/story_253_detail.html ( 'django' इंजन)
  • /home/html/jinja2/story_253_detail.html ( 'jinja2' इंजन)
  • /home/html/example.com/story_detail.html ( 'django' इंजन)
  • /home/html/default/story_detail.html ( 'django' इंजन)
  • /home/html/jinja2/story_detail.html ( 'jinja2' इंजन)

जब Django में मौजूद एक टेम्पलेट मिलता है, तो यह दिखना बंद हो जाता है।

टिप

आप लचीले टेम्पलेट लोड करने के लिए select_template() उपयोग कर सकते हैं। उदाहरण के लिए, यदि आपने एक समाचार कहानी लिखी है और चाहते हैं कि कुछ कहानियाँ कस्टम टेम्प्लेट हों, तो select_template(['story_%s_detail.html' % story.id, 'story_detail.html']) जैसी किसी चीज़ का उपयोग करें। यही कारण है कि आप एक कस्टम कहानी के लिए एक कस्टम टेम्पलेट का उपयोग करने की अनुमति देगा, जिसमें कस्टम टेम्पलेट नहीं है कहानियों के लिए एक फ़ॉलबैक टेम्पलेट है।

यह संभव है - और बेहतर - प्रत्येक निर्देशिका के अंदर उपनिर्देशिकाओं में टेम्पलेट्स को व्यवस्थित करने के लिए। अधिवेशन प्रत्येक Django ऐप के लिए एक उपनिर्देशिका बनाने के लिए है, आवश्यकतानुसार उपनिर्देशिकाओं के भीतर उपनिर्देशिका के साथ।

अपनी पवित्रता के लिए ऐसा करो। एकल निर्देशिका के रूट स्तर के सभी टेम्प्लेट को संग्रहीत करने से गड़बड़ हो जाती है।

एक उपनिर्देशिका के भीतर एक टेम्पलेट को लोड करने के लिए, बस एक स्लैश का उपयोग करें, जैसे:

get_template('news/story_detail.html')

ऊपर के रूप में एक ही विकल्प का उपयोग करना, यह निम्नलिखित टेम्पलेट्स लोड करने का प्रयास करेंगे:

  • /home/html/example.com/news/story_detail.html ( 'django' इंजन)
  • /home/html/default/news/story_detail.html ( 'django' इंजन)
  • /home/html/jinja2/news/story_detail.html ( 'jinja2' इंजन)

इसके अलावा, टेम्प्लेट को लोड करने और रेंडर करने की पुनरावृत्ति प्रकृति पर कटौती करने के लिए, Django एक शॉर्टकट फ़ंक्शन प्रदान करता है जो प्रक्रिया को स्वचालित करता है।

render_to_string(template_name, context=None, request=None, using=None) [source]

get_template() जैसे टेम्पलेट को लोड करता है और इसके render() विधि को तुरंत कॉल करता है। यह निम्नलिखित तर्क लेता है।

template_name
लोड करने और रेंडर करने के लिए टेम्प्लेट का नाम। यदि यह टेम्पलेट नामों की एक सूची है, तो Django टेम्पलेट खोजने के लिए select_template() बजाय get_template() का उपयोग करता है।
context
रेंडर करने के लिए टेम्प्लेट के संदर्भ के रूप में इस्तेमाल होने वाला एक dict
request
एक वैकल्पिक HttpRequest जो टेम्पलेट की रेंडरिंग प्रक्रिया के दौरान उपलब्ध होगा।
using
एक वैकल्पिक टेम्पलेट इंजन NAME । टेम्पलेट की खोज उस इंजन तक ही सीमित रहेगी।

उपयोग उदाहरण:

from django.template.loader import render_to_string
rendered = render_to_string('my_template.html', {'foo': 'bar'})

render() शॉर्टकट भी देखें जो render_to_string() कॉल करता है और परिणाम को एक दृश्य से लौटने के लिए उपयुक्त HttpResponse में फीड करता है।

अंत में, आप सीधे कॉन्फ़िगर इंजन का उपयोग कर सकते हैं:

engines

टेम्पलेट इंजन django.template.engines में उपलब्ध हैं:

from django.template import engines

django_engine = engines['django']
template = django_engine.from_string("Hello {{ name }}!")

इस उदाहरण में लुकअप कुंजी - 'django' - इंजन का NAME

अंतर्निहित बैकएंड

class DjangoTemplates [source]

एक Django टेम्पलेट इंजन को कॉन्फ़िगर करने के लिए BACKEND को 'django.template.backends.django.DjangoTemplates' पर सेट करें।

जब APP_DIRS True , तो DjangoTemplates इंजन इंस्टॉल किए गए एप्लिकेशन के templates उपनिर्देशिका में templates की तलाश करते हैं। इस जेनेरिक नाम को पश्च-संगतता के लिए रखा गया था।

DjangoTemplates इंजन निम्नलिखित DjangoTemplates स्वीकार करते हैं:

  • 'autoescape' : एक बूलियन जो यह नियंत्रित करता है कि HTML ऑटोटेसिंग सक्षम है या नहीं।

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

    चेतावनी

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

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

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

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

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

    यह DEBUG सेटिंग के मान को डिफॉल्ट करता है।

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

    डिफ़ॉल्ट DIRS और APP_DIRS के मूल्यों पर निर्भर करता है।

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

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

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

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

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

    यह FILE_CHARSET के मान को FILE_CHARSET

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

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

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

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

    OPTIONS={
        'builtins': ['myapp.builtins'],
    }
    

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

class Jinja2 [source]

Jinja2 को स्थापित करने की आवश्यकता है:

$ pip install Jinja2
...\> pip install Jinja2

Jinja2 इंजन को कॉन्फ़िगर करने के लिए 'django.template.backends.jinja2.Jinja2' पर सेट करें।

जब APP_DIRS True , तो Jinja2 इंजन इंस्टॉल किए गए एप्लिकेशन के jinja2 उपनिर्देशिका में टेम्प्लेट की jinja2

OPTIONS में सबसे महत्वपूर्ण प्रविष्टि 'environment' । यह एक बिंदीदार पायथन पथ है जो जिन्जा 2 पर्यावरण को लौटाने वाली कॉलिबल है। यह 'jinja2.Environment' लिए डिफॉल्ट करता है। Django उस कॉल करने योग्य को आमंत्रित करता है और कीवर्ड तर्क के रूप में अन्य विकल्प पास करता है। इसके अलावा, Django ने कुछ विकल्पों के लिए जिनजा 2 से अलग होने वाली चूक को जोड़ा:

  • 'autoescape' : True
  • 'loader' : DIRS और APP_DIRS लिए कॉन्फ़िगर किया गया एक लोडर
  • 'auto_reload' : settings.DEBUG
  • 'undefined' : DebugUndefined if settings.DEBUG else Undefined

Jinja2 इंजन भी निम्नलिखित Jinja2 स्वीकार करते हैं:

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

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

    जिनजा 2 टेम्पलेट्स के साथ संदर्भ प्रोसेसर का उपयोग करना हतोत्साहित किया जाता है।

    Django टेम्प्लेट के साथ संदर्भ प्रोसेसर उपयोगी होते हैं क्योंकि Django टेम्प्लेट तर्कों के साथ कॉलिंग फ़ंक्शन का समर्थन नहीं करते हैं। चूंकि Jinja2 में वह सीमा नहीं है, इसलिए यह फ़ंक्शन को नीचे दिए गए अनुसार jinja2.Environment का उपयोग करके टेम्पलेट के लिए उपलब्ध वैश्विक चर में एक संदर्भ प्रोसेसर के रूप में उपयोग करने की अनुशंसा की जाती है। फिर आप उस फ़ंक्शन को टेम्पलेट में कॉल कर सकते हैं:

    {{ function(request) }}
    

    कुछ Django टेम्प्लेट संदर्भ प्रोसेसर एक निश्चित मान लौटाते हैं। Jinja2 टेम्प्लेट के लिए, अप्रत्यक्ष की यह परत आवश्यक नहीं है क्योंकि आप सीधे jinja2.Environment में स्थिरांक जोड़ सकते हैं।

    शामिल Jinja2 के लिए संदर्भ प्रोसेसर जोड़ने के लिए मूल उपयोग मामला:

    • एक महंगी गणना करना जो अनुरोध पर निर्भर करता है।
    • हर टेम्पलेट में परिणाम की आवश्यकता है।
    • प्रत्येक टेम्पलेट में परिणाम का कई बार उपयोग करना।

    जब तक इन सभी शर्तों को पूरा नहीं किया जाता है, तब तक एक फ़ंक्शन को टेम्पलेट में पास करना सरल और अधिक है जिन्ना 2 के डिजाइन के अनुरूप।

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

उदाहरण के लिए, आप इस सामग्री के साथ myproject/jinja2.py बना सकते हैं:

from django.contrib.staticfiles.storage import staticfiles_storage
from django.urls import reverse

from jinja2 import Environment


def environment(**options):
    env = Environment(**options)
    env.globals.update({
        'static': staticfiles_storage.url,
        'url': reverse,
    })
    return env

और 'environment' विकल्प को 'myproject.jinja2.environment' सेट करें।

फिर आप जिनजा 2 टेम्प्लेट में निम्नलिखित निर्माणों का उपयोग कर सकते हैं:

<img src="{{ static('path/to/company-logo.png') }}" alt="Company Logo">

<a href="{{ url('admin:index') }}">Administration</a>

टैग और फ़िल्टर की अवधारणाएं Django टेम्पलेट भाषा और Jinja2 दोनों में मौजूद हैं, लेकिन उनका उपयोग अलग-अलग तरीके से किया जाता है। चूँकि Jinja2 टेम्प्लेट में callables के लिए तर्कों को पारित करने का समर्थन करता है, कई विशेषताएँ जिन्हें Django टेम्प्लेट में टेम्प्लेट टैग या फ़िल्टर की आवश्यकता होती है, उन्हें केवल जिन्जा 2 टेम्प्लेट में एक फ़ंक्शन को कॉल करके प्राप्त किया जा सकता है, जैसा कि ऊपर दिए गए उदाहरण में दिखाया गया है। जिनजा 2 का वैश्विक नाम स्थान टेम्पलेट संदर्भ प्रोसेसर की आवश्यकता को हटा देता है। Django टेम्पलेट भाषा में Jinja2 परीक्षणों के बराबर नहीं है।

कस्टम बैकएंड

किसी अन्य टेम्पलेट सिस्टम का उपयोग करने के लिए कस्टम टेम्प्लेट बैकएंड को लागू करने का तरीका यहां बताया गया है। एक टेम्पलेट बैकएंड एक वर्ग है जो django.template.backends.base.BaseEngine इनहेरिट django.template.backends.base.BaseEngine । इसे get_template() और वैकल्पिक रूप से from_string() लागू करना होगा। यहाँ एक काल्पनिक foobar टेम्पलेट लाइब्रेरी के लिए एक उदाहरण दिया गया है:

from django.template import TemplateDoesNotExist, TemplateSyntaxError
from django.template.backends.base import BaseEngine
from django.template.backends.utils import csrf_input_lazy, csrf_token_lazy

import foobar


class FooBar(BaseEngine):

    # Name of the subdirectory containing the templates for this engine
    # inside an installed application.
    app_dirname = 'foobar'

    def __init__(self, params):
        params = params.copy()
        options = params.pop('OPTIONS').copy()
        super().__init__(params)

        self.engine = foobar.Engine(**options)

    def from_string(self, template_code):
        try:
          return Template(self.engine.from_string(template_code))
        except foobar.TemplateCompilationFailed as exc:
            raise TemplateSyntaxError(exc.args)

    def get_template(self, template_name):
        try:
            return Template(self.engine.get_template(template_name))
        except foobar.TemplateNotFound as exc:
            raise TemplateDoesNotExist(exc.args, backend=self)
        except foobar.TemplateCompilationFailed as exc:
            raise TemplateSyntaxError(exc.args)


class Template:

    def __init__(self, template):
        self.template = template

    def render(self, context=None, request=None):
        if context is None:
            context = {}
        if request is not None:
            context['request'] = request
            context['csrf_input'] = csrf_input_lazy(request)
            context['csrf_token'] = csrf_token_lazy(request)
        return self.template.render(context)

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

कस्टम इंजन के लिए डिबग एकीकरण

Django डीबग पृष्ठ में टेम्पलेट त्रुटि होने पर विस्तृत जानकारी प्रदान करने के लिए हुक होते हैं। कस्टम टेम्पलेट इंजन उपयोगकर्ताओं को दिखाई देने वाली ट्रेसबैक जानकारी को बढ़ाने के लिए इन हुक का उपयोग कर सकते हैं। निम्नलिखित हुक उपलब्ध हैं:

खाका पोस्टमॉर्टम

जब PostDoesNotExist उठाया जाता है तो पोस्टमॉर्टम दिखाई देता है। यह उन टेम्प्लेट इंजन और लोडर को सूचीबद्ध करता है जो किसी दिए गए टेम्पलेट को खोजने की कोशिश करते समय उपयोग किए गए थे। उदाहरण के लिए, यदि दो Django इंजन कॉन्फ़िगर किए गए हैं, तो पोस्टमॉर्टम इस तरह दिखाई देगा:

../_images/postmortem.png

कस्टम इंजन TemplateDoesNotExist बढ़ाते समय backend और tried तर्कों को पोस्टमॉर्टम को पॉप्युलेट कर सकते हैं। पोस्टमॉर्टम का उपयोग करने वाले बैकएंड्स को टेम्प्लेट ऑब्जेक्ट पर origin-like

प्रासंगिक रेखा की जानकारी

यदि टेम्पलेट पार्सिंग या रेंडरिंग के दौरान कोई त्रुटि होती है, तो Django उस लाइन को प्रदर्शित कर सकता है जिस पर त्रुटि हुई थी। उदाहरण के लिए:

../_images/template-lines.png

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

  • 'name' : उस टेम्पलेट का नाम जिसमें अपवाद हुआ।
  • 'message' : अपवाद संदेश।
  • 'source_lines' : पहले और बाद की पंक्तियों सहित लाइनें अपवाद थीं। यह संदर्भ के लिए है, इसलिए इसमें 20 से अधिक लाइनें या ऐसा नहीं होना चाहिए।
  • 'line' : वह पंक्ति संख्या जिस पर अपवाद हुआ।
  • 'before' : त्रुटि से पहले त्रुटि पंक्ति पर सामग्री जिसने त्रुटि को उठाया।
  • 'during' : टोकन जिसने त्रुटि को उठाया।
  • 'after' : त्रुटि के बाद त्रुटि पंक्ति पर सामग्री जिसने त्रुटि को उठाया।
  • 'total' : source_lines में लाइनों की संख्या।
  • 'top' : वह पंक्ति संख्या जहाँ source_lines प्रारंभ होती है।
  • 'bottom' : वह पंक्ति संख्या जहाँ source_lines समाप्त होती है।

उपरोक्त टेम्पलेट त्रुटि को देखते हुए, template_debug ऐसा लगेगा:

{
    'name': '/path/to/template.html',
    'message': "Invalid block tag: 'syntax'",
    'source_lines': [
        (1, 'some\n'),
        (2, 'lines\n'),
        (3, 'before\n'),
        (4, 'Hello {% syntax error %} {{ world }}\n'),
        (5, 'some\n'),
        (6, 'lines\n'),
        (7, 'after\n'),
        (8, ''),
    ],
    'line': 4,
    'before': 'Hello ',
    'during': '{% syntax error %}',
    'after': ' {{ world }}\n',
    'total': 9,
    'bottom': 9,
    'top': 1,
}

उत्पत्ति एपीआई और 3-पार्टी एकीकरण

Django टेम्प्लेट में एक Origin ऑब्जेक्ट है जो template.origin माध्यम से उपलब्ध है। यह डिबग जानकारी को टेम्पलेट पोस्टमॉर्टम में प्रदर्शित करने में सक्षम बनाता है, साथ ही 3-पार्टी लाइब्रेरी में, Django डीबग टूलबार की तरह

कस्टम इंजन निम्नलिखित विशेषताओं को निर्दिष्ट करने वाली एक वस्तु बनाकर अपना स्वयं का template.origin प्रदान कर सकते हैं।

  • 'name' : टेम्पलेट का पूर्ण पथ।
  • 'template_name' : टेम्प्लेट लोडिंग विधियों में दिए गए अनुसार टेम्प्लेट के सापेक्ष पथ।
  • 'loader_name' : टेम्पलेट लोड करने के लिए उपयोग किए जाने वाले फ़ंक्शन या वर्ग की पहचान करने वाला एक वैकल्पिक स्ट्रिंग, जैसे django.template.loaders.filesystem.Loader

Django टेम्पलेट भाषा

वाक्य - विन्यास

इस खंड के बारे में

यह Django टेम्पलेट भाषा के सिंटैक्स का अवलोकन है। विवरण के लिए भाषा सिंटैक्स संदर्भ देखें

Django टेम्प्लेट भाषा का उपयोग करके एक Django टेम्प्लेट केवल एक पाठ दस्तावेज़ या पायथन स्ट्रिंग चिह्नित है। कुछ निर्माण टेम्पलेट इंजन द्वारा पहचाने और व्याख्या किए जाते हैं। मुख्य चर और टैग हैं।

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

Django टेम्पलेट भाषा के सिंटैक्स में चार निर्माण शामिल हैं।

चर

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

चर इस तरह से {{ और }} घिरे हैं:

My first name is {{ first_name }}. My last name is {{ last_name }}.

{'first_name': 'John', 'last_name': 'Doe'} संदर्भ के साथ, यह टेम्प्लेट इसमें शामिल है:

My first name is John. My last name is Doe.

डिक्शनरी लुकअप, फीचर लुकअप और लिस्ट-इंडेक्स लुक्स को डॉट नोटेशन के साथ लागू किया जाता है:

{{ my_dict.key }}
{{ my_object.attribute }}
{{ my_list.0 }}

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

टैग

टैग रेंडरिंग प्रक्रिया में मनमाना तर्क प्रदान करते हैं।

यह परिभाषा जानबूझकर अस्पष्ट है। उदाहरण के लिए, एक टैग सामग्री का उत्पादन कर सकता है, एक नियंत्रण संरचना के रूप में काम करता है जैसे "अगर" कथन या "के लिए" लूप, डेटाबेस से सामग्री को पकड़ो, या यहां तक ​​कि अन्य टेम्पलेट टैग तक पहुंच को सक्षम करें।

टैग इस तरह {% और %} घिरे हैं:

{% csrf_token %}

अधिकांश टैग तर्क स्वीकार करते हैं:

{% cycle 'odd' 'even' %}

कुछ टैगों को शुरुआत और समाप्ति टैग की आवश्यकता होती है:

{% if user.is_authenticated %}Hello, {{ user.username }}.{% endif %}

अंतर्निर्मित टैग का संदर्भ उपलब्ध है और साथ ही कस्टम टैग लिखने के निर्देश भी

फिल्टर

फिल्टर चर और टैग तर्क के मूल्यों को बदल देते हैं।

वे इस तरह दिखते हैं:

{{ django|title }}

{'django': 'the web framework for perfectionists with deadlines'} संदर्भ में {'django': 'the web framework for perfectionists with deadlines'} , यह टेम्प्लेट प्रस्तुत करता है:

The Web Framework For Perfectionists With Deadlines

कुछ फ़िल्टर एक तर्क लेते हैं:

{{ my_date|date:"Y-m-d" }}

अंतर्निर्मित फ़िल्टर का संदर्भ उपलब्ध है और साथ ही कस्टम फ़िल्टर लिखने के लिए निर्देश भी

टिप्पणियाँ

टिप्पणियाँ इस तरह दिखती हैं:

{# this won't be rendered #}

एक {% comment %} टैग बहु-पंक्ति टिप्पणियाँ प्रदान करता है।

अवयव

इस खंड के बारे में

यह Django टेम्पलेट भाषा के एपीआई का अवलोकन है। विवरण के लिए एपीआई संदर्भ देखें।

इंजन

django.template.Engine Django टेम्प्लेट सिस्टम का एक उदाहरण django.template.Engine करता है। एक django.template.Engine तुरंत चालू करने का मुख्य कारण Django परियोजना के बाहर Django टेम्पलेट भाषा का उपयोग करना है।

django.template.backends.django.DjangoTemplates एक पतली रैपर है जो django.template.Engine को Django के टेम्पलेट बैकएंड एपीआई के अनुकूल django.template.Engine है।

खाका

django.template.Template एक संकलित टेम्पलेट का प्रतिनिधित्व करता है। टेम्पलेट Engine.get_template() या Engine.from_string() साथ प्राप्त किए जाते हैं

इसी तरह django.template.backends.django.Template एक पतला रैपर है जो आम टेम्पलेट एपीआई के लिए django.template.Template को एडाप्ट django.template.Template है।

प्रसंग

django.template.Context संदर्भ डेटा के अतिरिक्त कुछ मेटाडेटा रखती है। इसे Template.render() रेंडर करने के लिए Template.render() में पास किया जाता है।

RequestContext django.template.Context का एक उपवर्ग है जो वर्तमान HttpRequest संग्रहीत करता है और टेम्पलेट संदर्भ प्रोसेसर चलाता है।

सामान्य API में समतुल्य अवधारणा नहीं होती है। प्रसंग डेटा को एक सादे HttpRequest में पारित किया जाता है और वर्तमान HttpRequest को अलग से पारित किया जाता है यदि आवश्यक हो।

लोडर

टेम्प्लेट लोडर टेम्प्लेट का पता लगाने, उन्हें लोड करने और django.template.Template ऑब्जेक्ट्स वापस करने के लिए जिम्मेदार हैं।

Django कई अंतर्निहित टेम्पलेट लोडर प्रदान करता है और कस्टम टेम्पलेट लोडर का समर्थन करता है।

प्रसंग प्रसंगकारक

प्रसंग प्रोसेसर वे फ़ंक्शन होते हैं जो वर्तमान HttpRequest को एक तर्क के रूप में प्राप्त करते हैं और रेंडरिंग संदर्भ में जोड़े जाने वाले डेटा का एक dict वापस करते हैं।

उनका मुख्य उपयोग सभी टेम्प्लेट द्वारा साझा किए गए सामान्य डेटा को संदर्भ में हर दृश्य में कोड को दोहराए बिना जोड़ना है।

Django कई अंतर्निहित संदर्भ प्रोसेसर प्रदान करता है। एक कस्टम संदर्भ प्रोसेसर को लागू करना एक फ़ंक्शन को परिभाषित करने के रूप में सरल है।