🤽🏿 🦉 👨🏽‍🚒 ExtJS 2.x / 3.x में एप्लिकेशन लिखने के सिद्धांत ◽️ 🗄️ ↙️

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

DOM आईडी पर टाइट बाइंडिंग से मना करें

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

हमेशा घटकों को अलग और अलग करना

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

var p = new Ext.Panel({ region: 'north', height: 30, html: '<b>Test</b>' }); var mainPanel = new Ext.Panel({ layout: 'border', items: [ p, { region: 'center' title: 'Center' } ] });

बहुत जल्दी, ऐसा कोड एक गड़बड़ में बदल जाएगा, जिसे इसके निर्माता भी नहीं समझेंगे। इसके अलावा, कोड में ऐसे तत्वों के बीच निर्भरता की वृद्धि व्यावहारिक रूप से नियंत्रित नहीं है।

नेस्टेड कॉन्फिग ऑब्जेक्ट: स्कोप याद रखें

यह मत भूलो कि जेएस में किसी भी समारोह को किसी भी वस्तु की ओर से बुलाया जा सकता है। दूसरे शब्दों में, this एक फ़ंक्शन के अंदर आम तौर पर कहीं भी बोलने का संकेत दे सकता है। उन मामलों में जहां हम स्वयं फ़ंक्शन को कॉल करते हैं, हम इस स्थिति को सिंथेटिक रूप से नियंत्रित कर सकते हैं। ऐसे मामलों में जहां कॉन्फ़िगरेशन ऑब्जेक्ट में घोंसले के शिकार के विभिन्न स्तरों पर फ़ंक्शन (इवेंट हैंडलर) होते हैं, उनके लिए गुंजाइश की समस्या स्पष्ट हो जाती है। ज्यादातर मामलों में, this हैंडलर के तर्क के लिए एक प्रकार का "संदर्भ बिंदु" है। इसे खो this - और यह पूरी तरह से समझ में नहीं आता है कि इसे कैसे छिपाएं / अक्षम करें, आदि, के लिए अगले बटन पर जाएं।
जावास्क्रिप्ट भाषा फ़ंक्शन ऑब्जेक्ट के कम से कम निम्नलिखित तरीके प्रदान करती है: लागू () और कॉल () [2] ।
ExtJS कोर createDelegate(scope) विधि के साथ फंक्शन प्रोटोटाइप को पूरक करता है। यह फ़ंक्शन मूल के चारों ओर एक आवरण फ़ंक्शन देता है, ताकि आपके मूल फ़ंक्शन को स्कोप में बुलाया जाए।
श्रोताओं और एक्सटीजेएस पुनरावृत्तियों के लिए, आप हमेशा स्पष्ट रूप से निर्धारित कर सकते हैं कि निर्दिष्ट फ़ंक्शन को किस दायरे में कहा जाना चाहिए [3] ।

नेस्टेड घटकों तक पहुँचना

नेस्टेड घटक हमेशा स्वामी के आइटम संग्रह में स्थित होते हैं। बच्चे को पाने के लिए कम से कम तीन विकल्प हैं:

