टेम्पलेट्स से स्थिर संसाधनों को जोड़ना

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

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

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

पहला उदाहरण

एक बड़ी परियोजना ( Zend फ्रेमवर्क पर आधारित) पर, स्थिर फाइलें लगभग निम्नलिखित तरीके से जुड़ी हुई थीं:

// someWidget.tpl // PROJECT_STATIC_VERSION —      (  ) ViewHelpers.appendStylesheet("css/some-path/sub-path/some-widget.css?" + PROJECT_STATIC_VERSION); ViewHelpers.appendJsFile ("js/some-path/sub-path/some-widget.js?" + PROJECT_STATIC_VERSION); //    Layout: <div class="some-widget"> <!-- a lot of cool html --> </div> 

हम मानेंगे कि तरीके ViewHelpers.appendStylesheet और ViewHelpers.appendJsFile हमें अंतिम पृष्ठ पर संबंधित टैग में उन्हें हस्तांतरित फ़ाइलों के कनेक्शन की गारंटी देते हैं। PROJECT_STATIC_VERSION लाइन का उपयोग url में एक कुंजी जोड़ने के लिए किया गया था , जो अपडेट करता है कि ब्राउज़र को इस फ़ाइल का एक नया संस्करण डाउनलोड करने के लिए मजबूर करेगा।
इसके अलावा, फाइलें अक्सर बाहर के टेम्पलेट्स से जुड़ी होती थीं, उदाहरण के लिए, नियंत्रक कोड में या तत्व डेकोरेटर कोड ( Zend_Form_Decorator ) में। विशेष रूप से अक्सर एक्स्टेज जेएस फ्रेमवर्क फ़ाइलों का कनेक्शन था यदि जेएस कोड एक्स्टजेएस पर निर्भर टेम्पलेट से शामिल था। दुर्भाग्य से, 95% मामलों में यह फॉर्म के कॉपी-पेस्ट द्वारा किया गया था:

 ViewHelpers.appendJsFile("js/libs/ext-js/ext-js.js?" + PROJECT_STATIC_VERSION); ViewHelpers.appendCss ("css/libs/ext-js/ext-js.css?" + PROJECT_STATIC_VERSION); ViewHelpers.appendJsFile("js/libs/ext-js/locale-ru.js?" + PROJECT_STATIC_VERSION); 

तो, इस दृष्टिकोण के नुकसान (सबसे अधिक, निश्चित रूप से):

• बैकएंड कोड और टेम्पलेट कोड फ्रंटएंड कोड की संरचना के बारे में जानते हैं। फ्रंटेंड कोड को बदलना (जोड़ना, हिलाना, विलय करना, विभाजित करना) बैकएंड कोड को बदलना आवश्यक बना देगा। यदि कुछ फाइलें काफी संख्या में टेम्प्लेट से जुड़ी होती हैं (और अक्सर वे होती हैं) तो एक लंबी और दर्दनाक प्रक्रिया क्या हो सकती है। यानी सीमावर्ती डेवलपर अनिवार्य रूप से बैकएंड साथी पर निर्भर करता है। बर्फ क्या नहीं है! (उपरोक्त उदाहरण में, यह बचाया गया कि परियोजना पर फ्रंटेंड / बैकएंड डेवलपर्स का कोई पृथक्करण नहीं था, इसलिए इस या उस घटक को लागू करने वाले व्यक्ति ने बैकएंड और फ्रंटेंड कोड दोनों को लिखा था।)
• स्थैतिक संसाधनों को जोड़ने के लिए कोई एकल बिंदु नहीं है। क्योंकि फ़ाइलों को विभिन्न स्थानों से जोड़ा जा सकता है: नियंत्रक कोड, तत्व डेकोरेटर कोड, व्यू-हेल्पर कोड और स्वयं टेम्पलेट कोड, यह केवल यह निर्धारित करना संभव नहीं है कि किसी विशेष घटक फ़ाइलों की आवश्यकता क्या है।
• स्पष्ट निर्भरता का अभाव। चूंकि फाइलों की सूची बस जुड़ी हुई थी, इसलिए उनके बीच के रिश्ते की पहचान करना असंभव था। उदाहरण के लिए, किसी और के आधार पर एक नया घटक बनाने वाला एक डेवलपर संसाधन कनेक्शन के हिस्से की नकल कर सकता है (उसकी राय में, किसी तरह के अलग-थलग भाग के लिए जिम्मेदार), और फिर पहेली कि जावास्क्रिप्ट क्यों काम नहीं करता है। लेकिन तथ्य यह है कि वह फ़ाइल /lib/some-cool-plugin.js को शामिल करना भूल गया
• टेम्प्लेट में तर्क को जोड़ना। मैं इसे सबसे गलत कदम मानता हूं। (निम्नलिखित उदाहरण में, यह और भी दुखद होगा!)। संसाधन url के लिए स्थिर संस्करण का संयोजन इस या उस वातावरण के लिए परिनियोजन तकनीकों में से एक है, और इसका टेम्पलेट और फ्रंटेंड कोड के तर्क से कोई लेना-देना नहीं है। साथ ही, यह गलती करने का एक और मौका है, इस कुंजी को जोड़ना भूल जाओ (बहुत आलसी!) या इस कुंजी को बदलने के लिए भूल (यह अक्सर हुआ)।
• दोहराव। दोनों सीधे कनेक्शन कोड ( ViewHelpers.blaBlaBla () ), और अलग-अलग टेम्पलेट्स में एक ही फाइल करते हैं। सामान्य तौर पर, डीआरवाई ।
• शब्दार्थ का अभाव। सिर्फ संसाधनों की उपरोक्त सूची बहुत कम कहती है। हम निर्भरता को अलग नहीं कर सकते, इन संसाधनों की प्रकृति का निर्धारण करें, समझें कि यह कोड अभी भी कहां उपयोग किया जाता है, आदि।
• एक सामान्य टाइपो अवसर। लंबे फ़ाइल पथ और नाम अक्सर टाइपोस के लिए प्रवण होते हैं। वह अक्सर यह निर्धारित करने के लिए बासी सिर पर अतिरिक्त समय बिताता था कि निर्दिष्ट फ़ाइल कनेक्ट नहीं हुई (404 नहीं मिली)। बेशक, आप कोड लिख सकते हैं जो कुछ फ़ाइलों की उपस्थिति के लिए जांच करता है, लेकिन यह हमेशा संभव नहीं था, क्योंकि अक्सर नंगेक्स के साथ मिश्रित रूटिंग 'ए। वैसे भी कोई ऐसा नहीं कर रहा था।

