कोड संशोधन Ext JS / GridView

एक बार मैं इस विश्वास में आया कि कोड

js को आमतौर पर लिखने की आवश्यकता नहीं है ताकि यह हो

सबसे इष्टतम। "ग्राहक भाग," मैंने कहा, "नहीं।"

प्रभावित करेगा, और इसलिए, आप स्कोर कर सकते हैं। " दुर्भाग्य से, यह पता चला कि यह पूरी तरह से नहीं है

इसलिए।



इस लेख में तकनीकी जानकारी है। अगर आपको समझ नहीं आ रहा है कि यहाँ क्या लिखा गया है, तो कृपया माइनस न करें।





यह सब पुस्तकालय के उपयोग के साथ शुरू हुआ

हमारे प्रोजेक्ट पर EXT JS, और

विशेष रूप से, संपादन योग्य विजेट। मूल रूप से

मुझे वास्तव में पुस्तकालय पसंद था। सबसे पहले, इसकी वस्तु उन्मुख

संरचना। समस्याएं बाद में शुरू हुईं। आगे देखते हुए मैं कहूंगा कि मैं अभी भी हूं

मैं EXTJS का प्रशंसक रहा हूं। एक और पुस्तकालय जो ऐसा ही होगा

तार्किक और ऐसे अवसरों की पेशकश, जो मुझे नहीं पता। यह भी होना चाहिए

ध्यान दें कि स्पष्ट प्रदर्शन समस्याएं या तो शुरू हुईं

तालिका में बड़ी संख्या में स्तंभ, या बड़ी संख्या में पंक्तियों के साथ (लगभग)

यह पुस्तकालय के डेवलपर्स है, हालांकि, चेतावनी दी है)।



आप यहाँ कुछ सामान्य js समस्याओं के बारे में पढ़ सकते हैं ।









CSS - कैस्केडिंग स्टाइल शीट - “और किस शब्द के लिए

कैस्केडिंग? "







वास्तव में, इस समस्या को हमारे द्वारा इंगित किया गया था

html एनकोडर (जेन्या, हैलो!

जे)



सीएसएस फ़ाइल पर एक नज़र डालें,

जिसका उपयोग किया जाता है।



हां, कभी-कभी शैलियों को कैस्केड किया जाता है, लेकिन अंदर

विशाल बहुमत - नहीं। "आप क्या समस्या है," आप पूछते हैं। मेरे लिए

एक जावा प्रोग्रामर के लिए, कोई समस्या नहीं है

जब तक मैं अस्वीकार किए गए पृष्ठ पर ग्रिड को एम्बेड नहीं करता, तब तक मौजूद रहा। और ...

सभी शैलियों मुझ पर तैरती हैं। ग्रिड भयानक लग रहा था। क्या हो रहा है? तथ्य यह है कि

पृष्ठ ने हर चीज़ के लिए सामान्य सीएसएस शैलियों का उपयोग किया

परियोजना और उनकी उन शैलियों की तुलना में अधिक प्राथमिकता थी जो इसमें वर्णित हैं

grid.css। क्यों

इसलिए - मैं आपको नहीं समझाऊंगा। मैं इसे "जितना सटीक ढंग से रास्ता तय करता हूं, उतना ही अधिक समझता हूं

शैली पर प्राथमिकता ”, कम से कम यह स्पष्टीकरण मेरे लिए काम करता है। वहाँ है

एक और संशोधक "महत्वपूर्ण", लेकिन जैसा कि उन्होंने मुझे बताया, यह बेहतर नहीं है

गाली देना। उम्मीद है कि पेशेवर डिजाइनरों की संख्या को देखते हुए

यहाँ टिप्पणियों में एक स्पष्टीकरण होगा।



इसलिए, अपने लिए, मैंने निष्कर्ष निकाला - शब्द का उपयोग करें

CSS परिभाषा में कैस्केडिंग।







CSS नियम अपडेट या पहले ब्रेक







यह पता चला है कि ग्रिड में से एक में आवश्यकताओं के अनुसार

प्रदर्शित करने के लिए 20 कॉलम थे। "छोटी संख्या" - जैसा मैंने सोचा था। यह पता चला कि

कोई।



Ext.grid.GridView कॉलम की चौड़ाई निर्दिष्ट करने के लिए एक मजेदार तंत्र का उपयोग करता है। जब ड्राइंग

एक नोड <style> जिसमें बनाया गया है

खाली दृश्य शैलियाँ लिखी गई हैं:







# [ग्रिड आईडी]

.x-ग्रिड-कोल- [संख्या

कॉलम] {



2}







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







# ग्रिड-उदाहरण .x-ग्रिड-कॉल -0



2}











जब html कोड तैयार हो जाता है,

इन गतिशील रूप से उत्पन्न शैलियों को संशोधित और निर्दिष्ट किया जाता है

प्रत्येक स्तंभ की चौड़ाई। ऐसी प्रत्येक शैली के लिए,







