टेम्पलेट सिंटैक्स मानक

क्या आपने शुरुआती सवालों को सुनना बंद कर दिया है: "कौन सा टेम्पलेट चुनना है?"। मुझे ऐसा नहीं लगता।

एक ही बात जो निश्चितता के साथ कही जा सकती है वह यह है कि समय-समय पर कुछ निर्णय कुछ हलकों में लोकप्रिय हो जाते हैं, लेकिन वे अपने दायरे की सबसे अधिक सीमा के लिए होते हैं, यह एक प्रोग्रामिंग भाषा है। किसी भी मानकों के अस्तित्व के लाभों को सूचीबद्ध करना आवश्यक नहीं है। हर कोई समझता है, "इससे सब कुछ अच्छा होगा।" आविष्कार करना, ठीक करना, उन्हें लागू करना - यह एक ऐसा कार्य है जो तुच्छ से दूर है, लेकिन इसे हल किया जा सकता है।



चलिए इस ओर बढ़ना शुरू करते हैं।



एकल टेम्प्लेट सिंटैक्स प्रस्तुत करने का विचार नया नहीं है। जैसा कि आप मौजूदा टेम्पलेट इंजनों की विविधता से देख सकते हैं, सिंटैक्स प्रोग्रामिंग भाषा पर निर्भर है।

हम यह निष्कर्ष निकाल सकते हैं कि किसी ऐसी चीज के लिए काम करना आवश्यक है जो सभी के लिए उपयुक्त हो। हम स्पष्ट रूप से समझते हैं कि भारी सिंटैक्स रूट (हैलो, xslt) नहीं लेते हैं। लेकिन अतिसूक्ष्मवाद की अभिव्यक्ति अच्छी नहीं है। आप तब जा सकते हैं जब हमारे पास ऑपरेटरों के लिए रिकॉर्डिंग का एक छोटा और पूर्ण रूप है, और यह धारणा बनाएं कि लेखन का पूर्ण रूप सभी के लिए काम करता है, पार्सर्स के संकरे सर्कल के लिए एक छोटा। यही है, हम एक संक्षिप्त वाक्यविन्यास के रूप में एक रोटी प्राप्त करना चाहते हैं, लेकिन हम "xxx" भाषा में टेम्पलेट्स के लिए प्रत्यक्ष समर्थन के इनकार के रूप में एक सिक्का देने के लिए तैयार हैं। इसके अलावा, भाषाओं के इस चक्र के लिए, इस तरह के पैटर्न में बाधा नहीं होनी चाहिए। ठीक है, यदि आप टेम्प्लेट्स को YP "xxx" में स्थानांतरित करना चाहते हैं, तो हमें जल्दी से सभी टेम्प्लेटों के माध्यम से जाने और शॉर्ट सिंटैक्स को पूर्ण के साथ बदलने में सक्षम होना चाहिए।



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



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



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



अविश्वसनीय रूप से कई स्थितियां।



अभ्यास से पता चलता है कि सार्वभौमिक समाधान अक्सर अत्यधिक विशिष्ट लोगों से हार जाते हैं। हाँ यह है यह केवल इस बात का पता लगाना है कि यह नुकसान हमारे मामले में कितना होगा? मानक विकसित करने के परिणामस्वरूप, मैं प्रत्येक पीएल के लिए कार्यान्वयन उदाहरण प्राप्त करना चाहता हूं। इसलिए मुझे नहीं लगता कि सब कुछ दुखी होगा।



यहाँ विभिन्न टेम्पलेट इंजनों में ऑपरेटर / टैग कार्यान्वयन के कुछ उदाहरण दिए गए हैं:

Django:

{% if today_is_weekend %}

< p > Welcome to the weekend! </ p >

{% else %}

< p > Get back to work. </ p >

{% endif %}



{% for athlete in athlete_list %}

< li > {{ athlete.name }} </ li >

{% endfor %}



XSLT:

< xsl:choose >

< xsl:when test ="/some/node = 1" >

One

</ xsl:when >

< xsl:otherwise >

More.

</ xsl:otherwise >

</ xsl:choose >



< xsl:for-each select ="/nodes/*" >

Name: {./name}

</ xsl:for-each >



HTML::Template:

< TMPL_IF BOOL >

Some text that is included only if BOOL is true

< TMPL_ELSE >