सिम्फनी प्रोजेक्ट से दूसरा उदाहरण

 // SomeConroller.SomeAction If (Config.Env == "Production") { includeCss("styles/feature.min.css"); includeJs("js/feature.min.js"); } Else If(Config.Env == "Dev") { includeCss("styles/feature/global.css"); includeCss("styles/feature/sub-feature.css"); includeJs("js/classes/Core.js"); includeJs("js/classes/Event.js"); includeJs("js/classes/CoolPlugin.js"); includeJs("js/classes/Feature.js"); includeJs("js/classes/FeatureSubFeature.js"); } Layout: <div class="feature"> <!-- feature's code is here --> </div> 

प्लस, प्रोजेक्ट स्तर पर, प्रपत्र के js और css कोड को मर्ज और छोटा करने के लिए आवश्यक फ़ाइलों का वर्णन करने के लिए एक कॉन्फ़िगरेशन था:

 styles/feature.min.css: styles/feature/main.css styles/feature/sub-feature.css js/feature.min.js: js/classes/Core.js js/classes/Event.js js/classes/CoolPlugin.js js/classes/Feature.js js/classes/FeatureSubFeature.js 

इस उदाहरण में पिछले एक के सभी नुकसान हैं, केवल अधिक भयानक रूप में:

• टेम्पलेट में परिनियोजन तर्क। और इसलिए अब फ्रंटएंड प्रोग्रामर पूरी तरह से सभी के बारे में जानता है (2 के रूप में कई!) जिस पर एप्लिकेशन को तैनात किया जा सकता है। साथ ही, यह फ़ाइलों को मर्ज करने और उन्हें छोटा करने के लिए कॉन्फिगरेशन को बनाए रखने की जिम्मेदारी जोड़ता है, जिसे केवल उत्पादन परिवेश पर परीक्षण किया जा सकता है। यह कल्पना करना डरावना है कि अगर एक नया वातावरण जोड़ा जाता है तो क्या होगा, जैसे कि चरण या परीक्षण। वास्तव में, कोई स्टैटिक्स कनेक्ट नहीं होगा ( अगर-और-अगर )। मैं इसे स्थैतिक संसाधनों को जोड़ने का सबसे बुरा सपना मानता हूं।
• नकल का एक गुच्छा। फ्रंट-एंड कोड की संरचना को बदलना दुःस्वप्न में बदल जाता है। विभिन्न वातावरणों के तहत सभी स्थानों को शामिल करने के लिए कॉन्फ़िगरेशन को बदलना आवश्यक है।
• कोई निर्भरता नहीं। उन क्षणों में जब कुछ घटकों ने सामान्य कोड का उपयोग करना शुरू किया, मुझे शर्मसार होना पड़ा। सभी छोटे संस्करणों को दो भागों में विभाजित किया गया था (देव के लिए सूची केवल नहीं बदली गई थी), कॉन्फ़िगरेशन लंबे समय तक और सबसे खराब हो रहा था, अब यह जांचने के लिए कि हमने सभी संस्करणों को सही ढंग से मिनी संस्करण में जोड़ा है, मुझे अपने दिमाग में दो खंडों से सूचियों को जोड़ना था।
  उसी समय, त्रुटियां उन स्थानों से भी दिखाई दीं जहां गैर-कुचल हिस्सा अभी भी इस्तेमाल किया गया था, और कुछ कोड ने विभिन्न स्थानों में दो बार काम किया। सादगी के लिए, एक उदाहरण की कल्पना करें: ब्लॉक ए का उपयोग 1.js और 2.js. ब्लॉक बी 2.js और 3.js फ़ाइलों का उपयोग करता है। हम अब इन दोनों ब्लॉकों को नहीं जोड़ सकते, क्योंकि 2.जज फ़ाइल को 2 बार संसाधित किया जाएगा।

