जावास्क्रिप्ट प्रश्नों में मध्यस्थ पैटर्न

Question

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

इस तरह मैं मध्यस्थ पैटर्न में आया था। मैं कुछ है कि कुछ इस तरह काम करता है ऊपर लिखा है:

//Extend 
Core.extend('widget',function(params){ 
    alert(params.message); 
}); 

//Load it 
Core.load('widget',{message:'Hello World'}); 

//Remove it 
Core.remove('widget'); 

मैं यद्यपि 3 प्रश्न हैं:

1. कैसे करते/आप जावास्क्रिप्ट के साथ इस पैटर्न में डोम हेरफेर के साथ सौदा करना चाहिए? मैं नहीं चाहता कि डेवलपर्स अपने विजेट के बाहर डीओएम के साथ गड़बड़ कर रहे हों।

2. आप AJAX अनुरोधों से कैसे निपटें/चाहिए। क्या आपको कुछ भी करना चाहिए? क्या आपको लाइब्रेरी में AJAX/JSONP कॉल की पेशकश करनी चाहिए (इस उदाहरण में Core)।

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

=== अद्यतन ===

मैं इस लेखन समाप्त हो गया:

http://oscargodson.github.com/Core.js/

Answer 1

विजेट विगेट्स के साथ बातचीत: मैं सिर्फ इस निर्माण कुछ दिन पहले समाप्त हो गया। मैंने जिस तरीके से इसे कार्यान्वित किया है, उसके माध्यम से देखा, और यहां आपके लिए कुछ अतिरिक्त विचार हैं।

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

उदाहरण के लिए विचार करें यदि वेब पेज पर प्रत्येक यूआई तत्व आपके सिस्टम में एक विजेट था। एक पृष्ठ पर आसानी से 30+ होगा। यदि प्रत्येक व्यक्ति "लोड" संदेश को धक्का देना था, तो अन्य 29 को इसे प्राप्त करना होगा। इसके अलावा, जैसा कि आपने बताया है, तीसरे पक्ष के डेवलपर इस प्रणाली के लिए विकासशील होंगे। इसके बाद वे उन संदेशों को फ़िल्टर करने के लिए बोझ डालते हैं जिन्हें वे प्राप्त नहीं करना चाहते हैं।

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

तो उदाहरण के लिए आईडी 45 के साथ एक विजेट टाइप करें, "ट्वीट-लिस्ट" टाइप करें, वास्तविक "कस्टम" में एक संदेश "लोड" हो जाता है। पब स्ट्रिंग तब प्रस्तुत करेगी: custom.tweet-list.45.loaded।

जब सदस्यताएं रखी जाती हैं तो उन्हें एक हैश तालिका के माध्यम से इनपुट किया जाता है जो वैकल्पिक रूप से 4 विशेषताओं के लिए मान रख सकता है (आप आसानी से दायरे/प्रकार/आईडी/संदेश के अलावा और अधिक जोड़ सकते हैं)। सुनना तो होगा जैसे:

custom\.whatever\.[^\.]+\.[^\.]+:

listen({ realm: 'custom', type: 'whatever' }, f); // (where 'f' is a function)

अपने ढांचे के श्रोता भाग एक "स्ट्रिंग" जो एक नियमित रूप से फिल्टर व्यक्त अभिव्यक्ति है जिसके लिए यह प्रतिनिधित्व करता होगा कि हैश तालिका बदल सकती है

कि regex कुछ छिपा सरणी के लिए एक संकलित नियमित अभिव्यक्ति के रूप में संग्रहीत किया जाता है ...

__subscriptions.push(new RegExp(subString));

तब जब भी कुछ धक्का दिया गया था (यानी। प्रकाशित) ढांचे मूल रूप से __ सदस्यता शिर्षक के माध्यम से loops, प्रत्येक संग्रहित subString (regex) के .test से आग लगती है और अगर मिलान करता है तो उस सबस्ट्रिंग के लिए कॉलबैक निष्पादित करता है।

इस प्रणाली का उपयोग करते हुए असीमित फ़िल्टर किया श्रोताओं लागू किया जा सकता है और श्रोताओं जानते हैं कि वे केवल संदर्भों वे में रुचि रखते हैं के लिए सूचनाएं प्राप्त हो रही

उदाहरण:।

// Listen for all messages by widget ID #99 
listen({ id: 99 } ,f); 

// Listen for all messages by widgets in realm clientB 
listen({ realm: 'clientB' }, f); 

// Listen for the data-received push of widgets whose type is tweet-list 
listen({ type: 'tweet-list', message: 'data-received' }, f); 

क्योंकि regex वास्तव में सिर्फ एक है concatenation, regex भी फ़िल्टर के भीतर शामिल किया जा सकता है।

// Listen for any data- message 
listen({ message: 'data-[^\.]+' }, f); 

इस प्रणाली का सौंदर्य है कि आप अभी भी अपने वर्तमान इंटरफ़ेस रख सकता है "बात रखने के सरल" और बस एक स्ट्रिंग या argument[0] के लिए एक हैश तालिका के लिए परीक्षण है। दूसरे शब्दों में ..

// This 
listen('loaded', f); 

// Could be equivalent to this on the backend: 
listen({ message: 'loaded' }, f); 

मुझे पता है कि यह लंबा था लेकिन उम्मीद है कि यह आपको कुछ विचार देगा।