Ext.util.CSS.updateRule







मुझे कहना होगा कि यह एक सस्ता ऑपरेशन नहीं है। और 20 के लिए

वक्ताओं ने ध्यान देने योग्य ब्रेक देखे। इसलिए मुझे अनुकूलन करना पड़ा

इस तंत्र के बाद से हुई मूर्त विराम को हटाने के लिए

डाउनलोड, उस क्षण तक जब उपयोगकर्ता वास्तव में कुछ कर सकता था।

इसके अलावा, प्रोसेसर लोड 100% था।



प्रारंभ में, मैंने खाली शैलियों को नहीं, बल्कि तुरंत उत्पन्न किया

सेट चौड़ाई से भरा बनाया

(चौड़ाई)। एक सवारी, लेकिन फिर इसे करना पड़ा

साफ (नीचे देखें)



इसलिए, अपने लिए, मैंने निष्कर्ष निकाला - उपयोग न करें

सीएसएस तालिकाओं का गतिशील अद्यतन।







तत्वों की एक बड़ी संख्या या "अच्छी तरह से, जितना संभव हो

धिक्कार है?







आप प्रत्येक सेल के लिए लगभग ऐसा कोड देखेंगे

ग्रिड:







<td class = "x-grid-col x-grid-td-1

x-grid-cell-5-1 "tabindex =" 0 ">



<div class = "x-grid-col-1

एक्स-ग्रिड-सेल-इनर »>



<div class = "x-grid-cell-text" unselectable = "on"> $ 31.61 </ div>



</ Div>



</ Td>







यह केवल एक सेल है। यह पता चला है कि इसके अलावा

td, नाखुश ब्राउज़र को अभी भी रखने की आवश्यकता होगी

कम से कम दो DOM ऑब्जेक्ट। यह स्मृति लेता है

और संसाधन।



मेरी राय में, इससे बचना चाहिए।







DOM टेबल या "वेल, इट्स डेड" के साथ काम करें



यह ध्यान दिया जाना चाहिए कि फ़ोरम ईमानदार डेवलपर्स हैं

चेतावनी दी है कि बड़ी संख्या में लाइनों के साथ काम करना धीमा हो जाएगा और

अंकुरण का उपयोग किया जाना चाहिए। लेकिन ... उपयोगकर्ता हमेशा सही होते हैं और

पृष्ठ नहीं देखना चाहते थे। वास्तव में, एक आसान तरीका है

बड़ी संख्या में पंक्तियों (मेरे पास) के साथ काम करने के लिए ग्रिड का अनुकूलन करें

बिना ब्रेक के 500 के साथ काम करता है)।







क्या समस्या थी? तथ्य यह है कि

GridView प्रस्तुति के लिए एक तालिका का उपयोग करता है।

हटाएं / डालें / संपादित करें ऑपरेशन बहुत धीमा था अगर

पंक्तियों की संख्या 20 से अधिक थी (15 से अधिक स्तंभों की संख्या के साथ)। यह और

यह स्पष्ट है कि एक तालिका केवल एक सरणी नहीं है, बल्कि एक संपूर्ण वस्तु है जिसकी आपको आवश्यकता है

recount / redraw। इसके अलावा, जब किसी में सभी मान बदलते हैं

स्तंभ (उदाहरण के लिए, एक परिकलित स्तंभ, जो बाहरी पैरामीटर पर निर्भर करता है)

ब्राउज़र बस मर गया और खुद नहीं आया।







यह कैसे तय किया गया था? प्रोफाइल से, मुझे एहसास हुआ कि साथ काम करना

बड़ी तालिकाएँ (> 20-30 पंक्तियाँ) की तुलना में अधिक समय तक एक क्रम लेती हैं

छोटे लोगों के साथ (<20 लाइनें)। उसके बाद, मैंने कार्यान्वयन को देखा

Google स्प्रेडशीट यहां

मुझे वहाँ क्या मिला: वे एक बड़ी मेज का उपयोग नहीं करते, लेकिन में विभाजित हो गए

कई छोटे, जो एक के नीचे एक स्थित हैं। चौड़ाई भी

कॉलम शैलियों द्वारा निर्धारित नहीं हैं, लेकिन, अधिक तार्किक रूप से, पहली पंक्ति की चौड़ाई के माध्यम से

शैली का उपयोग कर

टेबल लेआउट:

तय की।







परिणाम



इस प्रकार, ग्रिड व्यू को निम्नलिखित नियमों को ध्यान में रखते हुए फिर से लिखा गया है:



- कैस्केड शैलियों का उपयोग करें



- अतिरिक्त तत्वों को न जोड़ें

डोम



- डायनेमिक स्टाइल अपडेट का उपयोग न करें



- बड़े तालिकाओं को कई में विभाजित करें

छोटा



नतीजतन, मुझे मिल गया

EditableGrid जो बड़े काम कर सकते हैं

पंक्तियों की संख्या।