पर्यवेक्षक का जुर्माना, लेकिन आपको बुनियादी पैटर्न से आगे जाने पर विचार करना होगा। कैनोलिक ऑब्जर्वर/विषय पैटर्न केवल विषय वस्तु को पर्यवेक्षक को भेजता है, और कुछ भी नहीं, क्यों यह अधिसूचित किया जा रहा है।
प्रारंभ में, समाधान पर्यवेक्षक को अधिसूचना के कारण सहित भी प्रतीत हो सकता है, लेकिन फिर आप उन पर्यवेक्षकों को सूचित कर सकते हैं जो कुछ अधिसूचनाओं की परवाह नहीं करते हैं। एक बेहतर समाधान के लिए पर्यवेक्षकों को उन सूचनाओं की एक सूची मांगने की आवश्यकता हो सकती है, जिन्हें वे प्राप्त करना चाहते हैं।
लेकिन यह भी एक समस्या प्रस्तुत करता है। पर्यवेक्षकों को वास्तव में विषयों पर खुद को संलग्न करने के लिए, उन्हें तत्काल होना होगा। हर बार। भले ही उन्हें कभी आवश्यकता न हो। यह मूर्खतापूर्ण है।
तो, हम प्लगइन के कैननिकल PHP कार्यान्वयन में से एक में तेजी से पहुंचे हैं: "हुक"। हुक ऑब्जेर्वर/विषय के रूप में एक ही अवधारणा का उपयोग करते हैं, लेकिन कार्यान्वयन एक बहुत ही महत्वपूर्ण तरीके से भिन्न होता है: वास्तविक पर्यवेक्षकों को विषयों का निरीक्षण करने के लिए तत्काल नहीं किया जाता है। इसके बजाय, विषय कुछ प्रकार के केंद्रीय भंडार में अधिसूचना भेजते हैं। यह भंडार सभी की सूची के साथ कॉन्फ़िगर किया गया है और प्लगइन्स (पर्यवेक्षकों) को सक्रिय किया गया है, और प्रत्येक प्लगइन प्राप्त करने वाली सभी घटनाओं की एक सूची है। प्रत्येक प्लगइन और केवल घटना के दौरान अधिसूचित किया जाता है, अक्सर प्लगइन का उदाहरण बनाकर और इसे सूचित करते हुए एक स्थिर विधि के माध्यम से। call_user_func_array और एक अच्छा ऑटोलोडर इस अविश्वसनीय रूप से तुच्छ बनाता है।
इसलिए आप सभी प्लगइन को लागू करने के लिए एक सरल इंटरफ़ेस बना सकते हैं। जिन तरीकों की आपको आवश्यकता होगी उनमें शामिल हैं लेकिन इन तक सीमित नहीं हैं:
- प्लगइन, जैसे कि इसका नाम, लेखक, आधिकारिक वेबसाइट, संस्करण इत्यादि के बारे में डेटा लाने के लिए कुछ मानव उपभोग्य जानकारी।
- प्लगइन की सदस्यता लेने वाली घटनाओं को वापस करने का एक तरीका।
- एक इंस्टॉलेशन विधि, जो प्लगइन को खुद को स्थापित करने के लिए करने की आवश्यकता होती है, जैसे डाटाबेस में हेरफेर करना।
- एक अनइंस्टॉलेशन विधि भी आसान हो सकती है।
- (संभवतः स्थिर) विधि जो घटना अधिसूचनाएं प्राप्त करेगी और जो भी डेटा आवश्यक है उसे वापस कर देगा।
प्लगइन अवधारणा को आप कितनी दूर लेते हैं, इस पर निर्भर करते हुए, आप प्लगइन के साथ समाप्त हो सकते हैं जिसमें उपयोगकर्ता कॉन्फ़िगर करने योग्य विकल्प हैं। आपको इसे ध्यान में रखना पड़ सकता है। नीचे वह सड़क पागलपन और विन्यास प्रणाली है।
आदेश प्लगइन्स प्रभावी बनाने के लिए, आप हुक जगह हर जगह जरूरत के लिए, और अक्सर नए हुक, जहां वे की जरूरत है जोड़ने के लिए अंत उपयोगकर्ताओं के साथ काम जा रहे हैं।
विजेट आसानी से उसी तरह काम कर सकते हैं, जैसे कि पृष्ठ प्रतिपादन से पहले जिन्हें प्लगइन कहा जाता है।
थीम्स/टेम्पलेट्स, ओह मेरे। आपके पास शायद दो बड़े विकल्प हैं।
- Smarty, या एक समान टेम्पलेट इंजन। या आपका स्वयं का PHP-PHP टेम्पलेट इंजन नहीं है।
- PHP टेम्पलेट्स।
यह निर्णय आपके अंतिम उपयोगकर्ताओं द्वारा संचालित किया जाएगा। Smarty अविश्वसनीय रूप से सीमित है, लेकिन यदि आप यह सुनिश्चित करना चाहते हैं कि केवल टेम्पलेट में स्वीकृत कोड ही चलता है, तो यह एक व्यवहार्य विकल्प हो सकता है। इसके अलावा, एप्लिकेशन में स्वयं Smarty टेम्पलेट्स के संपादन की अनुमति देने के लिए असुरक्षित नहीं है।
दूसरी तरफ, वर्डप्रेस टेम्पलेट्स इतनी अच्छी तरह से काम करने का कारण यह है कि वे शुद्ध PHP हैं। वे वर्डप्रेस एपीआई में प्रकट किसी भी विधि को कॉल कर सकते हैं, और यहां तक कि अपने स्वयं के दिलचस्प तर्क भी कर सकते हैं। यदि आप उम्मीद करते हैं कि आपके अंतिम उपयोगकर्ता तकनीकी रूप से दिमाग में हों, या कम से कम तकनीकी रूप से सक्षम हों, तो PHP टेम्पलेट्स जाने का तरीका हैं। दूसरी तरफ, एप्लिकेशन के भीतर PHP टेम्पलेट्स के संपादन की इजाजत देकर एक संभावित संभावित सुरक्षा छेद खुल सकता है यदि कोई दुर्भावनापूर्ण उपयोगकर्ता व्यवस्थापक बिट्स में आता है। आप शायद फाइल सिस्टम में संपादन को प्रतिबंधित करना चाहते हैं।
हालांकि इसमें HTML निर्माण शामिल है, आपको सीएसएस को भी ध्यान में रखना चाहिए। क्या आपका अंतिम उपयोगकर्ता सीधे सीएसएस में हेरफेर कर पाएगा? क्या वे चाहते हैं? यदि आपके डिफ़ॉल्ट टेम्पलेट्स में पर्याप्त अर्थपूर्ण कक्षाएं शामिल हैं, तो वे शायद बहुत सारे प्रयासों के साथ स्टाइलिंग का एक बड़ा सौदा कर सकते हैं, अगर वे जानते हैं कि वे क्या कर रहे हैं। दूसरी तरफ, आपके एंड-यूजर को पता नहीं हो सकता कि सीएसएस क्या है, इसलिए वे चाहते हैं, ओह, कहें, कलर पिकर्स और प्री-बिल्ट कलर स्कीम, और एक रंग योजना चयनकर्ता, और अन्य ऐसी परेशान चीजें बनाने के लिए। अब उन भयावहताओं के बारे में सोचना सबसे अच्छा है।
विविध चीज़ें।
कोई सीएमएस ड्राफ्ट की अवधारणा के बिना पूरा नहीं होगा और राज्यों को प्रकाशित करेगा। मेरे पास आपके लिए कोई सलाह नहीं है, कोड के पहले यह पर कोड करें। यदि आपका ग्राहक या अंतिम उपयोगकर्ता किसी भी तरह का ऐतिहासिक संग्रह, प्रबंधकीय अनुमोदन तंत्र, या कुछ भी जो ड्राफ्ट/प्रकाशित कुछ भी एक साधारण राज्य क्षेत्र चाहता है, तो आपको बहुत जल्द पता होना चाहिए। (मुझे इस से बहुत परेशान किया गया है।हमने पूरे सिस्टम को एक साधारण प्रकाशित/प्रकाशित प्रकाशित मॉडल के आसपास डिज़ाइन नहीं किया था, और लगभग 9/10 वें स्थान पर स्पेक बिल्डिंग और संबंधित प्रोटोटाइप कोड के माध्यम से मिला जब हमें एहसास हुआ कि यह काम नहीं करेगा और हमें कुछ और करना होगा, और भी वास्तव में ग्राहक आवश्यकताओं को पूरा करने के लिए जटिल। किसी न किसी योजना को पुनर्निर्माण करना अब तक का सबसे बड़ा समय-सिंक था।)
क्या आप ओआरएम का उपयोग करेंगे? यदि नहीं, तो उचित डेटाबेस इंटरफ़ेस लाइब्रेरी का उपयोग करना सुनिश्चित करें। पीडीओ, या शायद पियर से कुछ, या शायद Zend_Db। आपके पास अनिवार्य रूप से एक ग्राहक होगा जो जोर देगा कि कोड ओरेकल या एमएसएसक्यूएल पर चलता है। या SQLite। यह बताना अच्छा होगा कि यह किया जा सकता है (कुछ प्रयासों के साथ)। प्लगइन लेखक भी सैनिटी के लिए धन्यवाद देंगे। अपने आप को रोल करें।
(फिर फिर, आपके प्रतिनिधि स्तर के साथ, मुझे उम्मीद है कि आप जो कुछ भी कहा है उससे पहले से ही परिचित हैं। आह, कोडिंग समस्याओं के अपने सेट के बारे में सोचते समय मैं खुद को विचलित करने के लिए करता हूं .. ।)
उत्सुक ... किसी भी कारण से मौजूदा सीएमएस (जैसे ड्रूपल) को आप जो चाहते हैं उसे पूरा नहीं किया जा सकता है? – xenoterracide
@xenoterracide: अभिनेताओं और गायकों और मीडिया से इसी तरह की इकाइयों को लक्षित एक नई सीएमएस प्रणाली बनाने के लिए ग्राहक आवश्यकता है। – Sarfraz
http://journal.relativesanity.com/2008/11/17/how-not-to-build-an-in-house-cms/ –