Some text that is included only if BOOL is false

</ TMPL_IF >



< TMPL_LOOP NAME = EMPLOYEE_INFO >

Name: < TMPL_VAR NAME = NAME > < br >

Job: < TMPL_VAR NAME = JOB > < p >

</ TMPL_LOOP >



Smarty

{if $name eq 'Fred'}

Welcome Sir.

{else}

Welcome, whatever you are.

{/if}



{foreach key=key item=item from=$contact}

{$key}: {$item} < br >

{$key}: {$item} < br />

{/foreach}



EJS — Embedded Javascript

<% if (question) { %>

< h2 > <% = author %> : <% = question %> </ h2 >

<% } else { %>

< h2 > , ! </ h2 >

<% } %>



<% for ( var i=0; i<supplies.length; i++) { %>

< li > <% = supplies[i] %> </ li >

<% } %>



* This source code was highlighted with Source Code Highlighter .

मंत्रमुग्ध, यह नहीं है? बेशक, कुछ टेम्प्लेट का उपयोग करने वाले लोग पहले से ही अपनी सुविधाओं के लिए उपयोग किए जाते हैं, और वे वास्तव में जीवन में कुछ बदलने की वांछनीयता नहीं देखते हैं। मैं किसी को भी राजी करने के लिए कुछ भी साबित नहीं करना चाहता। मैंने यह नहीं कहा कि जैसे सब कुछ लेने और करने के लिए पर्याप्त फ़्यूज़ है। मैं उन लोगों को ढूंढना चाहता हूं जो रुचि रखते हैं। जब काम लोगों के समूह में जाएगा - यह प्रतिभागियों को अच्छी तरह से प्रेरित करेगा।



हम कह सकते हैं कि यह एक अंतहीन प्रक्रिया होगी, या बकवास करना किसी के काम की ज़रूरत नहीं है। मुझे लगता है कि ऐसा नहीं है। सबसे पहले, एक व्यक्ति जो एक या दो साल के मामले में बहुत कम जानता है वह अपने फैसले को लागू कर सकता है, जो उसकी अधिकांश आवश्यकताओं को पूरा करेगा। दूसरे, जबकि स्वयं-लिखित टेम्पलेट इंजन की संख्या वेब प्रोग्रामिंग में मास्टर करने वाले लोगों की संख्या के अनुपात में बढ़ रही है, स्थिति सामान्य रूप से नहीं होती है।



कोई कहेगा कि उपलब्ध साधनों का उपयोग करके किसी भी समस्या को हल करना आज अधिक व्यावहारिक है। यह कहने के लिए नहीं कि मुझे सब कुछ पसंद नहीं है। नहीं, काफी योग्य उदाहरण हैं, लेकिन यह नियमों के एक सेट की अनुपस्थिति की समस्या को रद्द नहीं करता है। आज, आपके टेम्प्लेट इंजन के डेवलपर्स कहेंगे: "लेकिन क्या हम मौलिक रूप से दृष्टिकोण बदल सकते हैं?", वे पुराने शिल्पों के साथ असंगत कुछ के साथ आएंगे। हम सभी मनुष्य हैं, जल्दी या बाद में "रिटायर" हो जाते हैं, और हमारे व्यवसाय को जारी रखने के लिए हमेशा किसी के पास नहीं है। यहां मैं शायद बहुत ज्यादा झूल गया, क्योंकि इंटरनेट पर रुझान तेजी से बदल रहे हैं, जैसे हम बड़े हो रहे हैं, लेकिन यह उपरोक्त को रद्द नहीं करता है।



हाँ, बड़े और अभी भी यह सब पानी पर एक छड़ी है । इस कार्य पर टीम के काम को व्यवस्थित करने के लिए कोई संरचना नहीं है, लेकिन यह सभी लाभ का विषय है।



मुख्य बात के बारे में संक्षेप में:

विषय में रुचि रखने वाले, चर्चा करने में सक्षम और फिर विभिन्न प्रोग्रामिंग भाषाओं में कुछ प्रोसेसिंग एल्गोरिदम को लागू करने में सक्षम बनाने के लिए।



क्या कोई इच्छा है?



PS यह कहना अनावश्यक है कि कुछ भी काम नहीं करेगा, अनावश्यक रूप से अनुचित आलोचना, इसमें कुछ भी नहीं है, नर्वस न हों।