2009-12-04 20 views
6

"गंभीर" जावा जीयूआई ऐप में, आपके पास अपने कई जीयूआई तत्वों के पीछे मॉडल होंगे: DocumentModelJEditorPane का समर्थन करते हुए, उदाहरण के लिए, या JList के पीछे।क्या स्विंग वर्कर थ्रेड के बाहर एक मॉडल को बदलना ठीक है?

हमें हमेशा स्विंग कार्यकर्ता धागे के बाहर से जीयूआई परिवर्तन न करने के लिए कहा जाता है और इसके आसपास काम करने के लिए SwingUtilities.invoke...() दिया जाता है। ठीक है, मैं उसके साथ रह सकता हूँ! जीयूआई घटकों के गुणों को सीधे बदलते समय यह निश्चित रूप से जरूरी है (और अच्छी तरह से काम करता है)।

आदर्श रूप से, मेरे अधिकांश जीयूआई-दृश्य परिवर्तन मॉडल के लिए होंगे, न कि जेकंपोनेंट्स के लिए, वैसे भी। लेकिन क्योंकि वे जीयूआई-दृश्यमान हैं, क्या वे जीयूआई परिवर्तन के रूप में "गिनती" करते हैं? अर्थात। घटनाओं को बदलें और श्रोताओं को आवश्यक decoupling प्रदान करते हैं, या मॉडल परिवर्तनों को invoke...() में भी लपेटने की आवश्यकता है?

शायद स्विंग पेशेवरों के लिए पुरानी टोपी, लेकिन मुझे कोई संदर्भ नहीं मिला जो स्पष्ट रूप से एक या दूसरे तरीके से बताता है।

उत्तर

5

आम तौर पर, मॉडल परिवर्तन invokeLater (...) में लपेटा जाना चाहिए। मैंने देखा कि स्विंग कक्षाओं के मॉडल के कोड में कोई decoupling नहीं है।

यह एक मॉडल बनाने के लिए आप पर निर्भर है जिसमें कॉल डिस्पैचर थ्रेड पर जीयूआई संशोधन किए गए कॉल की जांच हो सकती है।

+1

-1: उत्तर नहीं जो मैं सुनना चाहता था! (बस मजाक कर रहे हैं, +1) धन्यवाद! –

+1

स्विंग थ्रेड मुद्दों के बारे में डीबगिंग के बारे में, मैं अत्यधिक इस लिंक की सिफारिश करता हूं: http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html चेक थ्रेडवियोलेशन रेपेंटमैनेजर ने मुझे बहुत समय बचाया। –

+1

स्विंग टेक्स्ट * कुछ * ईडीटी को घटनाओं का स्थानांतरण करता है। बेशक यह सिर्फ एक बड़ा गड़बड़ बनाता है। –

2

यदि ईवेंट ईडीटी से निकाल दिए जाते हैं और स्विंग घटकों को अद्यतन करते हैं जो एक समस्या होने जा रहे हैं।

स्विंग टेक्स्ट में, ईवेंट ईडीटी में स्थानांतरित हो सकते हैं या नहीं (!) हो सकते हैं। यह परीक्षण मुश्किल बनाता है। अनजाने में, एपीआई एक बहुप्रचारित वातावरण में उपयोगी नहीं है।

तो: ईडीटी पर मॉडल को सबसे आसान रखें और अन्य धागे संदेशों को पास करना चाहिए (EventQueue.invokeLater शामिल)। वैकल्पिक रूप से आप सबकुछ के चारों ओर एक बड़ा ताला लगा सकते हैं, जो अधिक कठिन है (और आपको शायद अभी भी ईडीटी को सामान पास करने की आवश्यकता होगी)। माइक्रोसिंक्रनाइज़ेशन का प्रयास बहुत मुश्किल है।

+1

"माइक्रोसिंक्रनाइज़ेशन बहुत मुश्किल है।" : मैं पूरी तरह से इस बिंदु से सहमत हूं। मैंने अपने सभी सिंक्रनाइज़ किए गए कीवर्ड हटा दिए और अधिक ध्यान से जांच की कि जीयूआई (और जीयूआई के तत्वों के मॉडल) पर प्रत्येक संशोधन ईडीटी पर किया गया था। –

+1

मुझे इससे डर था। इसका मतलब है कि मेरे मॉडल तकनीकी रूप से जीयूआई का हिस्सा बन जाते हैं और इस उद्देश्य के लिए इसका हिस्सा माना जाना चाहिए। यह एक लेयरिंग/encapsulation बिंदु दृश्य से "साफ" प्रतीत नहीं होता है, और (यह मेरी सबसे बड़ी आपत्ति है, ज़ाहिर है) यह और अधिक काम है! +1, धन्यवाद! –

2

हां यह निश्चित रूप से ठीक है।

हालांकि यह सच है कि आपको ईडीटी के बाहर स्विंग घटकों को संशोधित नहीं करना चाहिए। आप निश्चित रूप से ईडीटी के बाहर अपने मॉडल में बदलाव कर सकते हैं।

यदि आपने मॉडल को अपने स्विंग घटकों में सही तरीके से तार दिया है, तो दृश्य अपडेट हो रहा है और इसलिए ईडीटी शेड्यूलिंग लगभग स्वचालित रूप से हो जाएगी।

देखें: http://java.sun.com/products/jfc/tsc/articles/architecture/#roots

के बारे में JavaBeans घटना मॉडल भाग देखें।

इस प्रकार मॉडल अपने बदले हुए राज्य को ईडीटी सुरक्षित तरीके से जीयूआई में संवाद करते हैं। नए जीयूआई घटकों को बनाते समय आपको इस डिजाइन पैटर्न का पालन करना चाहिए।

जीयूआई-राज्य मॉडल और एप्लिकेशन-डेटा मॉडल के बीच भेद को भी ध्यान दें।

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

इसके अलावा इस में से कोई भी ठेठ बहु सूत्रण नुकसान से पूरी तरह वाकिफ होने के नाते निवारण होता है।

लेकिन तुम सबसे निश्चित रूप से EDT बाहर से एक JTableModel में परिवर्तन कर सकते हैं।

संबंधित मुद्दे