लगातार बदलती आवश्यकताओं और तंग समय सीमा ने हमें एक प्रोटोटाइप बनाने के लिए एक्सटीजेएस 4 का उपयोग करने के लिए प्रेरित किया।

एक्सटीजेएस में समस्याओं का सामना करना पड़ा जो हमने विकास में सामना किया और एक्सटीजेएस की तैयारी में हमें जो अनुभव प्राप्त हुआ, वह मुश्किल से अधिक था।

इंटरनेट पर एक्सटीजेएस 4 लेवल बेसिक के बारे में कई लेख हैं। उदाहरण के लिए, यह लेख http://css.dzone.com/articles/how-use-extjs-4-jquery से बहुत प्रसन्न था। लेकिन ExtJS का उपयोग करके कुछ समस्याओं को हल करने (या बनाने) पर गंभीर "गैर-नकद" लेख कई नहीं हैं।

मेरा सुझाव है कि आप एक्सटीजेएस पैच लैब के ढांचे में पहला लेख सुनें ... खैर, सबसे सामाजिक के बारे में थोड़ा सा। नेटवर्क ... थोड़ा बहुत।



फ़ीड के लिए, Ext.dpan.SGore के साथ Ext.panel.Grid का उपयोग करने का निर्णय लिया गया। आप कह सकते हैं कि ये मूलभूत चीजें हैं, जिसके लिए उन्होंने एक्सटीजेएस का उपयोग करना चुना।

क्यों ग्रिड , और dataView नहीं (बाद में फाइनल को देखने के पक्ष में ग्रिड को छोड़ना पड़ा)। ग्रिड को डेटा को सॉर्ट करने और फ़िल्टर करने के लिए दृश्य मोड पसंद आया, "अंतहीन" स्क्रॉल। प्रदान किए गए अवसरों की खुशी बस भारी थी।

Ext.data.Store

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

var myStore = Ext.create('Ext.data.Store', { model: 'Post', filterOnLoad: true, idProperty: 'id', filters: new Ext.util.Filter({ filterFn: function (item) { return item.get("status") > 0; } }) }); … API.Events.get().done(function(posts){ myStore.loadData(posts); }); 

पोस्ट मॉडल Ext.data.Model वर्ग का वंशज है।

 Ext.define('Post', { extend: 'Ext.data.Model', idProperty: 'id', constructor: function (raw) { return this.callParent([this.prepare(raw), raw[this.idProperty]]); }, prepare: function (raw) { … } }); 

पोस्ट मॉडल में, तैयार विधि के माध्यम से कच्चा डेटा तैयार किया जाता है। मूल वर्ग के निर्माता में, डेटा पहले से ही संसाधित रूप में आता है।

तैयार विधि में क्या होता है:
उदाहरण के लिए, स्ट्रिंग से पोस्ट डेट ऑब्जेक्ट तक पोस्ट डेट डालना

 this.data = new Date(this.data); 

... टाइपआईडी से पत्राचार तालिका के हैश के माध्यम से पोस्ट नाम का स्ट्रिंग मान प्राप्त करना

 this.typeName = Dict.post.types[this.typeId]; 

और इसी तरह ...

स्टोर अपने आप में डेटा को इंस्टेंट मॉडल के रूप में संग्रहीत करता है, लोडडेटा विधि यह जांचती है कि क्या डेटा अभी भी कच्चा है, तो इसे मॉडल कंस्ट्रक्टर में स्थानांतरित करें, और इसे हमें लिखें, और इस तरह से सरणी के प्रत्येक तत्व के साथ।

सुखद उपयोगिता # 1

इस प्रकार, लोडडाटा कच्ची वस्तुओं की एक सरणी और पहले से ही तत्काल मॉडल दोनों को स्वीकार करता है।

फ़ीचर # 1

लोडडैटा में किसी एकल ऑब्जेक्ट को पास करते समय एक त्रुटि होगी, विधि केवल एक सरणी की अपेक्षा करती है, यहां तक ​​कि एक तत्व से भी।

फ़ीचर # 2