कार्य

परिणामस्वरूप, इन और अन्य दृष्टिकोणों की कमियों का विश्लेषण करने के बाद, मैंने स्थिर संसाधनों को जोड़ने के लिए एक प्रणाली के लिए कई आवश्यकताओं को इकट्ठा किया:

• संसाधनों को जोड़ने के लिए एक जगह
• संरचना की स्वतंत्रता और फ्रंट-एंड कोड के संशोधन में आसानी
• टेम्प्लेट में कोई तर्क नहीं
• आसान निर्भरता प्रबंधन, डुप्लिकेट न्यूनतम
• टाइपोस के मामले में स्पष्ट त्रुटि संदेश
• शब्दार्थ की उपस्थिति

निर्णय

• संसाधनों को जोड़ने के लिए एक एकल स्थान। प्रोजेक्ट में उस स्थान को सख्ती से निर्धारित करना आवश्यक है जहां आप स्थैतिक संसाधनों को जोड़ सकते हैं। मुझे लगता है कि केवल सभ्य जगह टेम्पलेट है। क्यों? एक नियम के रूप में, एक या अन्य मार्कअप ब्लॉक संबंधित शैलियों और जावा स्क्रिप्ट के साथ जुड़ा हुआ है। एक ही टेम्पलेट में इस कनेक्शन को परिभाषित करना तर्कसंगत होगा। अंत में, मैं टेम्पलेट कोड के बाहर फ़ाइलों के कनेक्शन पर प्रतिबंध लगाने का प्रस्ताव करता हूं।
• शब्दार्थ की उपस्थिति। फ़ाइलों या संसाधनों की सूची की तुलना में कुछ संस्थाओं के साथ काम करना किसी व्यक्ति के लिए आसान है। इसलिए, कनेक्शन की इकाई टेम्पलेट के बाहर परिभाषित ब्लॉक का नाम होगी। इस नाम को कनेक्शन के सार को प्रतिबिंबित करना चाहिए, न कि इसकी रचना या भौतिक स्थान को। उदाहरण के नाम: lib / jquery, lib / twitter-बूटस्ट्रैप, रीसेट, ब्लॉग-मॉड्यूल / मुख्य, ब्लॉग-मॉड्यूल / फोटो, प्लगइन / कूल-वन, आदि।
• निर्भरता का विवरण और डुप्लिकेट का न्यूनतमकरण। क्योंकि हम ब्लॉकों के नामों का उल्लेख करते हैं, हमें एक जगह की आवश्यकता है जहां हम इन ब्लॉकों का वर्णन करेंगे। मैं तथाकथित "स्टेटिक रिसोर्स मैप" का वर्णन करने के लिए एक आसान-से-पढ़ा हुआ कॉन्फ़िगरेशन प्रारूप (उदाहरण के लिए, YAML में) का उपयोग करने का सुझाव देता हूं:
  
  

   reset: - fw/css/reset.css lib/underscore: - libs/underscore/underscore.js options: - useCdn lib/jquery: - libs/jquery/jquery-1.7.2.min.js options: - useCdn lib/twitter-bootstrap: - libs/bootstrap/css/bootstrap.css - libs/bootstrap/js/bootstrap.js - css/bootstrap-override.css depends: - lib/jquery framework/core: - fw/js/Tiks.js - fw/js/Classes.js - fw/js/EventsManager.js - fw/js/Core.js - fw/js/CorePublic.js - fw/js/ModulesManager.js - fw/js/Module.js - fw/js/ModuleSandbox.js depends: - lib/underscore - lib/jquery options: - merge module/blog: - js/modules/blog.js - css/modules/blog.css depends: - framework/core - lib/twitter-bootstrap 

  
  अब हमारे ब्लॉग टेम्पलेट में आपको बस कनेक्ट करने की आवश्यकता है:
  
  

   StaticInclude("module/blog") 

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

उपयोगी अभ्यास

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

अंत में, मैं कहना चाहता हूं कि मैं व्यक्तिगत परियोजनाओं में इस दृष्टिकोण का सफलतापूर्वक उपयोग करता हूं और धीरे-धीरे इसे वर्तमान परियोजना में काम पर पेश करता हूं।

इसे पढ़ने वाले सभी को धन्यवाद। मुझे किसी भी टिप्पणी और सुझाव पर खुशी होगी!