सीएमएस खुद करते हैं। साइकिलिंग का सिद्धांत

इतने मजेदार लोग

और हर कोई एक बाइक बनाता है।

और उनमें से एक सुबह

बारूद के साथ आएगा।

विक्टर त्सोई।







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



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

1. MVC हमारा सब कुछ है!

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



यह वह जगह है जहाँ रेक नंबर एक टिकी हुई है: उपस्थिति को प्रोग्राम लॉजिक से अलग किया जाना चाहिए। यह कैसे करना है - हर कोई खुद के लिए फैसला करता है। इस मुद्दे पर कुछ टूटी हुई प्रतियां हैं: यहां विभिन्न टेम्पलेट इंजन हैं, और xslt रूपांतरण हैं, और बस php + html अलग-अलग फ़ाइलों में निकाले गए हैं। पसंद बड़ी है, लेकिन "सिल्वर बुलेट", हमेशा की तरह मौजूद नहीं है: लचीलापन एक तरफ पैमाने पर होता है, और दूसरे पर इंटेलीजेंसी। यहां तक ​​कि स्मार्टी , अपने "सबसे छोटे के लिए प्रोग्रामिंग" के साथ, कई उपयोगकर्ताओं के लिए जटिल लगता है। इसलिए यदि हम एक ऐसे उपयोगकर्ता पर ध्यान केंद्रित करते हैं जो सिस्टम को बॉक्स से बाहर रखना चाहता है और इसे न्यूनतम प्रोग्रामिंग ज्ञान के साथ अपनी आवश्यकताओं के लिए फाइल करना चाहता है, तो यह उसके सिर को तोड़ने के लायक है।



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



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

2. साइट संरचना

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







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

पहले रेक। भंडारित करता है।

जब मैं अपने "मेगाड्राइव" के डिजाइन में लगा हुआ था, तो यह किसी तरह कैशिंग के लिए नहीं था ... हाँ, और आप सोचते हैं - इतना जटिल क्या है? मैंने पृष्ठ को एक चर में रखा, इसे एक फ़ाइल में सहेजा, और अगली बार मैंने इसे वहां से दिखाया। कुछ व्यापार ... किसी भी समय आप संलग्न कर सकते हैं! ओह ... और हमारे पास पंजीकृत उपयोगकर्ताओं के लिए एक अलग पृष्ठ है ... उम ... ठीक है, इसके बारे में सोचें - हम कैश में दो पृष्ठों को बचाएंगे! और हेडर में आपको "हैलो, वास्य" ... अच्छी तरह से प्रदर्शित करना होगा, फिर हेडर में इस टुकड़े को कैश नहीं किया जाना चाहिए। और तहखाने में एक ही टुकड़ा ... और बीच में ... हम्म ... मुझे अभी भी अलग-अलग अवधि के लिए पृष्ठ के विभिन्न हिस्सों को कैश करने की आवश्यकता है ... हम बैठते हैं और ब्लॉक कैशिंग के लिए इंजन और कैशिंग सिस्टम को फिर से लिखते हैं - ताकि प्रत्येक ब्लॉक का अपना जीवनकाल हो।

दूसरा रेक। भंडारित करता है।

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

तीसरा रेक करें। भंडारित करता है।

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



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



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







इंजन लिखने की प्रक्रिया में, रिफैक्टिंग के बारे में एक स्मार्ट पुस्तक पढ़ने के लिए भी समझ में आता है ... या इंजन लिखने के बाद इसे पढ़ें। किसी भी मामले में, तीनों (आप, इंजन और पुस्तक) अच्छा कर सकते हैं।

3. प्रतिरूपकता।

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

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



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



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



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



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



इसलिए, हमने मॉड्यूल को डिज़ाइन किया, कनेक्शन पर निर्णय लिया ... अब हमें यह तय करने की आवश्यकता है कि इसे कैसे कॉन्फ़िगर करें और इसे कैसे अनुमति दें। और फिर सब कुछ सरल है: चूंकि हमारे कर्नेल को गंदे काम के लिए डिज़ाइन किया गया है, इसलिए इसे एक सिरदर्द दें और xml में मॉड्यूल ने सेटिंग्स की एक सूची लौटा दी, और कर्नेल को इसे पार्स करने दें, इसे संग्रहीत करें और अनुरोध पर प्रदान करें - यह बस है सरल।



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

4. अद्यतन

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



मेरे पास दो विकल्पों के लिए विचार थे: स्क्रिप्ट एक अस्थायी निर्देशिका में अपडेट डाउनलोड करती है, और फिर, एफ़टीपी एक्सेस सेटिंग्स के लिए उपयोगकर्ता से पूछने के बाद, यह खुद को अपडेट करता है। इसलिए उसे अतिरिक्त अधिकार देने की आवश्यकता नहीं है, और सब कुछ स्वचालित रूप से होता है, और अपडेट सर्वर के भीतर चले जाते हैं ... आपको बस हर बार उपयोगकर्ता से एफ़टीपी एक्सेस सेटिंग्स का अनुरोध करना होगा, या उन्हें साइट पर वहीं स्टोर करना होगा ... अर्थात, सभी अंडे एक में टोकरी। इसलिए, मैंने एक और विकल्प चुना: उपयोगकर्ता खुद अपडेट डाउनलोड करता है (संग्रह के माध्यम से या svn के माध्यम से), उन्हें साइट पर अपलोड करता है, और साइट पर कोड, यह महसूस करते हुए कि वह "नया" है, डेटाबेस और / या सेटिंग्स के लिए आवश्यक सुधार करता है - लेकिन पहला विकल्प अभी भी था। और अधिक सुंदर ... लेकिन मेरी हिम्मत नहीं हुई।



ये मेरे "साइकिल निर्माण" के सबसे यादगार मील के पत्थर हैं। इसे पढ़ते हुए, मुझे बहुत पछतावा हुआ कि अपने काम की शुरुआत में मुझे ऐसा कुछ नहीं मिला, और मुझे खुद भी इतना अनुभव नहीं था कि मैं "सही" सवाल पूछ सकूँ। परिणामस्वरूप मुझे क्या मिला, आप यहां देख सकते हैं और यदि आपके कोई प्रश्न हैं, तो मैं उनका उत्तर देने के लिए तैयार हूं।



वैसे, अगर आपके पास अनुत्तरित प्रश्नों के उत्तर हैं, तो मैं उन्हें खुशी के साथ भी सुनूंगा। आखिरकार, अनुभव - यह ज्ञात है कि किसका बेटा है, और सभी गलतियों को अकेले करना लगभग असंभव है;)