अनुक्रमणिका द्वारा संग्रह आइटम तक पहुँचना
- गैर-स्पष्ट कोड; फार्म के उग्र निर्माण इसे वापस लौटाते हैं। (0) .get (3) या इससे भी बदतर वापसी। items.items [[0] ।items.items [3]
- वस्तुओं में घटकों का क्रम बदल गया है - सब कुछ टूट गया है
- दस्तावेज़ के DOM में माता-पिता को चित्रित करने से पहले आइटम केवल एक सरणी है (नीचे देखें)।
ItemId द्वारा संग्रह आइटम एक्सेस करना। यह पहचानकर्ता डोम आईडी से बंधा नहीं है, लेकिन आपको तत्व को कॉल को अधिक सार्थक बनाने की अनुमति देता है। इसके अलावा, यह विधि उस आदेश पर निर्भर नहीं करती है जिसमें घटक माता-पिता में घोषित किए जाते हैं।
रेफरी के माध्यम से अपील। Ref यह निर्दिष्ट करने का एक तरीका है कि किसी दिए गए तत्व का लिंक कैसे बनाया जाएगा, जब इसे बनाया जाएगा, और यह लिंक किस स्तर पर रखा जाएगा।

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

Ref और itemId का उपयोग करने का एक उदाहरण निम्नलिखित उदाहरण में देखा जा सकता है:

 Ext.ns('Util'); Util.MyPanel = Ext.extend(Ext.Panel, { constructor: function (config) { config = config || {}; Ext.apply(config, { border: false, layout: 'card', activeItem: 0, items: [{ xtype: 'panel', itemId: 'mainScreen', layout: 'border', items: [{ //...skipped... } ] }, { xtype: 'editpanel', itemId: 'editScreen', listeners: { scope: this, cancel: this.showMainScreen, finish: this.onRuleSaved } } ], buttons: [{ ref: '../editBtn', handler: this.onEditBtn, scope: this }] } ); Util.MyPanel.superclass.constructor.call(this, config); }, showMainScreen: function () { this.getLayout().setActiveItem('mainScreen'); this.editBtn.enable(); }, showEditScreen: function () { this.getLayout().setActiveItem('editScreen'); }, //... other methods } ); Ext.reg('mypanel', Util.MyPanel);

अपनी खुद की घटनाओं को पंजीकृत करें

ExtJS में घटनाएँ - विगेट्स के संपर्क के लिए मुख्य तंत्र। यह एक घटक के लिए अपनी स्थिति की बाहरी दुनिया को सूचित करने का एक तरीका है। प्रत्येक विजेट अन्य लोगों की घटनाओं का श्रोता हो सकता है, साथ ही साथ स्वयं का स्रोत भी हो सकता है। इस मामले में, घटक में श्रोताओं की एक मनमानी संख्या हो सकती है, उन सभी को घटना के बारे में सूचित किया जाएगा। सामान्य तौर पर, छात्रों को सूचित करने की प्रक्रिया को परिभाषित नहीं किया गया है।
ईवेंट प्राप्तकर्ताओं और उनकी संख्या के बारे में न्यूनतम अनुमान लगाते हैं, जो कोड की सुसंगतता को कम करता है। और यह बदले में, घटक को पोर्टेबल बनाता है और इसे अन्य संयोजनों में पुन: उपयोग करना संभव बनाता है।
यदि आपके कंपोनेंट में एक स्थिति है कि बाहर से आने वाली वस्तुओं के बारे में जानना चाहते हैं, तो अपने स्वयं के ईवेंट को पंजीकृत करें।
यदि आप एक समग्र विजेट बना रहे हैं और आंतरिक घटक को बाहरी को कुछ बताना होगा - अपनी स्वयं की घटना का उपयोग करें।

प्रतिपादन से पहले और बाद में वस्तु। जब afterrender की जरूरत है

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

  //...other property definitions... showDocFeedOptions: function (show) { var fn = function () { this.feedDocsFieldSet.setVisible(!!show); }; if (this.rendered) { fn.apply(this); } else { this.on('afterrender', fn, this); } }

आलसी आरंभीकरण। Xtype

Xtype कॉन्फ़िगरेशन ऑब्जेक्ट की मैजिक प्रॉपर्टी (एक और "ट्रिक") विशिष्ट रूप से निर्मित की जा रही वस्तु के प्रकार को निर्धारित करती है। इसका मतलब है कि अगर हम Ext.ComponentMgr.create () सार्वभौमिक कारखाने के लिए इस तरह के कॉन्फ़िगरेशन ऑब्जेक्ट को पास करते हैं (और इसे प्रत्येक नेस्टेड कॉन्फ़िग ऑब्जेक्ट के लिए स्वचालित रूप से कहा जाता है), तो हमें आउटपुट पर संबंधित वर्ग का एक उदाहरण मिलता है।
यह दृष्टिकोण इसे संभव बनाता है:

नेस्टेड कॉन्फ़िगरेशन ऑब्जेक्ट बनाएँ जिसमें विजेट संरचना दिखाई दे रही है
मैन्युअल रूप से ऑब्जेक्ट बनाने और उन्हें देर से कंटेनर में जोड़ने के अनुक्रम से बचें
आवश्यकतानुसार घटक बनाएं (जो बदले में आपके आवेदन की प्रतिपादन गति को बढ़ाएगा)

निष्कर्ष के बजाय - डिजाइनिंग के बारे में थोड़ा

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

एक बाहरी घटक (इसे "माता-पिता" कहते हैं) नेस्टेड (बच्चे) तत्वों के बारे में जानता है। आक्षेप सत्य नहीं है।
एक अभिभावक सीधे बच्चों तक पहुंच सकता है।
बाल तत्व घटनाओं के तंत्र के माध्यम से केवल "अप" की सूचना देते हैं। बच्चे को माता-पिता और उसके तरीकों के सेट के बारे में कोई धारणा नहीं बनानी चाहिए।
बच्चों के बीच "क्षैतिज" रिश्ते (सीधे एक-दूसरे को कॉल करते हैं) सख्त वर्जित हैं। केवल माता-पिता "बेटियों" के सिंक्रनाइज़ेशन में लगे हुए हैं।
लगातार DOM आईडी (Ext.getCmp ()) के माध्यम से कॉल करना सख्त वर्जित है।

ExtJS 2.x / 3.x में एप्लिकेशन लिखने के सिद्धांत