ExtJS 5 में ViewController का उपयोग करना

ExtJS 5 कुछ रोमांचक वास्तुकला सुधार लाता है: हमने MVC अनुप्रयोगों को बढ़ाने के लिए ViewModels, MVVM, और ViewControllers के लिए समर्थन जोड़ा है। सबसे अच्छी बात यह है कि ये फ़ंक्शन पारस्परिक रूप से अनन्य नहीं हैं, इसलिए आप उन्हें चरण दर चरण दर्ज कर सकते हैं या एक साथ उनका उपयोग कर सकते हैं।

नियंत्रकों के बारे में

ExtJS 4 में, एक नियंत्रक Ext.app.Controller



से विरासत में मिला एक वर्ग है। ये नियंत्रक घटकों और उनके घटना संचालकों को मैप करने के लिए सीएसएस जैसे चयनकर्ताओं ("घटक क्वेरी") का उपयोग करते हैं। वे तथाकथित refs



का उपयोग घटकों को लाने और प्राप्त करने के लिए भी करते हैं।



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

जटिलता

बड़े अनुप्रयोगों के लिए, ये तकनीकें कुछ कठिनाइयों को वहन कर सकती हैं।



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

ViewControllers

यह देखते हुए कि एक्सट जेएस 5 वर्तमान नियंत्रकों के साथ पिछड़ा हुआ है, यह इस तरह की समस्याओं को हल करने के लिए डिज़ाइन किए गए नए प्रकार के नियंत्रक प्रदान करता है: Ext.app.ViewController



। समाधान निम्नानुसार प्राप्त किया जाता है:

• listeners
  
  
  
  और reference
  
  
  
  विन्यास गुणों का reference
  
  
  
  , विचारों के साथ संचार सरल किया जाता है।
• ViewControllers को स्वचालित रूप से नियंत्रित करने के लिए दृश्य जीवनचक्र का उपयोग किया जाता है।
• ViewControllers की जटिलता को कम किया जाता है एक-से-एक संबंध इसी प्रतिनिधित्व के साथ प्रयोग किया जाता है।
• नेस्टेड विचारों को बनाने की क्षमता के लिए एनकैप्सुलेशन प्रदान किया जाता है।
• घटकों का चयन करना और उनकी घटनाओं को संबंधित दृश्य के नीचे किसी भी स्तर पर ट्रैक करना संभव है।

श्रोता (श्रोता)

listeners



नया नहीं है, लेकिन एक्सटी जेएस 5 में इसे नई सुविधाएँ मिलीं। नए श्रोताओं की एक और पूरी चर्चा आगामी लेख में होगी - "एक्सटी 5 जेएस में घोषणात्मक श्रोता"। ViewControllers में उपयोग के लिए हम कुछ उदाहरण देख सकते हैं। पहले एक नेस्टेड व्यू घटक में listeners



