क्लाइंट (जावास्क्रिप्ट) पर HTML पार्स करने के कार्य पर विचार करें, इसके बाद प्राप्त डेटा को शैलियों और लेआउट के साथ प्रारूपित करके उन्हें देखने के पृष्ठ पर सही स्थानों पर प्रदर्शित किया जाए। मुझे उपयोगकर्ता स्क्रिप्ट में पृष्ठों और ब्लॉकों का ऐसा लोडर मिला - जब लोडर के डेवलपर्स किसी भी तरह से साइट के डेवलपर्स से जुड़े नहीं हैं। लेकिन मॉडल से पूरी तरह से अलग करने के लिए नियमित साइटों के लिए दृष्टिकोण का उपयोग करने का कारण है।
लेख सैद्धांतिक निकला, क्योंकि इसकी मात्रा के कारण, मैंने इसे व्यावहारिक परिणामों के साथ अधिभार देना शुरू नहीं किया। हां, और कुछ चरणों की कल्पना करना कठिन है, जिनके द्वारा हर कोई विचारों को उठा सकता है और कुछ ऐसा बनाना शुरू कर सकता है। पहले आपको विचारों को बोने की ज़रूरत है, लेकिन अभी तक बोने की कोशिशें (यहाँ, हैबे पर) अंकुरित नहीं हुई हैं, हालाँकि मैंने वास्तव में इस दिशा में कोशिश नहीं की है। दृष्टिकोण पिछले छह महीनों से विकसित हो रहा है और अप्रैल-मई के आसपास हैबे पर भी घोषित किया गया था। लेख का वर्णन "यह कैसे करना है," और दृष्टिकोण के लाभों को सूचीबद्ध करता है। इसके लिए गहरी और विशिष्ट जेएस प्रोग्रामिंग की आवश्यकता होती है। काम के परिणामों के अनुसार, सबसे अधिक संभावना है, यह समान कार्यों के लिए एक पुस्तकालय आवंटित करने के लिए समझ में आता है।
परिचय
एकल HTML ब्लॉक में प्राप्त डेटा से पृष्ठों को पार्स करने और नए पृष्ठ बनाने पर, कई एल्गोरिथम कार्य आपस में जुड़ जाते हैं, जिनसे एक अलग डिज़ाइन पैटर्न (पैटर्न) निकलता है। इसका उद्देश्य एक गतिशील टेम्पलेट के निर्माण के रूप में वर्णित किया जा सकता है, जिनमें से विभिन्न या सभी भाग निर्माण चरण में मौजूद नहीं हो सकते हैं, लेकिन डेटा जोड़ की प्रक्रिया में, तत्वों के आवश्यक क्रम में निर्मित और आवश्यक शैलियों का उपयोग करके आंशिक रूप से या पूरी तरह से इकट्ठे ब्लॉक दिखाई देता है।
उदाहरण: एक पूरा लेख एक मौजूदा पृष्ठ पर एक लेख शीर्षक के साथ अपलोड किया गया था और लापता भागों को शीर्षक में जोड़ा गया था। इस तरह के एक उदाहरण ने लगातार
हबरजैक्स में काम किया - इसने एनोटेशन फीड और अन्य रिबन पर पूर्ण लेख लोड किए, और यह स्क्रिप्ट का मुख्य और सबसे भ्रमित करने वाला हिस्सा था (उन्होंने कई प्रकार के पृष्ठों पर काम किया)। दूसरा उदाहरण: लेख का केवल शीर्षक और लिंक है; हम पूरे लेख को लोड करते हैं और इसे मूल से अलग लेआउट में कंधे से कंधा मिलाकर रखते हैं। भविष्य में, हम लेआउट और शैलियों को बदल सकते हैं - ब्लॉक या पूरे देखने के पेज के पैरामीटर को अपनी वांछित प्रस्तुति में सेट कर सकते हैं।
शुरुआत में दूसरा उदाहरण एक कामकाजी स्क्रिप्ट में जोड़ने की इच्छा थी जिसमें पैटर्न की सभी भूमिकाओं को मिलाया गया था। कुछ भी बाहर निकलना शुरू हुआ, लेकिन बहुत सारी खामियों के साथ - लेख में शीर्षक, टैग, लेखक और अन्य विशेषताओं का अभाव था। और पुरानी लिपि बिखरने लगी - इसका हिस्सा, सवालों और जवाबों में काम करना, परिवर्तनों को समझना बंद हो गया। स्पेगेटी कोड के साथ एक दिन के अभ्यास के बाद, यह स्पष्ट हो गया कि व्यवस्थित दृष्टिकोण को छोड़ कर, इसे फिर से लिखना बेहतर है। इसलिए हमें एक नया कोड और पैटर्न मिला।
संरचना
हमारे लेख हैंडलर में यह संरचना है।
*
AJAX लेख अपलोड । पता इनपुट को दिया गया है, आउटपुट लेख का HTML कोड और कुछ अनावश्यक डेटा है। यह डेटा बाद में उपयोगी होने के साथ-साथ अलग-अलग विजेट और गतिशील रूप से लिंक को बदल सकता है। इसलिए, भविष्य में, पार्सर स्क्रिप्ट पृष्ठ लोडिंग से अधिक उपयोगी जानकारी निकाल सकती है।
*
पार्सर पेज । अपने वर्तमान रूप में, यह सूचनात्मक डेटा ब्लॉक - लेख, लेखक, शीर्षक, दिनांक, टिप्पणियाँ, लेख रेटिंग्स निकालता है। यह या तो ब्लॉक कक्षाओं को छोड़ सकता है या प्रस्तुति शैलियों को बदलते हुए, अपने स्वयं के ब्लॉकों में डेटा को विसर्जित करने के लिए उन्हें हटा सकता है। दूर के भविष्य में मौजूदा पृष्ठ कक्षाओं के लिए संलग्न करना केवल हानिकारक है - पृष्ठ निर्माता किसी भी समय वर्ग नाम (प्रकाशित, प्रकाशित, वर्तमान_ प्रकाशित) में बदल सकते हैं और यदि वे अपने पृष्ठ की शैलियों में मौजूद हैं, तो शैलियों को बदलना आवश्यक होगा। यदि आप मूल पृष्ठ की कक्षाओं से छुटकारा पा लेते हैं, तो सभी परिवर्तन पार्सर में बने रहेंगे। ट्रैकिंग परिवर्तनों की देखभाल भी पार्सर की जिम्मेदारी है।
*
प्रीलोडर शैलियों । जब तक पृष्ठ प्रदर्शन स्क्रिप्ट में एक एकल शैली होती है, लोडर की आवश्यकता नहीं होती है। आप बस CSS में शैलियों को सेट कर सकते हैं या उन्हें एक बार स्क्रिप्ट के साथ लोड कर सकते हैं। लेकिन अगर आप शैलियों को गतिशील रूप से बदलना चाहते हैं, तो लोडर के साथ ऐसा करना आसान है। नियम सूची के रूप में स्टाइल्स डोम में होंगे। नियमों की एक निश्चित सूची को हटाने की आवश्यकता है, और एक दूसरे को डाउनलोड किया जाना चाहिए (मानक विधि द्वारा)।
*
Iterator लेआउट लेआउट । देखने वाले पृष्ठ की स्थिति के आधार पर, पुनरावृत्त पृष्ठ पर सही स्थानों में उन में एम्बेडेड पार्सर के नए डेटा के साथ लेआउट ब्लॉक करता है। उपयोगकर्ता क्लिक द्वारा दिखाए जाने के लिए डेटा का हिस्सा छिपाया जा सकता है - इट्रेटर डिस्प्ले स्टेट्स को नियंत्रित करता है (इसलिए, परिभाषा के अनुसार, यह एक इटेरेटर है)।
जिम्मेदारियों के इस तरह के वितरण के साथ, लोडिंग सिस्टम एक प्रबंधनीय रूप लेता है और कम जटिल हो जाता है जैसे कि आपने इसे पहले लिखा था, सभी एक पंक्ति में, सबसिस्टम की भूमिकाओं को अलग किए बिना। यह हमारे नए आविष्कृत
ब्लॉक लोडिंग पैटर्न का सार है।
यदि आप परिणाम कोड और मूल प्रोटोटाइप को देखते हैं, तो, वास्तव में, यह देखा जा सकता है कि शैलियों को उन हिस्सों से हटा दिया जाता है जो प्रतिनिधित्व के लिए जिम्मेदार नहीं हैं और उनके भागों में स्थानांतरित हो जाते हैं। सिस्टम के प्रत्येक ब्लॉक को दूसरों से अलग किया जाता है, ब्लॉक का प्रभाव उनके बीच डेटा प्रवाह द्वारा सीमित होता है।
कार्य क्रम, कनेक्शन
काम शुरू करने के लिए पूरी तरह से इकट्ठे सिस्टम के लिए, इसे कुछ के साथ शुरू करने की आवश्यकता है। लॉन्च बिंदु एक मौजूदा पृष्ठ पर लिंक और सक्रिय क्षेत्र (बटन) हैं। यह लोडर के लॉन्च के लिए या तो पहले से बनाया गया एक साधारण पेज हो सकता है, या इसका अपना पेज पहले से जेनरेट हो सकता है और इसमें समान लॉन्च बटन और लिंक हो सकते हैं।
एक साधारण पृष्ठ से शुरू करके उपयोगकर्ता क्लिकों को रोकना शामिल है। उदाहरण के लिए, उदाहरण के लिए, एक लेख के साथ एक नया पृष्ठ लोड करना, लिंक पर क्लिक करना (शीर्षक, बिल्ली, टिप्पणियाँ) AJAX लोडर को सक्रिय करता है। इसके अलावा, सब कुछ नियंत्रण हस्तांतरण श्रृंखला के साथ चला जाता है, और परिणामस्वरूप, लिंक या बटन के पास एक लोड किए गए लेख और टिप्पणियों वाला एक ब्लॉक बनता है।
साइट के रचनाकारों द्वारा मूल पृष्ठ के लेआउट को बदलने तक सब कुछ ठीक है। यदि हमारी स्क्रिप्ट को बाइंड करने का लेआउट, कक्षाएं, और अन्य तरीके बदल गए हैं, तो यह केवल इसके लॉन्च बिंदु नहीं खोजेगा, और न ही आपके हैंडलर को जगह देगा।
आर्टिकल डिस्प्ले पेज को बेहतर तरीके से नियंत्रित करने के लिए, इसे समान पार्सर के साथ पहले से संसाधित करने की आवश्यकता होती है, लेआउट और साइट शैलियों को पूरी तरह से दिखाने से बचने के लिए - फिर पार्सर को पूरी तरह से लॉन्च करने का कार्य स्वयं ही चला जाता है - यदि पार्सर स्टार्ट पेज को पहचानता है (लेख हेडरों की सूची के साथ), तो उपयोगकर्ता की इच्छा होगी पहले से ही आपके पेज के साथ काम करते हैं, जो टेम्पलेट से बनाया गया है, पूरी तरह से क्लाइंट शैलियों पर बनाया गया है। बाहर, केवल एक अलार्म हो सकता है: पृष्ठ मान्यता प्राप्त नहीं है।
यदि साइट का लेआउट इतना बदल गया है कि पार्सर ने अपने नियंत्रण बिंदु नहीं पाए हैं, तो पार्सर हैंडलर को इसकी सूचना देता है, और उदाहरण के लिए, एक नई विंडो में अपरिचित पृष्ठ दिखाने का निर्णय लिया जाता है। या किसी मौजूदा विंडो में - मुख्य बात यह है कि डेटा प्रदर्शित होता है, हालांकि सिस्टम के नियंत्रण में नहीं। और पार्सर डेवलपर्स को बदली हुई परिस्थितियों में इसे परिष्कृत करने की आवश्यकता के बारे में संकेत मिलता है।
अभ्यास से पता चलता है कि साइट पर गहरा लेआउट परिवर्तन वर्षों तक नहीं होता है, जबकि शैली में नियमित रूप से बदलाव होते हैं, हर 2 से कई महीनों तक। यदि आप अपनी शैलियों (उपयोगकर्ता शैलियों) के साथ मिश्रित साइट शैलियों के प्रदर्शन की अनुमति देते हैं, तो आपको साइट शैलियों में प्रत्येक परिवर्तन के साथ, नियमित रूप से प्रदर्शन दोषों को सही करना होगा। यदि आप अपनी शैलियों को पूरी तरह से दिखाते हैं, तो प्रोसेसर के माध्यम से पारित किया जाता है, डेटा के एक स्वच्छ प्रदर्शन के लिए एक बफर का गठन किया जाता है, जिसके प्रदर्शन का केवल लेआउट और डिजाइन में पूर्ण परिवर्तन के दुर्लभ आपातकालीन मामलों में उल्लंघन किया जा सकता है। और यहां तक कि इन मामलों में, विकसित पार्सर स्रोत पृष्ठों को दिखाते हुए या सामान्य स्थानों में लापता छोटे डेटा की रिपोर्टिंग करके सही ढंग से संभाल करने में सक्षम होगा।
आदर्श रूप से, पार्सर को पृष्ठ के सभी गैर-आवश्यक हिस्सों को नियंत्रित करना चाहिए ताकि उनमें परिवर्तन का पता लगाया जा सके जो सामान्य से अलग हैं - नए ब्लॉक, मुखबिर, विज्ञापन, और डेवलपर्स के लिए सभी नवाचारों को स्थानांतरित करना। लोड किए गए ब्लॉक (विज्ञापन और उपयोगी दोनों भागों) के मामले में, पार्सर को लाइव स्रोत पृष्ठ की छिपी हुई छवि में काम करना चाहिए। यह मोड हमेशा संभव नहीं होता है (एक लाइव पेज iframe से मूल विंडो से बच सकता है) और हमेशा इसकी आवश्यकता नहीं होती है - यह साइट पर असामान्य नवाचारों की आवधिक निगरानी के लिए आवश्यक है और ज्यादातर डेवलपर्स के लिए दिलचस्प है। सौभाग्य से, उड़ान बैनर (लोड किए गए ब्लॉकों का एक विशिष्ट उदाहरण) लगभग कभी भी साइट के पृष्ठों से संबंधित सार्थक जानकारी नहीं ले जाता है। हालांकि यह कल्पना की जा सकती है कि इस तरह से साइट के लेखक कभी-कभी अपने स्वयं के शेयरों की रिपोर्ट कर सकते हैं।
आवेदन का क्षेत्र
इस रूप में, पृष्ठ और ब्लॉक लोडर को उपयोगकर्ता स्क्रिप्ट में काम करने के लिए डिज़ाइन किया गया है - जब लोडर डेवलपर्स किसी भी तरह से साइट डेवलपर्स से जुड़े नहीं हैं। इसलिए, उन्हें परिवर्तनों के बारे में साइट के फ्रंट-एंड के परिवर्तनों के बारे में सीखना होगा। क्या यह प्रीलोडर को उपयोगकर्ता स्क्रिप्ट के रूप में उपयोग करने के लिए समझ में नहीं आता है, लेकिन वेबसाइट स्क्रिप्ट के रूप में?
बल्कि, प्रश्न पहले से ही एक उत्तर के साथ, लयबद्ध दिखता है। लोडर में कम से कम एक उपयोगकर्ता के अनुकूल प्रणाली है जो सफलतापूर्वक काम करेगी और उपयोगकर्ता स्क्रिप्ट में नहीं - यह कई संभावित दृश्यों में पृष्ठों को प्रदर्शित करती है। उपयोगकर्ता अपनी देखने की शैली चुनते हैं। मूल पृष्ठ शैलियाँ बेहद खराब हो सकती हैं, क्योंकि उन्हें अब (खोज इंजनों को छोड़कर) दिखाने की आवश्यकता नहीं है। शो की सारी जटिलता लोडर पर जाती है, और साइट के साथ काम करने के लिए हम (साइट डेवलपर्स के रूप में) एक लोडिंग बफर प्राप्त करते हैं। हम पहले से ही पेजों में नहीं, बल्कि ब्लॉक में डेटा दे सकते हैं, जैसे कि एक नियमित अजाक्स में। यदि लोडर के दायरे में देखभाल की गई थी, तो इसे जमा करने की परवाह न करें। और एक बोनस के रूप में, हमारे पास लोडर की तरफ से एक फ्रंटेंड चेंज कंट्रोल सिस्टम है, जो डेटा फीड की अखंडता की जांच कर सकता है। यदि ब्लॉक स्तर पर कुछ भूल गया है, तो अनुपस्थिति संकेत पृष्ठ परीक्षणों के दौरान लोडर से आएगा।
अंत में, आप पृष्ठों की एक परीक्षण प्रस्तुति की व्यवस्था कर सकते हैं जब लोडर न केवल उपयोगकर्ता डेटा प्रदर्शित करता है, बल्कि सभी सेवा वाले जो फ्रंटएंड पर जा रहे हैं - छिपे हुए ब्लॉक, छिपे हुए पैरामीटर जो एक बार काम करेंगे, लेकिन सामान्य फ्रंटेंड परीक्षणों से उन्हें छोड़ना आसान है या इसके बारे में भूल जाना। हालांकि, सेलेनियम यह भी जानता है कि यदि परीक्षण लिखे जाते हैं, तो उन्हें कैसे नियंत्रित किया जाए, एकमात्र अंतर यह है कि परीक्षण लिखने के लिए - लोडर में या परीक्षण शेल में।
नतीजतन, हम देखते हैं कि लोडर साइट के सबसिस्टम के रूप में काम कर सकता है, पेज व्यू के बदलाव को आसान बना सकता है और पारंपरिक टाइपिंग और स्टाइलिंग के बजाय डेटा से प्रेजेंटेशन को बेहतर तरीके से अलग किया जा सकता है। यदि हम सीधे और केवल AJAX लोडर के साथ काम करते हैं, तो हम सामान्य रूप से लेआउट के बिना, डेटा लेयर को बहुत आसान बना सकते हैं। हां, कुछ भी नया नहीं है - सभी अजाक्स साइट इस तरह से काम करती हैं। विशेष बात यह है कि लोडिंग के बारे में सभी देखभाल एक ही केंद्र में एकत्र की जाती है, और सभी आउटपुट इसके माध्यम से जाते हैं। अन्य डेटा स्ट्रीम पैटर्न से उल्लंघन और विचलन होंगे।
MVC के बारे में तब क्या? वे लोडिंग पैटर्न की परवाह किए बिना हमेशा की तरह रह सकते हैं, बहुत "उल्लंघन" होने के नाते। यह इस तरह दिखेगा। लोडिंग पैटर्न ने व्यू पेज बनाया। इसमें, एक निश्चित "बैकबोन" (सामान्य नाम) ने अपने स्वयं के सिंक्रनाइज़ेशन ब्लॉक का निर्माण किया, जिसमें बैकएंड के साथ संचार स्थापित किया गया था। यह पता चलता है कि एक विशेष दृश्य में, कई में से एक, एक ऐड-इन बनाया गया था। यदि हम इस विचार को बदलते हैं, तो आपको किसी तरह इस ऐड-इन को एक नए व्यू में ट्रांसफर करना होगा या इसके काम को फिर से शुरू करना होगा। वास्तव में, यह एक पैटर्न संघर्ष है जिस पर विचार करने की आवश्यकता है। लेकिन यह अपरिहार्य है, क्योंकि दोनों पैटर्न प्रतिनिधित्व के साथ काम करते हैं, एक दूसरे के बारे में कुछ भी नहीं जानते हैं।
अन्यथा, दृश्य बदलने में आसानी और डेटा से बेहतर लेआउट को अलग करने के लिए, यह इस साइट के सबसिस्टम के रूप में इस पैटर्न को आज़माने लायक है।
कोडर्स के बारे में क्या?
मामले जब स्क्रिप्ट सक्रिय रूप से सामने के छोर पर आक्रमण करते हैं तो हमेशा लेआउट कार्य की जटिलता के साथ होते हैं। यदि वे जेएस-टेम्प्लेट इंजन का उपयोग करते हैं, तो कुछ, कम डेवलपर्स गर्व से घोषणा करते हैं: "हमें लेआउट डिजाइनरों की आवश्यकता नहीं है," बाकी सभी चुप हैं, यह महसूस करते हुए कि उन्होंने अधिक काम जोड़ा है।
लेआउट को सरल बनाने के लिए, पृष्ठ लोडिंग पैटर्न ने टेम्पलेट ब्लॉकों के पारंपरिक HTML + CSS डिज़ाइन को बनाए रखा। टाइपसेट पैटर्न के बाकी जावास्क्रिप्ट फिलिंग को छूने के बिना उनके लिए ब्लॉक और शैलियों के साथ काम कर सकता है। यदि आपको पृष्ठों की एक नई प्रस्तुति बनाने की आवश्यकता है (नया लेआउट, "नया डिज़ाइन खींचो"), हम परियोजना में हमारे पास मौजूद सभी ब्लॉकों को लेते हैं, देखें कि उनमें से कौन इस पृष्ठ से संबंधित है। बदले में, हम प्रत्येक ब्लॉक के टेम्प्लेट और शैलियों को बदलते हैं। सभी ब्लॉकों को डिज़ाइन किया गया है ताकि उनका लेआउट बाहरी ब्लॉक के लेआउट पर निर्भर न हो (या लगभग निर्भर नहीं हो), नियंत्रण नियंत्रण सीएसएस वर्गों के अपवाद के साथ। आमतौर पर, इसके लिए शैलियों में अन्य लोगों की कक्षाओं को शामिल नहीं करना और प्रत्येक ब्लॉक में उनके बाहरी HTML तत्वों की शैलियों का वर्णन करना पर्याप्त होता है। "स्वतंत्र ब्लॉकों की अवधारणा", यैंडेक्स के संदर्भ में।
परिणामों का निरीक्षण करने के लिए, आपके पास कई परीक्षण पृष्ठ होने चाहिए। वे वास्तविक लोगों के समान डेटा ब्लॉक से बनते हैं और प्रदर्शन के विभिन्न परीक्षण मामलों सहित। उपयोगकर्ता स्क्रिप्ट के मामले में, ऐसा डेटा विशेष परीक्षण ब्लॉक होगा, जिस पर लेआउट डिजाइनर पृष्ठों की प्रस्तुति का काम करता है। टेस्ट डोमेन पर या स्थानीय एक के साथ एक वास्तविक डोमेन (विंडोज पर मेजबान फ़ाइल, / आदि / लिनक्स पर होस्ट) के साथ ऐसे ब्लॉकों को देखना सुविधाजनक है। ब्लॉक डेटा को साधारण स्थिर फ़ाइलों के रूप में जारी किया जाता है।
उपयोगकर्ता स्क्रिप्ट के लिए परीक्षण पृष्ठों का लाभ यह है कि यदि साइट अस्थायी रूप से अनुपलब्ध है या डिज़ाइन में परिवर्तन किया है, तो परीक्षण पृष्ठों के साथ काम बाधित नहीं होता है, और डिज़ाइन के परिवर्तन के मामले में, पिछले स्वयं के डिज़ाइन और लेआउट के उदाहरण उपलब्ध रहते हैं।
लोडर पैटर्न की साइट स्क्रिप्ट के लिए, परीक्षण पृष्ठ आपको बैकएंड की स्थिति की परवाह किए बिना डिजाइनों के संग्रह को संग्रहीत करने की अनुमति देते हैं। बैकएंड में, इसके लिए, स्थैतिक परीक्षण पृष्ठों और उनके संस्करणों पर स्विच करना (अधिमानतः सामने के छोर से) प्रदान करना आवश्यक है।
अगर हमें जेएस टेम्पलेट की आवश्यकता है तो क्या होगा?
यदि पार्सर के लिए HTML टेम्पलेट पर्याप्त नहीं है (उदाहरण के लिए, JSON में टेम्पलेट की आवश्यकता है, क्योंकि इसे सेटिंग्स द्वारा संशोधित किया गया है), तो लेआउट डिजाइनर परिचित वातावरण में टाइपसेट करने की क्षमता खो देता है। बेशक, यह HTML के बजाय JSON के साथ काम करने के लिए थोड़ा सिखाया जा सकता है, लेकिन यह संभव है कि प्रत्येक व्यक्ति लेआउट त्रुटियों की संख्या में वृद्धि करेगा। सबसे अच्छा विकल्प (इस एप्लिकेशन में परीक्षण नहीं किया गया है) संभवतया उसी परिचित वातावरण के साथ काम करने के लिए जेएसएन-HTML से जेएस टेम्पलेट कनवर्टर करने के लिए है।
यह कैसे काम करता है?
आइए कोड के मुख्य भागों को दर्शाते हुए पैटर्न के सिद्धांतों का वर्णन करने का प्रयास करें।
हम लेख को अपने नए लेआउट में पार्स करने और फिर से लिखने के लिए HTML टेम्पलेट का निर्माण करेंगे - लेख के अपने लेआउट में, साइट के लेआउट के समान, लेकिन बिल्कुल समान होने की आवश्यकता नहीं है। इसमें कुछ नियंत्रण विशेषताएँ हैं, इसलिए यह केवल एक ब्लॉक प्रदर्शित करने के लिए एक टेम्पलेट नहीं है (इस मामले में, टिप्पणियों के साथ लेख), लेकिन इसमें कई उपयोगकर्ता-परिभाषित फ़ंक्शन हैं।
एक चीज केवल एक टेम्पलेट तक सीमित नहीं है, क्योंकि हमें साइट पेज से अपने टेम्पलेट को खोलना होगा। पार्सिंग टेम्प्लेट - साइट के तत्वों को दोहराता है और जानकारी को नियंत्रित करने और निकालने के लिए कार्य करता है, और डेटा प्रस्तुत करने के लिए HTML ब्लॉक बनाने के लिए - इस मामले में, टिप्पणियों के साथ लेख)। लेकिन सादगी के लिए, हम दोनों के लिए काम करने वाले टेम्पलेट का एक अनुमानित दृश्य दिखाते हैं। हम इसे एक भी बना सकते हैं, लेकिन यह दृष्टिकोण का उल्लंघन है, क्योंकि यह साइट में परिवर्तन की खोज में काम को जोड़ देगा।
डिस्प्ले टेम्प्लेट, इसलिए, कभी-कभी सुधार की आवश्यकता हो सकती है - किसी विशेष प्रस्तुति के लिए अनावश्यक टैग का बहिष्करण। लेकिन आप इस तरह के ब्लॉक को शैलियों के साथ अदृश्य बना सकते हैं या टैग विशेषताओं में डेटा छिपा सकते हैं। एक अलग लेआउट के लिए, यदि आवश्यक हो तो हम एक अलग टेम्पलेट बना सकते हैं।
शो कोड (टिप्पणियां वैकल्पिक हैं, स्पष्टीकरण के लिए दी गई हैं)<div class="post"> <div class="published"> </div> <h1 class="title"> </h1> <div class="hubs"> </div> <div class="content"> <div class="clear"></div> </div> <div class="btnBack" style="display: block;"> <i>← </i> <div class="percent"> <div class="gPercent"><div style="width:<!-- -->px"></div></div> , <i></i> </div> </div> <div class="content c2"> <div class="clear"></div> </div> <div class="btnBack n2" style="display: block;"> <i>← </i> </div> <ul class="tags"> </ul> <div class="infopanel"> <div class="voting"> <a href="#plus" class="plus" title=""></a> <div style="position: relative;" class="mark"> <a class="score" title=" " href="#">—</a> </div> <a href="#minus" class="minus" title=" "></a> </div> <div class="pageviews" title=""></div> <div class="favorite"> <a class="add" title=" " href="#"> </a> </div> <div class="favs_count" title=" , "></div> <div class="author"> <a title=" "> </a> <span class="rating" title=" "></span> </div> <div class="informative"> <a title=" "></a> </div> <div class="showComm btnBack inln">→</div> <div class="published"></div> </div> <div class="showComm btnBack" style="display: block;"> <i>← </i> </div> <div class="comments_list"> <h2 class="title"> </h2> </div> <div class="showComm btnBack n2" style="display: block;"> <i>← </i> </div> </div>
हर जगह इस तरह के टेम्पलेट का उपयोग करने से, हम एक दूसरे के समान सामान्य वेबसाइट टेम्पलेट्स की अस्थिरता से छुटकारा पा लेते हैं:
*) लेख
*) सवाल और जवाब,
*) सैंडबॉक्स लेख,
*) खोज से लेख लोड करना,
*) पसंदीदा सूची से डाउनलोड करें।
उदाहरण के लिए, प्रश्नों और उत्तरों का प्रारूप लेख के प्रारूप के अनुरूप होगा। सच है, पूर्ण अनुपालन के लिए स्वयं के उत्तरों को फिर से व्यवस्थित करना आवश्यक है, यह पार्सिंग का एक और चरण है, लेकिन आप इसे छोड़ सकते हैं जैसा कि यह है और वर्तमान लेआउट पर निर्भर करता है।
प्रदर्शन निर्भरता की आवश्यकता कब है? लंबे लेखों के मामले में, लेख ब्लॉक के लिए शीर्षक, दिनांक और लेखक की आवश्यकता होती है, जिसे कम से कम 2 स्थानों पर दिखाया जाना चाहिए - ऊपर और नीचे, और यह आम तौर पर लंबे ग्रंथों की स्थिति को ट्रैक करने के लिए बेहतर है, और जब लेखक दिखाई नहीं देता है, तो इसे विंडो के भीतर एक पॉप-अप विंडो में दिखाएं, साथ ही शीर्षक। लेख, और तारीख। सुविधा परिमाण के एक क्रम से बढ़ेगी, और यह अक्सर साइटों पर नहीं किया जाता है - आखिरकार, यह एक अतिरिक्त प्रोग्रामिंग लागत है। अंतर्निहित प्रस्तुति टेम्पलेट के साथ, हम साइट के सभी समान ब्लॉकों और यहां तक कि अन्य समान साइटों पर भी एक बार स्क्रिप्ट और शैलियों में आवश्यक तर्क बना सकते हैं। यदि हम एक लेख को कई लेख खंडों वाले पृष्ठ में लोड करते हैं, तो संदर्भ के आधार पर पॉप-अप विंडो की सामग्री बदल जाती है।
इस तरह की स्क्रिप्ट के साथ शुरुआती काम के लिए, लेखक और तारीख के डेटा को लेख से पहले और बाद में 2 स्थानों पर टेम्पलेट में लोड किया जाता है। यदि लेख छोटा है, खिड़की के आकार से छोटा है, तो दो क्षेत्रों की आवश्यकता नहीं है, स्क्रिप्ट उनमें से एक को छिपाएगी। यदि लेख बड़ा है, तो स्क्रिप्ट मुख्य स्थानों में उनकी अदृश्यता के क्षणों में एक अस्थायी विंडो में डेटा में प्रवेश करती है।
और कभी-कभी प्रश्नों और उत्तरों के प्रारूप में प्रश्न का स्पष्टीकरण होता है। यदि हम प्रश्न के साथ परिशोधन को पार्स करते हैं - कोई भविष्य की समस्याएं नहीं हैं, इसके अलावा, फिर से, हम साइट के लेआउट पर निर्भर करते हैं। यदि हम अलग-अलग पार्स करते हैं, तो "क्वेरिफिकेशन ऑफ़ द क्वेश्चन" ब्लॉक हमारे टेम्प्लेट में दिखाई देता है, जो हमेशा खाली रहता है, सिवाय स्पष्टीकरण के प्रश्नों के। अब हमारे लिए इसे शून्य ऊँचाई तक अदृश्य बनाना आसान है। लेकिन अगर यह संभव नहीं था, तो नियमों को मैप करने के लिए इस ब्लॉक या एक विशेष
क्यूए वर्ग को निकालना आवश्यक होगा।
पार्सर
हालांकि, क्लाइंट पर ग्रंथों का संश्लेषण कभी जटिल नहीं होता है और स्पष्टीकरण की आवश्यकता होती है। पृष्ठ विश्लेषण, पार्सिंग को कैसे अंजाम दिया जाता है, इसकी व्याख्या करना बहुत अधिक दिलचस्प है। पहले से ही कहीं न कहीं पुस्तकालय लिखे गए हैं, लेकिन खुद को बाइक बनाना दिलचस्प है, और फिर मौजूदा एनालॉग्स के साथ पार्सर कोर की जटिलता की तुलना करें। इस तथ्य के बावजूद कि अपने स्वयं के मूल में कोई कचरा नहीं होगा, बाकी गुणवत्ता का स्तर उस समय से निर्धारित होता है जिसे लिखने में समस्या का सार और विश्लेषण की गहराई होती है।
हमें पार्स करने से क्या चाहिए? सरल मामले में, आपको पृष्ठ से कई पाठ ऑब्जेक्ट चुनने की आवश्यकता है। यदि ये सर्वर से हमारे पृष्ठ थे, तो JSON द्वारा पूरी तरह से विनिमय करना और सभी आवश्यक संस्थाओं (वस्तुओं) को स्थानांतरित करना बेहतर है। चूंकि हम सरल विदेशी HTML पृष्ठों को पार्स करने पर विचार कर रहे हैं, हमें टेक्स्ट (संभव त्रुटियों के साथ HTML, अर्थात् एक्सएचटीएमएल नहीं) का विश्लेषण करना होगा।
उदाहरण के लिए, पुराने पार्सर में, 2 ऑब्जेक्ट आवंटित किए गए थे - लेख का पाठ और टिप्पणियों की सूची। यह 2 नियमित अभिव्यक्तियों के साथ किया गया था (सैद्धांतिक रूप से, यह एक हो सकता है) और एक वर्ष से अधिक उपयोग के लिए, पार्सिंग को एक बार संपादित किया जाना था, जब साइट लेखकों की कीमत पर पार्सिंग में शामिल लाइनें बदल गईं। थोड़ी देर बाद लेख में कीवर्ड पार्सिंग - कीवर्ड करना आवश्यक था। यहाँ लेख और टैग की पार्सिंग के साथ पहली नियमित अभिव्यक्ति का एक उदाहरण है।
var conte = this.responseText.match(
इस तरह, स्रोत पाठ की कई मान्यताओं के लिए, यह बहुत तेज़ नहीं है, लेकिन आप कई वस्तुओं का चयन कर सकते हैं जिनकी हमें आमतौर पर आवश्यकता होती है। और यह आमतौर पर पर्याप्त है - आपको बाद में इसका एक टुकड़ा लेने के लिए एक पूर्ण डोम विश्लेषण नहीं करना होगा।
यदि आप मान्यता को गति देना चाहते हैं, तो आप पाठ के एक सामान्य ब्लॉक को टुकड़ों में काट सकते हैं और फिर टुकड़ों का विश्लेषण कर सकते हैं। यह विधि पुराने जमाने और धीमी है, लेकिन इसके लिए उन्नत पुस्तकालयों की आवश्यकता नहीं है और एक साइट पर वर्षों तक काम कर सकते हैं।
यदि आपको पार्सिंग के सर्वोत्तम स्तर को पेश करने की आवश्यकता है, तो आपको इस हिस्से पर काम करना होगा या तीसरे पक्ष के समाधान की तलाश करनी होगी। उदाहरण के लिए, यहां अगली चीज़ जो आप चाहते हैं (जानकारी पैनल से रेटिंग और मापदंडों को खींचने के बाद, जो तेज़ है) टिप्पणी पेड़ को पार्स करना है। इसके अलावा, विभिन्न साइटों के लिए हर बार फिर से पार्सिंग न करने के लिए, एक सामान्य प्रक्रिया लिखना अच्छा होगा। फिर हम या तो टिप्पणियों को कॉम्पैक्ट रूप से संग्रहीत कर सकते हैं, या उन सभी को अपने स्वयं के लेआउट के साथ एक पेड़ में व्यवस्थित कर सकते हैं, जो डिजाइन के लिए बेहतर है।
जब कार्य ब्लॉक के तत्वों के पूर्ण नियंत्रण के लिए उठता है (तुरंत यह पता लगाने के लिए कि क्या लेआउट में कुछ नया दिखाई दिया है), तो आपको लाइन में एक पूर्ण टैग पार्सर की आवश्यकता होगी। लेकिन अभी के लिए, हम भविष्य के लिए इसे सुरक्षित रूप से स्थगित कर देंगे।
पार्सिंग और संश्लेषण के लिए विभिन्न पैटर्न
जब हम किसी ब्लॉक का अपना प्रतिनिधित्व प्रदर्शित करते हैं, तो हम पार्सिंग की तुलना में एक समान समस्या को हल करते हैं। लेकिन, फिर भी, ये अलग-अलग कार्य हैं, अगर हम मूल से किसी के विचार की स्वतंत्रता के नियम को ध्यान में रखते हैं। पार्सिंग के लिए एक टेम्पलेट होगा - और दूसरा (या अन्य) - दृश्य के निर्माण के लिए। यह "उपयोगकर्ता शैली + कुछ उपयोगकर्ता स्क्रिप्ट" दृष्टिकोण से एक मूलभूत अंतर है, जिसमें वे दोनों बहुत समान टेम्पलेटों को संयोजित करने का प्रयास करते हैं ताकि कोड में स्वयं टेम्पलेट की आवश्यकता न रहे - स्रोत टेम्पलेट साइट से एक ब्लॉक है, अंतिम टेम्पलेट समान है लिपियों द्वारा थोड़ा संशोधित, और सभी दृश्य अंतर शैलियों द्वारा आरोपित हैं।
इस दृष्टिकोण (उपयोगकर्ता शैली) के साथ एक टेम्पलेट सामान्य रूप से कोड में अदृश्य है। यह, जैसा कि यह आने वाले डेटा में भंग कर दिया गया था, अदृश्य रूप से मौजूद है और केवल स्क्रिप्ट के निर्माता के लिए काफी स्पष्ट है, और फिर अगर इसके साथ काम चल रहा है। इसलिए, पृष्ठ के स्रोत (एलियन) कोड में किसी भी मामूली बदलाव का बाद के सभी परिणामों पर एक मजबूत प्रभाव पड़ता है - स्क्रिप्ट काम करना बंद कर सकती है; ताकि वे त्रुटियों का निर्माण न करें, आपको उनमें किसी भी त्रुटि के प्रावधान के साथ सुरक्षित डेटा विश्लेषण की तकनीक का उपयोग करने की आवश्यकता है; शैलियों को विकृत किया जाएगा और पृष्ठ गलत दिखाई देगा। यह देखते हुए कि अलग-अलग ब्राउज़र हैं, सामान्य प्रदर्शन को बनाए रखना भी मुश्किल है - मूल पृष्ठ का प्रत्येक परिवर्तन कहीं भी प्रदर्शन को तोड़ सकता है।
यदि हम ब्लॉकों के विश्लेषण और संश्लेषण के लिए विचारों को साझा करते हैं, तो एक-दूसरे से संबंधित कठिनाइयों को भी विभाजित नहीं किया जाता है। कार्य संरचित है, समाधान की जटिलता कम हो गई है। विश्लेषण की त्रुटियां (पार्सिंग) उनके साथ बनी हुई हैं, और सबसे ज्यादा जो वे कर सकते हैं वह है पन्नों से पहले निकाले गए भाग या सभी डेटा की कमी। ब्लॉक का प्रदर्शन केवल इसके लेआउट पर निर्भर करता है और संभवतः, इसे डेटा के साथ भरने पर।
इसलिए, हम परिणामस्वरूप स्क्रिप्ट में 2 या अधिक समान पैटर्न की उपस्थिति पर आश्चर्यचकित नहीं होंगे। एक पार्सिंग और सत्यापन (साइट ब्लॉक का विश्लेषण) के लिए है, दूसरा ब्लॉक के अपने प्रतिनिधित्व के निर्माण के लिए है। तीसरा और इससे परे एक ही डेटा के अन्य संभावित प्रतिनिधित्व हैं जो अपने स्वयं के HTML टेम्पलेट्स और सीएसएस नियमों की आवश्यकता है।
इसलिए, पाठकों की विभिन्न परतों के स्वाद से संतुष्ट हैं। यदि पहले सभी को साइट के एकमात्र उपलब्ध प्रतिनिधित्व के लिए "प्यार" करने के लिए मजबूर किया गया था, अब जो लोग आदी हैं, आप एक सटीक या लगभग सटीक प्रतिलिपि बना सकते हैं या यहां तक कि संकेत भी बना सकते हैं जैसे कि पुराने डिजाइन को संरक्षित करना (साइट ने एक प्रगतिशील डिजाइन पेश किया और हर कोई इसके पुराने संस्करण पर बैठा है) । उन लोगों के लिए जो अलग तरह से सोचते हैं - अपने स्वयं के, अन्य डिज़ाइन विकल्पों और लेआउट का उपयोग करते हैं, जो अब मूल साइट में परिवर्तन से इतनी आसानी से टूट नहीं रहे हैं।
तकनीकी रूप से, यह मुख्य स्क्रिप्ट के मॉड्यूल के रूप में विभिन्न लेआउट को जोड़ने के लिए समझ में आता है। यदि मुख्य स्क्रिप्ट लेआउट मॉड्यूल को देखता है, तो यह उसकी सेटिंग्स के आधार पर एक विकल्प के रूप में या मुख्य एक के रूप में शामिल करता है।
उपयोगकर्ता स्क्रिप्ट के मामले में ब्लॉक सेटिंग
यदि हमारे पास स्क्रिप्ट को डीबग करने के लिए सर्वर के साथ काम करने के लिए कोई उपकरण नहीं है, तो हम डिज़ाइन और डीबग मोड में पूरी तरह से javaskipt सुविधाओं का उपयोग करेंगे। क्या आप तैयार पृष्ठ के अंदर टेम्पलेट को खाली रखना चाहते हैं? DOM पेज पर सही जगह टेम्प्लेट डालने के लिए बस एक स्क्रिप्ट लिखें।
var tpArtic ='......'; var rotPosts ='... ...'; if(rotPosts) ... ...;
// (कोड जानबूझकर यहां इंगित नहीं किया गया है, ताकि लंबे समय तक इसकी प्रक्रियाओं की आंतरिक संरचना की व्याख्या न हो)
पृष्ठ में टेम्पलेट को देखने के बाद, हम इसे मैन्युअल रूप से परीक्षण सामग्री से भरते हैं और इसे बनाते हैं ताकि यह फ़्रेमिंग पृष्ठ की शैलियों पर निर्भर न हो। फिर हम उनके इच्छित उद्देश्य के लिए सही टेम्पलेट और शैलियों का उपयोग करते हैं।
यदि शैलियों और टेम्पलेट को दूसरों द्वारा प्रतिस्थापित किया जाना है, तो हम स्क्रिप्ट सेटिंग्स के अनुसार सीएसएस नियमों को लागू करने और हटाने की व्यवस्था करते हैं।
समाचार साइट पर सक्रिय ब्लॉक
यह सिर्फ इतना होता है कि समाचार साइटों पर डेटा प्रदर्शित करने के लिए हमें रुचि रखने वाले मुख्य टेम्पलेट को एक टेम्पलेट द्वारा वर्णित किया जाता है, जिसे "टिप्पणियों के साथ लेख" कहा जा सकता है। उपयोगकर्ता डेटा और विशेष साइट सेटिंग्स भी हैं, लेकिन ये टेम्पलेट अवलोकन के लिए बहुत कम दिलचस्प हैं। इसलिए, इस तरह के कम से कम एक टेम्पलेट को बनाकर, हम इसके माध्यम से किसी भी समाचार और लेख को पढ़ सकते हैं जो लगभग 90% साइटों पर प्रचलित और प्रचलित है। ए। लेबेडेव की निराशा की भविष्यवाणी में यह सच है कि "साइटों को हार का सामना करना पड़ेगा", हजारों डिजाइनर रोटी खोना शुरू कर देंगे, उनकी सभी आशा पेंशनभोगियों के लिए बनी हुई है जिन्होंने अभी तक समाचार स्क्रिप्ट को पार्स करना नहीं सीखा है। जब तक आप खासतौर पर टेम्पलेट में "न्यूज़ सोर्स" फ़ील्ड का ध्यान नहीं रखते, तब तक ख़ुद का चेहरा खो जाएगा, या बल्कि, वह हिस्सा जो अपने मध्यस्थ को दिखाने के लिए ज़िम्मेदार है।
लेकिन जब हम एक ही साइट पर होते हैं, तो यह भयानक सर्वनाश परिदृश्य अभी भी काम नहीं करता है, और आप स्रोत साइट की स्वच्छ डिजाइन दृष्टि को सुरक्षित रूप से विकृत कर सकते हैं - उपयोगकर्ता जानता है कि एक साइट पर क्या है।
छिपी हुई शक्तियाँ
ब्लॉकों का पार्सर-सिंथेसाइज़र बनाने के बाद, हमें अपने स्वयं के क्लाइंट एप्लिकेशन के लिए ताकत का एक और स्रोत मिलता है। हमने मोनोलिथ लेआउट से छुटकारा पा लिया, जो साइट पर आने वाले आगंतुकों को खिलाते हैं। आमतौर पर केवल विज्ञापन कटर साइट के लेआउट में हस्तक्षेप करते हैं। यहां हमें उपयोगी ब्लॉकों की संरचना विस्तार से मिलती है। हम इसे मशीन JSON प्रारूप में सहेज सकते हैं, इसे मुख्य सर्वर की निष्क्रियता की अवधि के लिए संग्रह और समर्थन सर्वर को भेज सकते हैं। सामान्य तौर पर, हमें वह सब कुछ मिलता है जो नियमित रूप से आरएसएस के लोग करते हैं या नियमित करते हैं, लेकिन आमतौर पर संचालित पेज पार्सर होते हैं। साइट विज्ञापन के साथ - यहाँ, हम, निश्चित रूप से, किसी अन्य मुद्दे पर स्पर्श करें, जानकारी नहीं पढ़ रहे हैं, लेकिन विज्ञापन प्रदर्शित करने के माध्यम से साइट बनाने का मॉडल। मॉडल का पुनर्निर्माण करके, आप ऐसे मुद्दों को हल कर सकते हैं। सबसे अधिक संभावना है, यह बहुत दूर का भविष्य नहीं है, जब सरल पृष्ठों में विज्ञापन और भी बदतर हो जाएगा। लेकिन अब हम विमुद्रीकरण मॉडल के बारे में सोचने या समर्थन करने के लिए नहीं जा रहे हैं, बल्कि ऐसी जानकारी के बारे में सोचते हैं जो किसी एकल साइडर (स्रोत साइट) से बाधित हो सकती है।
कई मेहनती कॉपियर यहां बचाव के लिए आते हैं, जो स्वयं केंद्र में ताजा और उपयोगी सामग्री प्रदर्शित करके तीसरे पक्ष के विज्ञापन से लाभ उठाने से बाज नहीं आते हैं, और खोज इंजन कैश जो 1-2 सप्ताह की अवधि के लिए उपयोगी पृष्ठ सामग्री बनाए रखते हैं, एक निश्चित आवृत्ति के साथ ऐसा कर रहे हैं - घंटे-घंटे । इसलिए, वे याद रखते हैं कि पृष्ठ पर पहुंचने से पहले अंतिम ताजा स्थिति नहीं देखी जा सकती (साइट "नीचे चली गई", पृष्ठ हटा दिया गया, फिर से लिखा गया, घटाया गया) और हमेशा, स्वाभाविक रूप से, एक अतिथि, एक अनधिकृत उपयोगकर्ता की आंखों के माध्यम से साइट को देखें।
तुरंत हमें पृष्ठ की एक प्रति मिल जाती है, जिसे हम दूसरों के साथ साझा करने के लिए तैयार होते हैं, जिनके पास अपने नवीनतम वास्तविक रूप में अपने उपयोगकर्ताओं को देखने का समय नहीं होता है जो हमें "पक्ष" बनाने की अनुमति देता है। हमें पीयर-टू-पीयर नेटवर्क जैसा कुछ मिलता है, एकमात्र अंतर यह है कि ब्राउज़र क्लाइंट सीधे अन्य साथियों को कंटेंट वितरित नहीं कर सकते हैं। उन्हें एक या अधिक सर्वरों की आवश्यकता होती है जो डुप्लिकेट साइडर के रूप में कार्य करते हैं, प्रारंभिक साइडर पर लोड को काफी कम करते हैं।
यदि प्रारंभिक साइडर काम कर रहा है, तो अतिरिक्त साइडर्स केवल सामग्री (लेआउट और विज्ञापन के बिना) जमा करते हैं। उनकी भूमिका उन दुर्लभ क्षणों में शुरू होती है जब प्रारंभिक सवार ने काम करना बंद कर दिया था। यह छिपी शक्ति स्रोत पृष्ठों के क्लाइंट पार्सिंग के तंत्र में निहित है। इसके लिए प्रकट होना शुरू करना, ज़ाहिर है, हमें मॉडल को परिष्कृत करने और उपयोगी डेटा को बैकअप सर्वर में स्थानांतरित करने की आवश्यकता है।
अपना खुद का पेज शेयर करें
कल्पना करें कि हम पहले ही उस पृष्ठ को डाउनलोड कर चुके हैं जिस पर हम स्थित हैं और इसे पार्स करना चाहते हैं। अपनी खुद की लेआउट में इसे फिर से लिखने के लिए या अपनी साइट की पूरी तस्वीर प्राप्त करने के लिए डेटा निकालने के लिए, आपको अपने स्वयं के पृष्ठ (वर्तमान पृष्ठ के URL पर) को फिर से डाउनलोड करने की आवश्यकता नहीं है यदि आप सिर्फ document.body.inner HTML या पेज की गहरी सामग्री का उपयोग करते हैं। । केवल यह याद रखना आवश्यक है कि लगभग सभी ब्राउज़र अपनी क्षमता के भीतर इनर HTML ट्रिम करते हैं, टैग विशेषताओं को पुन: व्यवस्थित करते हैं और कभी-कभी अपनी विशेषताओं को जोड़ते हैं। लेकिन परिणाम एक पाठ है जो पार्सर के लिए पर्याप्त रूप से पठनीय है, जिसे हमने पहले ही समाधान के पिछले चरण में पार्स करना सीख लिया है।
अपने स्वयं के पृष्ठ को पार्स करने की व्यवस्था होने के बाद, हम इसे अपनी प्रस्तुति (डिज़ाइन, लेआउट) में तुरंत प्रदर्शित कर सकते हैं, यदि पहली बार में हम पृष्ठ की संपूर्ण सामग्री को शैलियों के साथ वेबसाइट के लेआउट में छिपा दें। कभी-कभी इस तरह की चाल उपयोगी हो सकती है, जो साइट के पृष्ठों में आपकी स्वयं की प्रदर्शन शैली की पैठ की गहराई पर निर्भर करती है।
परिणाम
अब यह टेम्प्लेट और इसे भरने की विधि आपको "लेख-टिप्पणी" ब्लॉक का एक उदाहरण कहीं भी रखने की अनुमति देती है, यहां तक कि आपके पृष्ठ पर एक खाली जगह पर भी। यदि पहले प्रतियां केवल 5 मामलों में रखी गई थीं, जहां ब्लॉक ब्लैंक मौजूद थे (एनोटेशन के स्थान पर), अब 3 में से 1 पाद लेख के तहत, आप लेख भी लोड कर सकते हैं। बेशक, कोड की कुछ तैयारी के साथ - डाउनलोड सक्रियण बटन डालें, लेख का स्थान इंगित करें। पुरानी लिपियों के साथ यह भी संभव है, लेकिन पुरानी लिपियां कम पठनीय थीं, विकास के लिए बदतर रूप से अनुकूलित, असंरचित (पढ़ने और विकसित करने के लिए कठिन), तैयार करने के लिए अधिक कोड की आवश्यकता होगी।
अंत में, यह कोड, जिसे हम ब्लॉक लोडिंग पैटर्न कहते हैं, का उपयोग अन्य स्थानों में किया जा सकता है, जैसा कि लेख के पहले भाग में वर्णित है। इसे एक प्रक्रिया के रूप में नहीं लिया जा सकता है, यह एक शाब्दिक पैटर्न है, अर्थात एक टेम्पलेट जिसके द्वारा इसी तरह के समाधान लागू किए जाते हैं। यह एक बहुत ही जटिल स्निपेट जैसा दिखता है - कोड का एक टुकड़ा जिसे पोर्ट किया जा सकता है और किसी अन्य स्थान पर काम करने के लिए अनुकूलित किया जा सकता है जहां समान कार्यों की आवश्यकता होती है।
लोडिंग पैटर्न के साथ कोड के इस टुकड़े के प्रोटोटाइप ने टिप्पणियों के साथ कोड की 350 पंक्तियों पर कब्जा कर लिया, जिसमें एक वर्ष पहले लेख ब्लॉक के राज्यों के अनुसार इसमें एक पुनरावृत्ति की व्यवस्था करने का प्रयास भी शामिल है। वास्तव में, इटेटर पहले से ही कोड में "भंग" हो गया था, 8 राज्यों के टुकड़े को ट्रैक कर रहा था और वर्तमान राज्य के आधार पर ब्लॉक खोलने के लिए नियम दिखा रहा था। उदाहरण के लिए, जब सवाल और जवाब लोड करते हैं, तो उन्होंने विस्तृत प्रश्न और उत्तर दिखाए, और जब एक लेख या उस पर टिप्पणी लोड करते हैं, तो उन्होंने या तो एक लेख या टिप्पणी दिखाई - जहां उपयोगकर्ता क्लिक करता है।
अब यह कोड की अधिक पंक्तियों को लेता है, लेकिन फ़ंक्शन विस्तारित हो जाते हैं, कोड पारदर्शी हो गया है (लेखक के लिए) और प्रबंधनीय। डेटा का एक भाग टेम्पलेट में निकाला जाता है, और इससे पहले इसे जावास्क्रिप्ट कोड से जनरेट किया गया था।
दृष्टिकोण के संपूर्ण परिवर्तन से अधिक की अपेक्षा की जाती है - विभिन्न पृष्ठ राज्यों की पवनचक्कियों के साथ छोटे कोडिंग और लड़ाई के बजाय, हमें स्रोत साइट के एनकोडर के सोचने के तरीके से एक अलग प्रणाली और एक अनलिंकिंग मिलती है।