स्विंग के जेटीबल और जेटीआर

Question

के प्रस्तुतकर्ता तंत्र को समझने में कठिनाइयों अक्सर, JTable या JTree उपयोगकर्ता का उपयोग करते समय और लिखते हैं कि यह स्वयं का विशिष्ट सेल रेंडरर है।

DefaultTableCellRenderer से उपयोगकर्ता के घटक का उत्तराधिकारी होना बहुत आम है, और प्रस्तुतकर्ता विधि getTableCellRendererComponent लागू करता है। यह पता चला है कि DefaultTableCellRenderer वास्तव में जेएलएबल से विरासत में मिलता है, इस प्रकार सुपर (जिसे रेंडर विधि पर) कहा जाता है, इस प्रकार स्वयं (यह) लौटाता है और इस प्रकार उपयोगकर्ता का रेंडरर इसी तरह खुद को (यह) भी लौटा सकता है।

और यह सब ठीक काम करता है।

मेरा सवाल यह है कि यह कैसे हो सकता है?

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

मैं वेब खोज की है, और स्विंग के कोड के भीतर खुदाई, और क्लोन या प्रतिलिपि निर्माता है कि वास्तव में उत्पादन लेबल डुप्लिकेट की किसी भी कार्य नहीं पा सके। मुझे कोई सबूत नहीं मिला कि (शायद) स्विंग प्रत्येक बार स्क्रैच से रेंडरर को फिर से चालू करने के लिए प्रतिबिंब का उपयोग करता है।

मैं स्विंग के tutorial on JTables पढ़ लिया है, और वहाँ मैं अगले लाइनों मिल सकता है:

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

वे संकेत देते हैं कि वास्तव में जो मैं कह रहा हूं वह सही है, लेकिन यह समझ में नहीं आता कि यह वास्तव में कैसे पूरा किया जा रहा है।

मुझे यह नहीं मिल रहा है। क्या आप में से कोई भी हो सकता है

Answer 1

यह flyweight pattern का कार्यान्वयन है।

जब जेटीबल खुद को पश्चाताप करता है, तो यह प्रत्येक सेल पर एक लूप शुरू करता है और इसे चित्रित किया जाना चाहिए।

प्रत्येक सेल के लिए, यह रेंडरर को सेल से संबंधित तर्कों के साथ आमंत्रित करता है। रेंडरर एक घटक देता है। यह घटक वर्तमान तालिका कक्ष से संबंधित आयताकार में चित्रित किया गया है।

तो रेंडरर अगले सेल के लिए कहा जाता है, और लौट आए घटक (जो, एक अलग पाठ और रंग है उदाहरण के लिए), आयत सेल से संबंधित में चित्रित है, आदि

कल्पना कीजिए प्रत्येक कि समय रेंडरर कहलाता है, लौटा घटक का एक स्क्रीनशॉट लिया जाता है और टेबल सेल में चिपकाया जाता है।

Answer 2

Adition में @ करने के लिए जेबी के कैसे JTable और JTreeflyweight pattern उपयोग करते हैं, ध्यान दें कि दोनों वर्गों सार्वजनिक तरीकों getCellRenderer() और getCellEditor() प्रदान की स्पष्ट explication। यह देखने के लिए इन विधियों की जांच करें कि JTable कक्षा द्वारा रेंडरर या संपादक का चयन करने के लिए Class Literals as Runtime-Type Tokens का उपयोग करता है, यदि कोई कॉलम द्वारा निर्दिष्ट नहीं किया गया है। आंतरिक रूप से, JTable उदाहरण भंडारण के लिए Hashtable defaultRenderersByColumnClass का उपयोग करता है।

Answer 3

कुछ खुदाई के बाद, DefaultTableCellRenderer documentation से अगले कार्यान्वयन टिप्पणी पाया:

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

यह अनिवार्य रूप से जेबी ने ऊपर वर्णित किया है।

(त्वरित) उत्तरों के लिए धन्यवाद