का सामान्य उपयोग है:

 Ext.define('MyApp.view.foo.Foo', { extend: 'Ext.panel.Panel', xtype: 'foo', controller: 'foo', items: [{ xtype: 'textfield', fieldLabel: 'Bar', listeners: { change: 'onBarChange' //    (scope) } }] }); Ext.define('MyApp.view.foo.FooController', { extend: 'Ext.app.ViewController', alias: 'controller.foo', onBarChange: function (barTextField) { //     'change' } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस मामले में, onBarChange



नाम के onBarChange



पास कोई विशिष्ट scope



नहीं है। Bar



टेक्स्ट फ़ील्ड के लिए ईवेंट सिस्टम अपने स्वयं के ViewController को डिफ़ॉल्ट संदर्भ बनाता है।



ऐतिहासिक रूप से, listeners



विन्यास को मूल घटक द्वारा उपयोग के लिए आरक्षित किया गया है, इसलिए, यह सवाल उठता है: कोई दृश्य अपनी स्वयं की घटनाओं को कैसे सुन सकता है या शायद उन लोगों को भी जो बेस क्लास द्वारा बुलाए गए थे? इसका उत्तर स्पष्ट संदर्भ का उपयोग करना होगा:

 Ext.define('MyApp.view.foo.Foo', { extend: 'Ext.panel.Panel', xtype: 'foo', controller: 'foo', listeners: { collapse: 'onCollapse', scope: 'controller' }, items: [{ ... }] });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस उदाहरण में एक्सटीजेएस 5 में दो नई सुविधाओं का उपयोग किया गया है: स्कोप्स और घोषित श्रोता (लगभग। ट्रांसलेशन। )। हम नामित संदर्भ पर ध्यान केंद्रित करेंगे। नामित संदर्भों के लिए, दो नाम मान्य हैं: "this"



और "controller"



। जब हम एमवीसी एप्लिकेशन लिखते हैं, तो हम लगभग हमेशा एक "controller"



उपयोग करते हैं, जो स्पष्ट रूप से हमारा अपना व्यू कॉन्ट्रोलर होगा (और व्यूस्ट्रीम के व्यू- "controller"



नहीं है)।



क्योंकि Ext.Component



दृश्य Ext.Component



। हमने इस दृश्य xtype



असाइन किया है, जो अन्य दृश्यों को उसी तरह से xtype



अनुमति देता है, xtype



हमने xtype



साथ किया था। यह देखने के लिए कि सब कुछ एक साथ कैसे फिट बैठता है, एक पदानुक्रम बनाएं:

 Ext.define('MyApp.view.bar.Bar', { extend: 'Ext.panel.Panel', xtype: 'bar', controller: 'bar', items: [{ xtype: 'foo', listeners: { collapse: 'onCollapse' } }] });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस मामले में, Bar



दृश्य Foo



का एक उदाहरण अपने तत्वों में से एक बनाता है। यह तब Foo



दृश्य के रूप में उसी तरह से collapse



घटना को सुनता है। Ext JS और Sencha Touch के पिछले संस्करणों में, इन परिभाषाओं में संघर्ष होगा। हालाँकि, इसे एक्सट जेएस 5 में हल किया गया है: Foo



में घोषित श्रोता व्यूकंट्रोलर Foo



में काम करेंगे, और Bar



- व्यूकंट्रोलर Bar



में घोषित किए जाएंगे।

संदर्भ (संदर्भ)

नियंत्रक तर्क में व्यापक रूप से उपयोग किए जाने वाले कार्यों में से एक कार्य करने के लिए आवश्यक घटक प्राप्त करना है। कुछ इस तरह:

 Ext.define('MyApp.view.foo.Foo', { extend: 'Ext.panel.Panel', xtype: 'foo', controller: 'foo', tbar: [{ xtype: 'button', text: 'Add', handler: 'onAdd' }], items: [{ xtype: 'grid', ... }] }); Ext.define('MyApp.view.foo.FooController', { extend: 'Ext.app.ViewController', alias: 'controller.foo', onAdd: function () { // ...  grid    ... } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लेकिन हम टेबल (गर्ड) कैसे प्राप्त करते हैं? ExtJS 4 में, आप घटक को प्राप्त करने के लिए कॉन्फिग refs



या किसी अन्य तरीके का उपयोग कर सकते हैं। सभी तकनीकों को विशिष्ट पहचान के लिए आपको एक तालिका में एक पहचानने योग्य संपत्ति देने की आवश्यकता है। पुराने तकनीशियनों ने id



(और Ext.getCmp



) Ext.getCmp



या Ext.getCmp



( Ext.getCmp



या किसी अन्य चयन विधि का उपयोग करके) का उपयोग किया। id



का लाभ शीघ्र प्राप्त होता है, लेकिन क्योंकि पहचानकर्ता पूरे एप्लिकेशन में और DOM में अद्वितीय होना चाहिए, यह हमेशा प्राप्त करने योग्य नहीं होता है। itemId



और विभिन्न प्रकार के प्रश्नों (क्वेरी) का उपयोग करना अधिक लचीला है, लेकिन आपको सही घटक खोजने के लिए खोज करने की आवश्यकता है।



lookupReference



जेएस 5 में नए reference



विन्यास के साथ, हम इसे केवल तालिका में जोड़ते हैं और इसे प्राप्त करने के लिए lookupReference



का उपयोग करें:

 Ext.define('MyApp.view.foo.Foo', { extend: 'Ext.panel.Panel', xtype: 'foo', controller: 'foo', tbar: [{ xtype: 'button', text: 'Add', handler: 'onAdd' }], items: [{ xtype: 'grid', reference: 'fooGrid' ... }] }); Ext.define('MyApp.view.foo.FooController', { extend: 'Ext.app.ViewController', alias: 'controller.foo', onAdd: function () { var grid = this.lookupReference('fooGrid'); } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह itemId = 'fooGrid'



और फिर this.down('#fooGrid')



असाइन करने के समान है। लेकिन "हुड के तहत" अंतर महत्वपूर्ण है। सबसे पहले, reference



कॉन्फ़िगरेशन को स्वामी दृश्य में खुद को पंजीकृत करने के लिए घटक की आवश्यकता होती है। दूसरे, lookupReference



विधि कैश को अपडेट करने की आवश्यकता के बारे में पूछती है (कंटेनर में जोड़ या हटाने के कारण मान लीजिए)। यदि सब कुछ ठीक है, तो यह कैश से लिंक लौटाता है। छद्म कोड में:

 lookupReference: (reference) { var cache = this.references; if (!cache) { Ext.fixReferences(); //   cache = this.references; //    } return cache[reference]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

कैप्सूलीकरण

एक्सटी जेएस 4 एमवीसी कार्यान्वयन में चयनकर्ताओं का उपयोग करना बहुत लचीला था, लेकिन साथ ही साथ इसने कुछ जोखिम भी उठाए। यह तथ्य कि चयनकर्ताओं ने सभी स्तरों पर सभी घटनाओं को "देखा" शक्तिशाली था, लेकिन त्रुटियों के कारण। उदाहरण के लिए, अलगाव में 100% त्रुटि मुक्त काम करने वाला एक नियंत्रक त्रुटियों को पैदा कर सकता है जैसे ही नए विचार अवांछित मिलानकर्ताओं के साथ दिखाई देते हैं।



यह कुछ प्रथाओं का पालन करके हल किया जा सकता है, लेकिन ViewControllers में श्रोताओं और लिंक का उपयोग करके इन समस्याओं को आसानी से समाप्त कर दिया जाता है। और सभी क्योंकि reference



और listeners



विन्यास को केवल अपने ViewController के साथ कनेक्ट करते हैं। नेस्टेड विचार वर्तमान एक के अंदर किसी भी reference



मूल्य का उपयोग कर सकते हैं, यह जानते हुए कि ये नाम उच्च पदानुक्रम के दृश्य के लिए खुले नहीं होंगे।



उसी समय, listeners



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



इस उदाहरण को पूरा करने के लिए, उस मामले पर विचार करें जहां एक दृश्य एक घटना को बढ़ा सकता है जिसे उच्च-स्तरीय दृश्य के ViewController द्वारा नियंत्रित किया जाएगा। ऐसा करने के लिए, ViewController में एक सहायक विधि है: fireViewEvent



। उदाहरण के लिए:

 Ext.define('MyApp.view.foo.Foo', { extend: 'Ext.panel.Panel', xtype: 'foo', controller: 'foo', tbar: [{ xtype: 'button', text: 'Add', handler: 'onAdd' }], items: [{ xtype: 'grid', reference: 'fooGrid' ... }] }); Ext.define('MyApp.view.foo.FooController', { extend: 'Ext.app.ViewController', alias: 'controller.foo', onAdd: function () { var record = new MyApp.model.Thing(); var grid = this.lookupReference('fooGrid'); grid.store.add(record); this.fireViewEvent('addrecord', this, record); } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह पदानुक्रम को उच्चतर दृश्य में एक मानक श्रोता का उपयोग करना संभव बनाता है:

 Ext.define('MyApp.view.bar.Bar', { extend: 'Ext.panel.Panel', xtype: 'bar', controller: 'bar', items: [{ xtype: 'foo', listeners: { collapse: 'onCollapse', addrecord: 'onAddRecord' } }] });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अनुवादक से: यह भ्रामक लगता है, लेकिन संक्षेप में fireViewEvent



अंदर एक दृश्य के लिए एक घटना को बढ़ाने की अनुमति देता है। यही है, अगर इस मामले में कोई ViewControllers नहीं थे, तो यह "फू" दृश्य कोड में सामान्य fireEvent



कॉल को कॉल करने के लिए fireEvent



होगा।

श्रोता और ईवेंट डोमेन

Ext JS 4.2 में, इवेंट डोमेन MVC इवेंट मैनेजर में पेश किए गए थे। ये डोमेन कॉल करते ही घटनाओं को रोक देते हैं और चयनकर्ताओं के संयोग से उन्हें संसाधित करने वाले नियंत्रकों के पास भेज देते हैं। component



ईवेंट डोमेन में घटक चयनकर्ताओं के लिए पूर्ण समर्थन है, जबकि अन्य के पास सीमित समर्थन है।



Ext JS 5 में, प्रत्येक ViewController एक नए प्रकार के इवेंट डोमेन का एक उदाहरण बनाता है जिसे view



कहा जाता view



। यह इवेंट डोमेन ViewControllers को मानक श्रवण और control



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

 Ext.define('MyApp.view.foo.FooController', { extend: 'Ext.app.ViewController', alias: 'controller.foo', control: { '#': { //     collapse: 'onCollapse' }, button: { click: 'onAnyButtonClick' } } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

श्रोताओं और चयनकर्ताओं के बीच महत्वपूर्ण अंतर निम्नलिखित उदाहरण में देखा जा सकता है। button



चयनकर्ता इस दृश्य में या किसी भी उप-बटन में किसी भी बटन से मेल खाता है, इससे कोई फर्क नहीं पड़ता है, कम से कम उप-उप-उप में। दूसरे शब्दों में, चयनकर्ता-आधारित हैंडलर विरासत की सीमाओं को नहीं मानते हैं। यह व्यवहार पिछले Ext.app.Controller



के व्यवहार के Ext.app.Controller



और कुछ स्थितियों में एक उपयोगी तकनीक हो सकती है।



अंत में, ये डोमेन नेस्टिंग को ध्यान में रखते हैं और प्रभावी ढंग से घटना को अभ्यावेदन के पदानुक्रम को आगे बढ़ाते हैं ( एक घटना को ऊपर - - लगभग अनुवाद। )। यही है, जब किसी घटना को ट्रिगर किया जाता है, तो इसे पहले मानक श्रोताओं को दिया जाता है। फिर इसे मालिक ViewController को पास कर दिया जाता है, और उसके बाद माता-पिता ViewController (यदि कोई हो) को पदानुक्रम दिया जाता है। अंततः, Ext.app.Controller



नियंत्रकों में प्रसंस्करण के लिए मानक component



ईवेंट डोमेन को इवेंट Ext.app.Controller



जाता है।

जीवन चक्र

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



इसलिए, दृश्य के जीवन चक्र में, ViewController तुरंत बनाया जाता है और यह पूरे जीवन में इस दृश्य से जुड़ा हुआ है। जब दृश्य हटा दिया जाता है, तो ViewController भी करता है। इसका मतलब यह है कि जब कोई दृश्य या कई दृश्य नहीं होते हैं ( जहाँ अब कोई दृश्य या कई दृश्य नहीं हैं, - जाहिर तौर पर, शास्त्रीय नियंत्रकों के साथ तुलना है; लगभग। )



एक-से-एक संबंध लिंक ट्रैकिंग को सरल करता है और दूरस्थ घटकों को लीक करना असंभव बनाता है। निम्न मुख्य घटनाएँ ViewController जीवनचक्र में उठाई जाती हैं:

• इससे पहले कि यह एक विधि है जिसे प्रस्तुति को नियंत्रित करने से पहले इसे नियंत्रित करने से रोक दिया जा सकता है क्योंकि यह initComponent विधि को कॉल करती है। नियंत्रक बनाने के तुरंत बाद कॉल किया जाता है, जब घटक initConfig
  
  
  
  या इसके निर्माता को initConfig
  
  
  
  किया जाता है।
• init - initComponent
  
  
  
  में initComponent
  
  
  
  विधि पूर्ण होने के तुरंत बाद कहा जाता है। यह एक नियंत्रक को प्रारंभिक करने के लिए एक विशिष्ट बिंदु है जिसकी प्रस्तुति पहले से ही आरंभिक है।
• initViewModel - जब व्यू व्यूकोड बनाया गया था (यदि कोई परिभाषित किया गया है) कहा जाता है।
• नष्ट - किसी भी संसाधनों की सफाई ( callParent
  
  
  
  को कॉल करना न भूलें)।

निष्कर्ष

हमें लगता है कि ViewControllers आपके एप्लिकेशन को अपग्रेड करने में महान हैं। वे ViewModels के साथ भी अच्छी तरह से काम करते हैं, इसलिए आप दोनों तरीकों की ताकत को जोड़ सकते हैं। हम आगामी रिलीज से प्रसन्न हैं और आपके अनुप्रयोगों में सुधार का भी स्वागत करेंगे।

पुनश्च

पिछला पोस्ट: एक्सट जेएस 5: एमवीसी, एमवीवीएम, आदि।