जावास्क्रिप्ट में वस्तुओं को संदर्भ द्वारा पारित किया जाता है, इसलिए लोड डेटा को हस्तांतरित किया जाने वाला कच्चा डेटा मॉडल का एक सरणी बन जाएगा।

 API.Events.get().done(function(posts){ //posts is array of objects myStore.loadData(posts); //posts is array of Models }); 

यदि आपको अपरिवर्तित लोड करने के बाद मूल डेटा की आवश्यकता है, तो Ext.Array.clone () विधि का उपयोग करें, लेकिन यह विधि गहरी क्लोनिंग का समर्थन नहीं करती है, जैसे jQuery.extend ।

समस्या # 1

लोडडेटा विधि में एक दूसरा पैरामीटर एपेंड है (स्टोर में मौजूदा रिकॉर्ड में रिकॉर्ड जोड़ने के लिए सही जोड़ें, पहले वाले को हटाने के लिए झूठे) । यानी नए पोस्ट सर्वर से आते हैं, हमें उन्हें मौजूदा में जोड़ना होगा। ऐसा करने के लिए, दूसरा पैरामीटर सही पर सेट करें।

हमारे मामले में, स्टोर लोड फ़िल्टरिंग का उपयोग करता है (filterOnLoad = true)

फ़िल्टरिंग कैसे काम करता है:

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

स्टोर और लोडडाटा विधि में फिल्टर का उपयोग करना संगत नहीं है।

Ext-all-debug.js फ़ाइल से लिस्टिंग ( लोडरकार्ड विधि का उपयोग लोडडेटा द्वारा किया जाता है ... और अधिक)

 loadRecords: function(records, options) { … if (!options.addRecords) { delete me.snapshot; me.clearData(); } me.data.addAll(records); … } 

यह वह जगह है जहाँ समस्या निहित है, विकल्प । हमारे मामले में विकल्प सही है , स्नैपशॉट हटाया नहीं गया है, डेटा केवल मुख्य संग्रह में आता है।

 API.Posts.get().done(function(posts){ myStore.loadData(posts); //posts.length 8, filtered 2 entries }); … API.Posts.get().done(function(posts){ myStore.loadData(posts, true); //posts.length 10, filtered all entries }); 

पहले बूट में केवल 2 प्रविष्टियाँ हुईं, और दूसरे में यह सब है।

me.data में 2 + 10 प्रविष्टियाँ हैं, और me.snapshot केवल 8, क्योंकि दूसरे कॉल से डेटा छिपे हुए स्टोरेज में समाप्त नहीं हुआ।

हमारे संग्रह को फिर से क्रमबद्ध करने के लिए, हमें पुराने फ़िल्टरों को साफ़ करने और नए लोगों को लागू करने की आवश्यकता है, आप केवल फ़िल्टर (जो बहुत, बहुत ही अजीब हैं) को फिर से नहीं पढ़ सकते हैं।

मिस्टॉर .clearFilter () विधि पिछले 10 रिकॉर्ड को मारती है, परिणामस्वरूप, हमारे पास रिपॉजिटरी में 8 रिकॉर्ड हैं।

निर्णय

 loadRecords: function(records, options) { … if (!options.addRecords) { delete me.snapshot; me.clearData(); } me.data.addAll(records); //add records in snapshot too. if (options.addRecords && me.snapshot) { me.snapshot.addAll(records) } … } 

समस्या # 2

IdProperty कुंजी का उपयोग इसके इच्छित उद्देश्य के लिए नहीं किया गया है।

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

स्रोत के माध्यम से अफवाह करते हुए, मैंने पाया कि ऐसी कार्यक्षमता मौजूद है, लेकिन बस इसका उपयोग नहीं किया जाता है। Me.data.addAll (रिकॉर्ड्स) विधि न केवल सरणियों को स्वीकार कर सकती है, बल्कि कुंजी-मूल्य ऑब्जेक्ट भी हो सकती है। आपको इस सुविधा का उपयोग करने के लिए बस उसी लोडरकार्ड विधि को थोड़ा संशोधित करने की आवश्यकता है।

निर्णय

 loadRecords: function(records, options) { … if (!options.addRecords) { delete me.snapshot; me.clearData(); } me.data.addAll(records); if (this.idProperty) { var indexRecord = {}; for (i = 0; i < length; i++) { indexRecord[records[i].data[this.idProperty]] = records[i]; } me.data.addAll(indexRecord); if (options.addRecords && me.snapshot) { me.snapshot.addAll(indexRecord); } records = []; for (key in indexRecord) { records.push(indexRecord[key]); } length = records.length; } else { me.data.addAll(records); if (options.addRecords && me.snapshot) { me.snapshot.addAll(records); } } … } 

इन परिवर्तनों के बाद, हमारे पास कुंजी के रूप में आईडी मान हैं, और हम नए डेटा जोड़ सकते हैं, उन्हें डुप्लिकेट नहीं किया जाएगा ...

PS यह मत भूलो कि आपके संपादन के साथ स्रोत में क्रॉलिंग खराब है, Ext.override का उपयोग करें । इस प्रकार, आपको फ्रेमवर्क के संस्करण को अपडेट करते समय समस्या से छुटकारा मिलता है, आप बस अपनी पैच फ़ाइल लिखते हैं, और यदि आप नए संस्करण में पुरानी समस्या को ठीक करते हैं, तो आप पैच से अपना समाधान निकालते हैं।

क्षितिज पर अपनी प्रस्तुति के साथ स्टोर के सिंक्रनाइज़ेशन समस्या पर विचार किया जाता है, और यदि कई प्रस्तुतियां हैं तो क्या करें।

आवेदन स्वीकार किए जाते हैं, शायद कुछ और दिलचस्प समस्याएं और उनके समाधान हैं।