XML / XSLT टेक्नोलॉजीज का पुनर्वास

हेलो, हैबर। कुछ समय पहले, हमने अपने CMS में, अपने स्वयं के टेम्पलेट इंजन के साथ, उस समय पहले से ही मौजूद XSLT को भी लागू किया था। चूंकि XSLT में डेवलपर्स के लिए, स्टूडियो मालिकों के लिए और वेबसाइट के मालिकों के लिए भी बढ़िया और वास्तविक फायदे हैं। लेकिन हमारे भागीदारों की प्रतिक्रिया को विरोधी राय में विभाजित किया गया था: कुछ लंबे समय से इसकी उम्मीद कर रहे थे और अवसर के लिए खुश थे, दूसरों ने एक्सएसएलटी की प्रासंगिकता पर सवाल उठाया, कम उत्पादकता का हवाला देते हुए कहा कि एक्सएसएलटी का उपयोग कथित रूप से होता है।

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







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



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

XSLT टेम्पलेट इंजन, स्मार्टी और आंतरिक tpl बॉक्सिंग CMS।

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



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



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



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



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



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

XSLT के लिए 10 तर्क

प्रौद्योगिकी विश्वसनीयता



1) XSLT W3C द्वारा समर्थित एक लंबे समय से स्थापित उद्योग मानक है। यह पेशेवर डेवलपर्स की एक बड़ी टीम द्वारा विकसित किया गया है। गुणवत्ता के समर्थन के कारण प्रौद्योगिकी लगातार सुधार और अद्यतन कर रही है। दुनिया भर में, XSLT को लंबे समय से एक लेआउट मानक के रूप में माना जाता है, रूस में इसका उपयोग यैंडेक्स, माय सर्कल और अन्य जैसी बड़ी परियोजनाओं पर किया जाता है।

सुरक्षा



2) किसी भी परिस्थिति में व्यावसायिक तर्क और डेटा प्रस्तुति मॉडल का सख्त अलगाव लेआउट डिजाइनर को संपूर्ण सिस्टम को "मार" करने की अनुमति देगा यदि इसमें केवल टेम्पलेट्स तक पहुंच है।



लचीलापन



3) एक्सएसएलटी आपको पहले से किए गए काम के परिणामों का पुन: उपयोग करने की अनुमति देता है। एक बार XSLT पर बना लेआउट व्यावसायिक तर्क की कार्यक्षमता और इसके विकास का समर्थन नहीं करता है, इसलिए इसे स्वतंत्र रूप से स्केलेबल और अन्य परियोजनाओं में स्थानांतरित कर दिया जाता है।



4) ठेठ संचालन के लिए, यह केवल एक बार एक टेम्पलेट बनाने और परियोजना से परियोजना के लिए उपयोग करने के लिए पर्याप्त है। अभ्यास से एक उदाहरण: एक साथी स्टूडियो को विभिन्न कार ब्रांडों के लिए कार डीलरशिप की 3 साइटों को विकसित करने का आदेश मिला। पहली साइट बनाने में लगभग 2 महीने लगे, दूसरी साइट, नए सुधारों को ध्यान में रखते हुए, 1 महीने में विकसित किया गया, तीसरी साइट को 2 सप्ताह में उठाया गया। इस तथ्य के कारण कि तकनीक पहले से ही बनाई गई है, साइटें केवल "सजाया" (यानी, डिजाइन को बदल सकती हैं) हो सकती हैं। एक बार समस्या हल हो जाने के बाद, अगली बार 2-3 बार कम समय लगता है, यहां तक ​​कि नए कार्यों की शुरुआत के साथ भी।

उपलब्धता, समझदारी, कम विकास लागत



5) हमारे अनुभव के अनुसार, HTML और CSS से परिचित एक टाइपसेट, खरोंच से एक XSLT परियोजना का विकास समय लगभग डेढ़ महीने का औसत होगा। इसके अलावा, अगर वह अन्य परियोजना कार्यों से अलगाव में XSLT का अध्ययन करता है, तो वह इसे एक और डेढ़ सप्ताह में मास्टर कर सकता है। तुलना के लिए, एक ही लेआउट डिजाइनर प्रति सप्ताह औसतन एक विशिष्ट सीएमएस के टीपीएल-टेम्पलेट इंजन को मास्टर करने में सक्षम होगा, और एक परियोजना पर काम करने की प्रक्रिया में महारत हासिल करने में उसे उसी महीने लगेगा। लेकिन XSLT लेआउट डिजाइनर को केवल एक बार सीखने की जरूरत है, और प्रत्येक व्यक्ति tpl- टेम्पलेट इंजन एक अलग अध्ययन खींचता है। इसलिए, XSLT पर पहली परियोजना विकसित करने के बाद, हम कार्यान्वयन चरण में बचत के बारे में बात कर सकते हैं।



alienability



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



तानाना



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



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



8) XML + XSLT में हल किए गए कुछ कार्य केवल और कुशलता से XSLT के बिना कम से कम गैर-तुच्छ लगते हैं।



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



मूल XML समर्थन



9) एक्सएमएल डेटा की बहुतायत जो अक्सर एक परियोजना में उपयोग करने की आवश्यकता होती है, वह हमारी वास्तविकता है। XSLT टेम्पलेट इंजन एक देशी XML पार्सर है, और अन्य सभी समाधान एक साइकिल हैं।



प्रदर्शन और गति



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

XSLT के नुकसान के बारे में।

दुर्भाग्य से, कोई आदर्श लोग / उत्पाद / प्रौद्योगिकियां नहीं हैं। XSLT कोई अपवाद नहीं है।



XSLT पर एक टेम्पलेट को डीबग करना, यदि इसमें कोई गलती की जाती है, तो इसे खोजने और समाप्त करने के लिए डेवलपर से महत्वपूर्ण प्रयासों की आवश्यकता हो सकती है। इसके अलावा, यहां तक ​​कि किसी भी अस्पष्ट टैग से पूरे टेम्प्लेट की निष्क्रियता हो जाती है। इसलिए, एक्सएसएलटी को डेवलपर को विशेष देखभाल, सटीकता और विस्तार पर ध्यान देने की आवश्यकता है।



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

निष्कर्ष।

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