2012-01-01 16 views
8

जेएसएफ 2.0 में, दृश्य क्षेत्र के लिए सबसे स्पष्ट उपयोग-केस संभावित रूप से एकाधिक AJAX पोस्ट-बैक वाला एक पृष्ठ है। जेएसएफ प्रबंधित बीन्स के बजाय सीडीआई का उपयोग करना हमें बिना किसी दायरे के छोड़ देता है, इसलिए हम या तो अपने आप को लागू करने के लिए छोड़ दिए जाते हैं, एक (संभावित रूप से बग-सवार) तीसरे पक्ष के कार्यान्वयन का उपयोग करते हैं या वार्तालाप के दायरे का उपयोग करते हैं।क्या वार्तालाप दृश्य क्षेत्र के लिए एक उचित विकल्प है?

मेरा प्रश्न: क्या बातचीत सामान्य AJAX स्थिति में दृश्य क्षेत्र के लिए एक योग्य विकल्प है? दृश्य क्षेत्र की तरह, क्या यह प्रति सत्र कई उदाहरणों की अनुमति देता है? नुकसान क्या हैं?

मुझे किसी नुकसान के बारे में पता है, अर्थात् जब उपयोगकर्ता पृष्ठ से दूर निकलता है तो वार्तालाप का दायरा स्वचालित रूप से हटा नहीं जाता है, लेकिन इसके बाद समय-समय पर हटा दिया जाता है। लेकिन मुझे यकीन नहीं है कि क्या होता है जब उपयोगकर्ता बातचीत के समय समाप्त होने से पहले उस पृष्ठ पर वापस पर नेविगेट करता है।

अद्यतन

बातचीत गुंजाइश वास्तव में प्रति सत्र कई उदाहरण का समर्थन करता है। This book उतना ही बताता है और मैं ch से कोड का उपयोग करके इसकी पुष्टि करने में सक्षम था। 2.

उत्तर

4

किसी भी @ConversationScoped CDI सेम में, आपको निम्न क्षेत्र होना चाहिए:

@Inject 
private Conversation conversation; 

जब भी आप बातचीत शुरू करना चाहते हैं, तो आप अगर सेम transient अवस्था में है की जाँच की जरूरत है। अन्यथा, IllegalStateException फेंक दिया जाएगा।

public void beginConversation() { 
    if (conversation.isTransient()) conversation.begin(); 
} 

ऐसा करने से, अपने सेम long-running राज्य में हो जाएगा: यह कुछ इस तरह होगा। इसलिए, यदि उपयोगकर्ता पृष्ठ से रास्ते पर नेविगेट करता है और बाद में नेविगेट करता है, तो आप हमेशा जांच सकते हैं कि उसकी बातचीत का समय समाप्त हो गया है या नहीं और उसे उस पृष्ठ पर ले जाएं जहां उसने छोड़ा था।

इसके अलावा, मैं थोड़ी देर के लिए CDI सेम साथ @ViewScopedManagedBean एक साथ उपयोग किया गया है। आप सीडीआई बीन को में MangedBean में इंजेक्ट करने के लिए अभी भी @Inject का उपयोग कर सकते हैं। मुझे नहीं लगता कि आप यद्यपि अन्य तरीकों से कर सकते हैं। वैसे भी, मुझे नहीं पता कि इससे बाद में कुछ बुरा होने का कारण होगा। हालांकि, अब तक, मैंने कभी भी किसी भी मुद्दे से मुलाकात नहीं की है। यदि आप वास्तव में @ViewScoped का उपयोग करना चाहते हैं, तो मुझे लगता है कि आप कोशिश कर सकते हैं: पी।

अद्यतन:

बातचीत गुंजाइश ठेठ AJAX स्थिति में देखने के क्षेत्र के लिए एक योग्य विकल्प है?

मुझे नहीं लगता कि @ConversationScoped@ViewScoped को पूरी तरह से प्रतिस्थापित कर सकता है।

दृश्य क्षेत्र की तरह, क्या यह प्रति सत्र कई उदाहरणों की अनुमति देता है?

नहीं, आपके पास प्रति सत्र कई उदाहरण नहीं हो सकते हैं।जैसा कि मैंने उल्लेख किया है, यदि आप एक नया वार्तालाप शुरू करते हैं, जबकि पुरानी बातचीत अभी भी long-running स्थिति में है, तो आपको IllegalStateException मिल जाएगा।

नुकसान क्या हैं?

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

+0

क्या आप प्रबंधित बीन्स में ईजेबी इंजेक्ट कर सकते हैं? यदि हां, तो इसका मतलब यह नहीं है कि जेएसएफ स्कॉप्स का प्रबंधन करने के लिए सीडीआई का उपयोग करने का कोई कारण नहीं है? यह सही नहीं लगता है ... –

+0

यदि आप प्रबंधित बीन में ईजेबी इंजेक्ट करना चाहते हैं, तो आप बस '@ EJB' का उपयोग कर सकते हैं। यह 'सीडीआई बीन्स' और 'प्रबंधित बीन' दोनों पर काम करेगा। इसके अलावा, 'सीडीआई' का उपयोग करने का कारण जेएसएफ स्कॉप्स के प्रबंधन के बारे में नहीं है। यह इस तथ्य के बारे में अधिक है कि आप सीडीआई सेम में बड़ी संख्या में चीजें इंजेक्ट कर सकते हैं। –

+0

"इसके अलावा, सीडीआई का उपयोग करने का कारण जेएसएफ स्कॉप्स के प्रबंधन के बारे में नहीं है।" हाँ, मुझे वह मिलता है। यह जेएसएफ स्कॉप्स को ऐसे तरीके से प्रबंधित करेगा जो बाकी ऐप सर्वर के साथ अधिक एकीकृत है। मैं जवाब स्वीकार नहीं कर रहा हूं क्योंकि मैं ऐसे उत्तर के लिए बाहर हूं जो सीधे वार्तालाप के इस उपयोग के मामले को संबोधित करता है। लेकिन जानकारीपूर्ण होने के लिए धन्यवाद। +1 क्योंकि उत्तर कम से कम उपयोगी है। –

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