Umi.CMS डेवलपर समस्या ट्री, धीमी वृद्धि विकल्प

दुर्भाग्य से प्रोग्रामर के लिए, Umi.CMS पर परियोजना के विकास के बाद, उसे दो समस्याएं हो सकती हैं:

1) प्रोजेक्ट डिवाइस को भरने के लिए जिम्मेदार व्यक्ति को कैसे समझा जाए।
2) वारंटी अवधि के दौरान परियोजना के साथ समस्याओं को जल्दी से कैसे हल करें।

Umi.CMS मॉड्यूल का एक सेट प्रदान करता है जो वास्तविक समस्याओं को हल करने के लिए पर्याप्त रूप से अमूर्त हैं। दरअसल, सिस्टम में कोई भी मॉड्यूल उपलब्ध नहीं है
यह आपको ग्राहक के कार्यों को तुरंत हल करने की अनुमति नहीं देता है, क्योंकि डिफ़ॉल्ट रूप से टेम्प्लेट में एम्बेडेड कार्यक्षमता काफी सीमित है। विशिष्ट समस्याओं के लिए तैयार समाधान के बजाय
उपकरणों का एक सेट पेश किया जाता है जो आपको लचीले ढंग से आवश्यक समाधान तैयार करने की अनुमति देता है।

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

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

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

पेज ट्री की शॉक ग्रोथ निम्नलिखित कारणों से होती है:

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

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

2) व्यक्तिगत डेटा प्रकारों के लिए बनाई गई बड़ी संख्या में पैरामीटर। उदाहरण के लिए, कैटलॉग या ऑनलाइन स्टोर प्रदर्शित करने के लिए मापदंडों वाले विशेष पृष्ठों के अलावा, कैटलॉग के किसी विशेष खंड को प्रदर्शित करने के लिए मापदंडों के समूह बनाए जा सकते हैं।
समस्या को बढ़ाने के लिए, एक प्रोग्रामर की इच्छा विकास के समय को कम करने और इन पृष्ठों के पहचानकर्ताओं के लिए विशेष रूप से महत्वपूर्ण पृष्ठों से मापदंडों के चयन को टाई करने से समस्या बढ़ सकती है।

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

3) कुछ परियोजना कार्यक्षमता को लागू करने के लिए उपयोग किए गए ट्री पृष्ठों का घनिष्ठ संबंध।

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

यदि आप उत्पाद की संपत्ति "पेड़ से लिंक" सेट करते हैं और इसमें एक विशिष्ट गैलरी निर्दिष्ट करते हैं, तो इसका आंदोलन फोटो डिस्प्ले पर प्रदर्शित नहीं किया जाएगा, लेकिन कॉपीराइटर को एक अतिरिक्त संपत्ति जोड़ना होगा।

इनमें से कोई भी विकल्प अंतिम समस्या को हल करता है, लेकिन इसकी कमियां हैं।

यह समझने में कि सामग्री भरने में त्रुटियां एक प्रोग्रामर के जीवन को काफी जटिल कर सकती हैं, प्रोग्रामर के लिए बेहतर है कि वह पेज ट्री को पहले से ऑप्टिमाइज़ करने की कोशिश करें, जितना संभव हो एक विशिष्ट प्रोजेक्ट में।
और आपको काम के लिए सिस्टम तैयार करने के चरण में तुरंत ऐसा करने की आवश्यकता है।

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

2) चूंकि Umi.CMS में एक प्रोग्रामर का काम नए डेटा प्रकार बनाने के लिए कम हो गया है, साथ ही नए और मौजूदा डेटा प्रकारों के लिए गुण, यह आवश्यक है कि अग्रिम में "डेटा टेम्पलेट" मॉड्यूल में सभी आवश्यक कार्य करें।
पैरामीटर पृष्ठों के लिए डेटा प्रकार बनाने के लिए विशेष रूप से ध्यान दिया जाना चाहिए। यदि परियोजना कुछ मापदंडों का उपयोग करने का इरादा रखती है, तो यह सलाह दी जाती है कि उन्हें कई अलग-अलग पृष्ठों में न रखें, लेकिन वांछित संपत्ति समूहों के साथ एक अलग डेटा प्रकार बनाने के लिए।
इस प्रकार के पृष्ठों को उनके आकस्मिक विलोपन की संभावना को कम करने के लिए स्वयं एक स्थान पर समूहित किया जाना चाहिए। आप इन पृष्ठों के लिए एक अलग मूल पृष्ठ बना सकते हैं।

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

उदाहरण के लिए, हमारे पास एक ऑनलाइन स्टोर सेटिंग पेज है। उदाहरण के लिए, हमें पृष्ठ ही नहीं बल्कि उसके डेटा प्रकार के पहचानकर्ता की आवश्यकता है। आइए एक getSpecial.xml Usel फॉर्म के अनुरोध को बनाते हैं।

<?xml version="1.0" encoding="UTF-8"?> <selection> <target expected-result="pages count" force-hierarchy="1"> <type id="{1}" /> <category depth="{3}">{2}</category> </target> <limit page="{p}">{6}</limit> <sort order="{4}">{5}</sort> </selection> 

फिर usel जैसे एक क्वेरी: // getSpecial / 152/0/0 / आरोही / आईडी / 1 / इस डेटा प्रकार के पहले पृष्ठ पर हमारे पास वापस आ जाएगी। यदि कॉपीराइटर गलती से इस पृष्ठ को हटा देता है, तो टेम्पलेट के साथ हस्तक्षेप किए बिना सीधे प्रशासनिक पैनल में एक नया बनाना संभव होगा। यह विशेष रूप से उपयोगी होगा यदि
इसके लिए सीमित अधिकारों के साथ एक व्यक्तिगत उपयोगकर्ता को पंजीकृत करके डेटा टेम्प्लेट मॉड्यूल तक कॉपीराइटर पहुंच से इनकार करें।

यह सलाह दी जाती है कि परियोजना टेम्पलेट में किसी भी पृष्ठ पहचानकर्ता का उपयोग न करें। कई पेजों को उनके डेटा प्रकार या यूसेल प्रोटोकॉल का उपयोग करके विशेष गुणों द्वारा खोजा जा सकता है।

न केवल पृष्ठ पहचानकर्ताओं, बल्कि डेटा प्रकार पहचानकर्ताओं के टेम्पलेट्स में उल्लेख को कम करने के लिए, चर सक्रिय रूप से उपयोग किया जा सकता है। उदाहरण के लिए

 <xsl:variable name="commonParamsId" select="document('usel://getSpecial/152/0/0/ascending/id/1/')/udata/page[1]/@id" /> <xsl:variable name="commonParams" select="document(concat('upage://', $commonParamsId))/udata" /> 

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

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

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