🍟 🦒 🐽 एक बार फिर से टेम्पलेट्स के बारे में 😷 ⬛️ 👨🏽‍🚀

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

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

दरअसल, उसी स्मार्टी को एक ऐसी साइट में एकीकृत करना जो कार्यक्षमता में बहुत सरल है, डेवलपर बस समय बिताता है। और समय, जैसा कि आप जानते हैं, पैसा है। और ज्यादातर मामलों में, ग्राहक को इस बात की परवाह नहीं है कि उनकी साइट किस टेम्पलेट इंजन पर काम करेगी। ग्राहक बिताए समय के बारे में अधिक चिंतित है।

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

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

लेकिन दृश्य और अमूर्त के बीच की खाई को वापस। एक औसत परियोजना में एक टेम्पलेट इंजन को पूरा करने के लिए न्यूनतम आवश्यकताएं क्या हैं?

एक टेम्प्लेट में चर निर्दिष्ट करने की क्षमता
एक एकल HTML टेम्पलेट के लिए अलग चर नाम स्थान
प्रपत्र के दोहराए जाने वाले निर्माण से बचने के लिए पृष्ठ के सामान्य फ्रेम के लिए एक टेम्पलेट का उपयोग करने की क्षमता के लिए 'शीर्ष लेख' की आवश्यकता होती है; ... 'पाद लेख' की आवश्यकता होती है; प्रत्येक फ़ाइल में

वैसे, "औसत" परियोजना मेरे व्यक्तिगत पैमाने पर वेब एप्लिकेशन की जटिलता को मापने का एक निश्चित मानक है और निम्नलिखित मानदंडों को पूरा करती है:

एक परियोजना एक ऑनलाइन स्टोर या सामाजिक समुदाय है।
10-20 प्रकार के पृष्ठ। मैं जोर देता हूं - पृष्ठ नहीं, लेकिन पृष्ठ प्रकार। उदाहरण के लिए: उत्पाद विवरण पृष्ठ। यानी इस प्रकार के पेज के लिए एक html टेम्प्लेट होगा, लेकिन डायरेक्टरी कंटेंट से भरे होने पर खुद कई पेज होंगे

प्रत्येक डेवलपर का अपना पैमाना होता है, इसलिए कृपया इस मामले में कड़ाई से निर्णय न लें।

शब्दों से कर्मों की ओर बढ़ते हैं।

सबसे सरल वर्ग पर विचार करें, जिसमें केवल तीन विधियां शामिल हैं।

<?php class Template { private $_tmpl; private $_vars = array(); public function __construct($filename) { $this->_tmpl = $filename; } public function assign($name, $value) { $this->_vars[$name] = $value; } public function render() { if (count($this->_vars) > 0) { extract($this->_vars); } $tmplPath = "../templates/{$this->_tmpl}.tpl"; if (file_exists($tmplPath)) { require $tmplPath; } else { throw new Exception(" <strong>{$this->_tmpl}</strong>  "); } } }

 <!--    --> <!DOCTYPE html> <html> <head> <title></title> </head> <body> <?php echo $content ?> </body> </html>

Catalog.tpl

 <!--     --> <p> №<?php echo $ID ?></p>

Product.tpl

 <!--     --> <p>   №<?php echo $ID ?></p>

Index.tpl

 <!--    --> <p>   </p>

404.tpl

 <!--    404-  --> <p>  !</p>

index.php

 /** *  . * ,    echo-  print-,    ,     . */ ob_start(); //   require dirname(__FILE__).'/classes/Template.php'; //        //       ,        404.tpl //    ,    if (isset($_GET['route']) && $_GET['route'] == 'catalog') { $tmpl = new Template('Catalog'); $tmpl->assign('ID', $_GET['ID']); $tmpl->render(); } else if ($_GET['route']) && $_GET['route'] == 'product') { $tmpl = new Template('Catalog'); $tmpl->assign('ID', $_GET['ID']); $tmpl->render(); } else if (!isset($_GET['route'])) { $tmpl = new Template('Index'); $tmpl->render(); } else { header("HTTP/1.0 404 Not Found"); $tmpl = new Template('404'); $tmpl->render(); } //    $content = ob_get_clean(); //          $tmpl = new Template('Main'); $tmpl->assign('content', $content); $tmpl->render();

जैसा कि आप उदाहरण से देख सकते हैं, कैटलॉग और उत्पाद पृष्ठों की सामग्री $ _GET ['आईडी'] के मूल्य के आधार पर बदल जाती है। इस प्रकार हमें दो प्रकार के टेम्प्लेट मिले और इन टेम्प्लेट से एप्लिकेशन द्वारा उत्पन्न पृष्ठों की एक असीमित संख्या।

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

आपका ध्यान देने के लिए धन्यवाद।

एक बार फिर से टेम्पलेट्स के बारे में

More articles: