जावा सर्वर फेस 2.0 के मुख्य नुकसान क्या हैं?

Question

कल मैंने जावा सर्वर फेस 2.0 पर एक प्रस्तुति देखी जो वास्तव में प्रभावशाली थी, भले ही मैं वर्तमान में एक खुश एएसपीनेट एमवीसी / jQuery डेवलपर हूं। जेएसएफ के बारे में मुझे जो सबसे ज्यादा पसंद था, वह AJAX- सक्षम UI घटकों की विशाल राशि थी जो ASP.NET MVC के साथ, विशेष रूप से AJAX- भारी साइटों पर की तुलना में बहुत तेजी से विकास कर रहे हैं। एकीकरण परीक्षण बहुत अच्छा लग रहा था।

चूंकि प्रस्तुति ने केवल JSF के फायदों पर जोर दिया है, मैं दूसरे पक्ष के बारे में भी सुनना चाहूंगा।

तो मेरे सवाल हैं:

• जावा सर्वर फेस 2.0 के मुख्य नुकसान क्या हैं?
• JSF के बजाय ASP.NET MVC का उपयोग करके JSF डेवलपर क्या विचार कर सकता है?

Comments

सच कहूँ तो हम सभी को इस घटक, बीन, "फीचर" बकवास से छुटकारा पाना चाहिए और सामान्य कोडिंग पर वापस जाना चाहिए। मैं एक मोटा ढांचा नहीं चाहता जो मेरे लिए सब कुछ करने की कोशिश करे (और बुरी तरह से करता है, मैं जोड़ सकता हूं) और मुझे उससे दूर कर दें जो वास्तव में चल रहा है। मैं टाइपस्क्रिप्ट पर एक नज़र डालने की सिफारिश करूंगा और कोड की बहुत पतली परतों को खोजने की कोशिश करूंगा जो उस के साथ काम करता है और उस पर बनाया गया है। JSF / PF और दोस्तों के पास बहुत सारी "सुविधाएँ" हैं, लेकिन आपको उनके चारों ओर अपना रास्ता बनाना होगा और जो आप चाहते हैं आदि करने के लिए सही जादू विशेषता कोड या ट्री लेआउट को जानना होगा

— एंड्रयू

Answer 1

JSF 2.0 नुकसान? ईमानदारी से, जब आप मूल वेब डेवलपमेंट (HTML / CSS / JS, सर्वर साइड बनाम क्लाइंट साइड, इत्यादि) और बुनियादी जावा सर्वलेट एपीआई (अनुरोध / प्रतिक्रिया / सत्र ) के बारे में ठोस पृष्ठभूमि का ज्ञान नहीं रखते हैं, तो आप संबंधित स्टडी लर्निंग कर्व से अलग हैं। , अग्रेषण / पुनर्निर्देशन, आदि), कोई गंभीर नुकसान दिमाग में नहीं आता है। जेएसएफ को अपनी वर्तमान रिलीज़ में अभी भी कम उम्र के दौरान प्राप्त नकारात्मक छवि से छुटकारा पाने की आवश्यकता है, जिसके दौरान कई गंभीर नुकसान थे।

JSF 1.0 (मार्च 2004)

यह प्रारंभिक रिलीज थी। यह उन दोनों मुख्य और प्रदर्शन क्षेत्रों में बग्स से जुड़ा हुआ था जिनके बारे में आप जानना नहीं चाहते हैं। जब आप सहजता से अपेक्षा करते हैं, तो आपका वेबकैप हमेशा काम नहीं करता था। डेवलपर के रूप में आप मुश्किल से रोते हुए भागेंगे।

JSF 1.1 (मई 2004)

यह बगफिक्स रिलीज थी। प्रदर्शन में अभी भी बहुत सुधार नहीं हुआ था। एक प्रमुख नुकसान यह भी था: आप जेएसएफ पृष्ठ में HTML को त्रुटिपूर्ण रूप से इनलाइन नहीं कर सकते। सभी सादे वेनिला HTML जेएसएफ घटक पेड़ से पहले प्रदान किए जाते हैं । आपको सभी सादे वेनिला को <f:verbatim>टैग में लपेटने की आवश्यकता है ताकि वे जेएसएफ घटक पेड़ में शामिल हो जाएं। हालाँकि यह विनिर्देशन के अनुसार था, इसे बहुत आलोचना मिली। Ao JSF / Facelets भी देखें : HTML टैग्स के साथ JSF / Facelets को मिलाना एक अच्छा विचार क्यों नहीं है?

JSF 1.2 (मई 2006)

यह रयान लुबके द्वारा नई JSF डेवलपमेंट टीम लीड की पहली रिलीज़ थी। नई टीम ने बहुत अच्छा काम किया। कल्पना में भी बदलाव थे। प्रमुख परिवर्तन दृश्य हैंडलिंग का सुधार था। यह न केवल जेएसपी से जेएसएफ को पूरी तरह से अलग कर देता है, इसलिए एक जेएसपी की तुलना में एक अलग दृश्य प्रौद्योगिकी का उपयोग कर सकता है, लेकिन इसने डेवलपर्स को जेएसएफ पृष्ठ में <f:verbatim>टैग के साथ परेशान किए बिना सादे वेनिला एचटीएमएल को इनलाइन करने की अनुमति दी । नई टीम का एक और प्रमुख फोकस प्रदर्शन में सुधार था। सूर्य JSF संदर्भ कार्यान्वयन 1.2 (जो कूटनाम गया था के जीवनकाल के दौरान Mojarra निर्माण 1.2_08 के बाद से, 2008 के आसपास), व्यावहारिक रूप से हर निर्माण सामान्य (मामूली) bugfixes के बगल में (प्रमुख) प्रदर्शन में सुधार के साथ भेज दिया गया।

जेएसएफ 1.x (1.2 सहित) का एकमात्र गंभीर नुकसान अनुरोध और सत्र के दायरे में तथाकथित वार्तालाप गुंजाइश की कमी है । इसने डेवलपर्स को छिपे इनपुट तत्वों, अनावश्यक डीबी प्रश्नों और / या सत्र के स्कोप के साथ परेशान करने के लिए मजबूर किया, जब भी कोई व्यक्ति सत्यापन, रूपांतरण, मॉडल परिवर्तन और कार्रवाई के चालान को सफलतापूर्वक संसाधित करने के लिए बाद के अनुरोध में प्रारंभिक मॉडल डेटा को बनाए रखना चाहता है। जटिल वेबएप्लिकेशंस। एक 3 पार्टी पुस्तकालय को अपनाने से दर्द को नरम किया जा सकता है जो बाद के अनुरोध में आवश्यक डेटा को रखता है जैसे कि MyFaces Tomahawk <t:saveState> घटक, JBoss सीम वार्तालाप गुंजाइश और MyFaces ऑर्केस्ट्रा बातचीत की रूपरेखा।

HTML / CSS शुद्धतावादियों के लिए एक और नुकसान यह है कि JSF जनरेट किए गए HTML आउटपुट में :HTML तत्व की विशिष्टता को सुनिश्चित करने के लिए ID विभाजक वर्ण के रूप में बृहदान्त्र का उपयोग करता है id, खासकर जब एक घटक दृश्य में एक से अधिक बार पुन: उपयोग किया जाता है (अस्थायी, पुनरावृत्त घटक, आदि) । क्योंकि सीएसएस पहचानकर्ताओं में यह एक अवैध चरित्र है, इसलिए आपको \सीएसएस चयनकर्ताओं में कॉलोन से बचने के लिए उपयोग करने की आवश्यकता होगी , जिसके परिणामस्वरूप बदसूरत और विषम दिखने वाले चयनकर्ता #formId\:fieldId {}या यहां तक ​​कि #formId\3A fieldId {}। यह भी देखें कि जेएसएफ जेनरेट किए गए HTML एलिमेंट आईडी को कोलन के साथ कैसे इस्तेमाल करें: "सीएसएस चयनकर्ताओं में"? हालाँकि, यदि आप शुद्ध नहीं हैं, तो डिफ़ॉल्ट रूप से भी पढ़ें , JSF अनुपयोगी आईडी बनाता है, जो वेब मानकों के css भाग के साथ असंगत हैं ।

इसके अलावा, JSF 1.x बॉक्स से बाहर अजाक्स सुविधाओं के साथ जहाज नहीं था। वास्तव में एक तकनीकी नुकसान नहीं है, लेकिन उस अवधि के दौरान वेब 2.0 प्रचार के कारण, यह एक कार्यात्मक नुकसान बन गया। Exadel Ajax4jsf है, जो अच्छी तरह से वर्षों के दौरान विकसित और के मुख्य हिस्सा बन गया था शुरू करने की जल्दी थी JBoss RichFaces घटक पुस्तकालय। एक अन्य घटक पुस्तकालयों को बिलियन अजाक्स शक्तियों के साथ भेज दिया गया था, जो कि अच्छी तरह से ज्ञात आईसीईफेसेस था ।

JSF 1.2 जीवनकाल के लगभग आधे रास्ते में, एक नई XML आधारित दृश्य तकनीक पेश की गई: फेसलेट्स । इसने JSP के ऊपर भारी लाभ की पेशकश की, विशेष रूप से टेम्प्लेटिंग के क्षेत्र में।

JSF 2.0 (जून 2009)

यह दूसरी बड़ी रिलीज़ थी, जो अजाक्स के साथ गुलज़ार के रूप में थी। बहुत सारे तकनीकी और कार्यात्मक परिवर्तन थे। JSP को फेसलेट्स द्वारा डिफॉल्ट व्यू तकनीक के रूप में बदल दिया गया है और शुद्ध XML (तथाकथित कंपोजिट घटकों ) का उपयोग करके कस्टम घटकों को बनाने के लिए फेसलेट्स का विस्तार किया गया । यह भी देखें कि जेएसएफ पर फेसलेट्स को जेएसएफ 2.0 से व्यू डेफिनेशन लैंग्वेज के रूप में क्यों पसंद किया जाता है?

अजाक्स शक्तियों को <f:ajax>घटक के स्वाद में पेश किया गया था जिसमें अजाक्स 4jsf के साथ बहुत समानताएं हैं। टिप्पणियों और अधिवेशन-ओवर-कॉन्फ़िगरेशन एन्हांसमेंट को यथासंभव वर्बोज़ फ़ाइल को मारने के लिए पेश किया गया था faces-config.xml। साथ ही, डिफ़ॉल्ट नामकरण कंटेनर ID विभाजक वर्ण :विन्यास योग्य हो गया, ताकि HTML / CSS शुद्धतावादी राहत की सांस ले सकें। तुम सब करने की ज़रूरत है के रूप में यह परिभाषित करने के लिए है init-paramमें web.xmlनाम के साथ javax.faces.SEPARATOR_CHARकि आप चरित्र अपने आप को इस तरह के रूप उपयोग नहीं कर रहे कहीं भी ग्राहक आईडी के दशक में, और यह सुनिश्चित करना -।

अंतिम लेकिन कम से कम, एक नया दायरा पेश नहीं किया गया था, दृश्य क्षेत्र। इसने पहले वर्णित के रूप में एक और प्रमुख JSF 1.x नुकसान को समाप्त कर दिया। आप सिर्फ बीन @ViewScopedको बाद में (संवादी) अनुरोधों में डेटा को बनाए रखने के लिए सभी तरीकों को परेशान किए बिना बातचीत की गुंजाइश को सक्षम करने की घोषणा करते हैं। @ViewScopedजब तक आप बाद में एक ही दृश्य (स्वतंत्र रूप से खोले गए ब्राउज़र टैब / विंडो!) को या तो सिंक्रोनाइज़ या असिंक्रोनस (Ajax) के रूप में सबमिट कर रहे हैं, तब तक एक बीन रहेगा। यह भी देखें कामयाब सेम में देखें और अनुरोध दायरे के बीच अंतर और कैसे सही सेम दायरा चुनने के लिए?

यद्यपि व्यावहारिक रूप से JSF 1.x के सभी नुकसानों को समाप्त कर दिया गया था, लेकिन JSF 2.0 विशिष्ट बग हैं जो शोस्टॉपर बन सकते हैं। @ViewScopedटैग संचालकों में विफल रहता है आंशिक राज्य की बचत में एक चिकन अंडे समस्या के कारण। यह JSF 2.2 में तय किया गया है और Mojrara 2.1.18 में वापस लाया गया है। साथ ही HTML5 जैसी कस्टम विशेषताएँ पास करनाdata-xxx समर्थित नहीं है। यह जेएसएफ 2.2 में नए पस्चथ्रू तत्वों / विशेषताओं विशेषता द्वारा तय किया गया है। इसके अलावा जेएसएफ कार्यान्वयन मोजार्रा के मुद्दों का अपना समूह है । अपेक्षाकृत उनमें से बहुत से, कभी-कभी अनजाने में किए गए व्यवहार से<ui:repeat> संबंधित होते हैं , नए आंशिक राज्य बचत कार्यान्वयन और खराब कार्यान्वित फ्लैश स्कोप । उनमें से अधिकांश मोअज़रा 2.2.x संस्करण में तय किए गए हैं।

JSF और jQuery UI के आधार पर, JSF 2.0 समय के आसपास, प्राइमफेस को पेश किया गया था। यह सबसे लोकप्रिय जेएसएफ घटक पुस्तकालय बन गया।

JSF 2.2 (मई 2013)

JSF 2.2 की शुरुआत के साथ, HTML5 को buzzword के रूप में उपयोग किया गया था, हालांकि यह तकनीकी रूप से सभी पुराने JSF संस्करणों में समर्थित था। JavaServer Faces 2.2 और HTML5 समर्थन भी देखें , XHTML अभी भी क्यों इस्तेमाल किया जा रहा है । सबसे महत्वपूर्ण नई JSF 2.2 फीचर कस्टम घटक विशेषताओं के लिए समर्थन है, जिससे कस्टम टेबललेस रेडियो बटन समूहों जैसी संभावनाओं की दुनिया खुल रही है ।

कार्यान्वयन के अलावा विशिष्ट कीड़े और कुछ "कष्टप्रद छोटी चीजें" जैसे कि एक मान्य / कनवर्टर (पहले से ही जेएसएफ 2.3 में तय) में एक ईजेबी को इंजेक्ट करने में असमर्थता, जेएसएफ 2.2 विनिर्देश में वास्तव में बड़े नुकसान नहीं हैं।

घटक MVC बनाम अनुरोध आधारित MVC आधारित है

कुछ लोग यह चुन सकते हैं कि JSF का प्रमुख नुकसान यह है कि यह उत्पन्न HTML / CSS / JS पर बहुत कम सूक्ष्म नियंत्रण देता है। यह जेएसएफ का अपना नहीं है, यह सिर्फ इसलिए है क्योंकि यह एक घटक आधारित एमवीसी फ्रेमवर्क है, न कि अनुरोध (एक्शन) आधारित एमवीसी फ्रेमवर्क। यदि MVC फ्रेमवर्क पर विचार करते समय HTML / CSS / JS को नियंत्रित करने की एक उच्च डिग्री आपकी प्रमुख आवश्यकता है, तो आपको पहले से ही एक घटक आधारित MVC फ्रेमवर्क नहीं, बल्कि स्प्रिंग MVC जैसे MVC फ्रेमवर्क पर आधारित अनुरोध पर देखना चाहिए । आपको केवल इस बात का ध्यान रखना है कि आपको वह सब लिखना होगा जो HTML / CSS / JS बॉयलरप्लेट स्वयं करता है। अनुरोध MVC और घटक MVC के बीच अंतर भी देखें ।

यह सभी देखें:

• JSF, सर्वलेट और JSP में क्या अंतर है? (मूल बातें समझने के लिए)
• जेएसएफ का उपयोग टेबललेस सीएसएस लेआउट विकसित करने के लिए (जेएसएफ के बारे में एक और मिथक)
• JSF बनाम सादे HTML / CSS / JS / jQuery (जब JSF गलत विकल्प है)
• वेब अनुप्रयोगों में डिजाइन पैटर्न (MVC के पीछे की विचारधारा दिखाता है)

Comments

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

— अर्जन टिजम्स

फिर भी, यूआई: रिपीट को ठीक करने की आवश्यकता है, और नेस्टेड एच के साथ बग्स: डेटाटेबल + अजाक्स दोनों कार्यान्वयन में रिलीज के एक वर्ष से अधिक समय बाद दयनीय हैं। वास्तव में अफ़सोस होता है, क्योंकि अगर दो समस्याओं के लिए नहीं, तो मैं सभी वेब अनुप्रयोग विकास के समाधान के रूप में JSF 2.0 को किसी को भी सुझाऊंगा ।

— fdreger

अच्छा जवाब है लेकिन मुझे लगता है कि परीक्षण के बारे में कुछ तर्क याद आते हैं। JSF का परीक्षण कठिन है। ASP.NET MVC TDD तैयार हैं।

— गुआदो Gu

मेरे पास 20 साल का जेएवीए / वेब अनुभव है और मैं उन सभी परियोजनाओं को मना करता हूं जो जेएसएफ का उपयोग करते हैं जैसा कि मैं और कृपया नाराज न हों, महसूस करें कि जेएसएफ सभी रूपरेखाओं में सबसे भयानक है। यह हर अमूर्तन नियमों का उल्लंघन करता है, जिसमें सीएसएस, एचटीएमएल और जावा सभी को एक साथ मिलाया जाता है। जेएसएफ परियोजनाओं में प्रगति स्प्रिंग एमवीसी परियोजना के साथ एक एक्सटीजेएस की तुलना में हास्यास्पद है। जेएसएफ में रखरखाव भयानक और सरल है अन्यथा सीधे मुद्दे जेएसएफ में एक पूर्ण क्लस्टर *** हैं। मेरे अनुभव में, JSF का उपयोग न करें। मानक या नहीं, यह एक बुरा मानक है जो मानक भी नहीं होना चाहिए। VAADIM या विकेट या एक्सटीजेएस की कोशिश करें।

— लॉरेंस

बड़ा नुकसान इसका ई-मेल आईडी है जिसमें ग्रहण आईडीई में रिफ्लेक्टरिंग सपोर्ट, खराब वेबफ्रैगमेंट सपोर्ट, खराब सर्वर इंटीग्रेशन, नो click and go to component or include, कंपोनेंट्स / टैग्स का कोई निर्भरता ग्राफ नहीं है और न ही खुद के या 3 पार्टी टैग्स के लिए कोई मेन्यू है। मैं परियोजना चौड़ी खोजों के प्रदर्शन के लिए बहुत समय बिताता हूं यह समझने के लिए कि घटक या फ़ंक्शन x का उपयोग कहां किया जाता है।

— djmj

Answer 2

जेएसएफ के साथ काम करने के 5 साल बाद, मुझे लगता है कि मैं अपने 2 सेंट जोड़ सकता हूं।

दो प्रमुख JSF कमियां:

1. बड़ी सीखने की अवस्था। JSF जटिल है, यह सिर्फ सच है।
2. इसका घटक प्रकृति। घटक-आधारित ढांचा वेब की वास्तविक प्रकृति को छिपाने की कोशिश करता है, जो भारी मात्रा में जटिलताओं और आपदाओं के साथ आता है (जैसे लगभग 5 वर्षों के भीतर जेएसएफ में जीईटी का समर्थन नहीं करना)।
   डेवलपर से HTTP रिक्वेस्ट / रिस्पॉन्स को छिपाना IMHO एक बहुत बड़ी गलती है। मेरे अनुभव से, प्रत्येक घटक-आधारित रूपरेखा वेब विकास में अमूर्तता जोड़ती है, और यह कि अमूर्तता का परिणाम अनावश्यक ओवरहेड और उच्च जटिलता है।

और छोटी-छोटी कमियां जो मेरे दिमाग में आती हैं:

1. ऑब्जेक्ट की डिफ़ॉल्ट आईडी से उसके माता-पिता की आईडी बनती है, उदाहरण के लिए form1: button1।
2. गलत पृष्ठ के टुकड़े पर टिप्पणी करने का कोई आसान तरीका नहीं है। टैग <ui:remove>को वाक्यात्मक रूप से सही सामग्री की आवश्यकता होती है जिसे वैसे भी पार्स किया जाता है।
3. निम्न गुणवत्ता वाले 3 पार्टी घटक जो जारी रखने से पहले उदाहरण के isRendered()अंदर जांच नहीं processXxx()करते हैं।
4. LESS & Sencha को शामिल करना कठिन है।
5. REST के साथ अच्छा नहीं खेलता है।
6. यूएक्स डिजाइनरों के लिए इतना आसान नहीं है, क्योंकि तैयार-से-उपयोग के घटकों की अपनी सीएसएस शैली है, जिसे ओवरराइट करने की आवश्यकता है।

मुझे गलत मत समझो संस्करण 2 में एक घटक ढांचा JSF के रूप में वास्तव में अच्छा है, लेकिन यह अभी भी घटक-आधारित है, और हमेशा रहेगा ...

कृपया टेपेस्ट्री, विकेट की कम लोकप्रियता और अनुभवी जेएसएफ डेवलपर्स के कम उत्साह (जो और भी अधिक सार्थक है) पर एक नज़र डालें। और इसके विपरीत, रेल्स, ग्रेल्स, Django, Play की सफलता पर एक नज़र डालें! फ्रेमवर्क - वे सभी एक्शन-आधारित हैं और प्रोग्रामर सच्चे अनुरोध / प्रतिक्रिया और से छिपाने की कोशिश नहीं करते हैं वेब के स्टेटलेस प्रकृति ।

मेरे लिए यह प्रमुख JSF नुकसान है। IMHO JSF कुछ प्रकार के अनुप्रयोगों (इंट्रानेट, प्रपत्र-गहन) के अनुरूप हो सकता है, लेकिन वास्तविक जीवन के वेब के लिए एप्लिकेशन के लिए यह एक अच्छा तरीका नहीं है।

आशा है कि यह किसी को उसकी पसंद के साथ मदद करता है जो सामने वाले के संबंध में है।

Comments

+1 वेब को स्टेटलेस, अच्छा या बुरा होने के लिए डिज़ाइन किया गया था, कोई भी इसे बदल नहीं सकता है (और इसका कोई कारण नहीं है!)

— एलिरेज़ा फतही

यह निश्चित रूप से बड़ी साइटों को संभाल सकता है irctc.co.in भारत में सबसे बड़ी ईकॉमर्स साइट है। । । लेकिन हां JSF के साथ आपके पास UI पर अधिक नियंत्रण नहीं है जो उत्पन्न होता है।

— निर्भय मिश्रा

क्या आप परिभाषित कर सकते हैं कि क्या है real-life web application? इसके अलावा, JSF अनुरोध / प्रतिक्रिया की प्रकृति को छुपाता है, यह सच हो सकता है, लेकिन यह प्रोग्रामर्स के लिए यह जानने के लिए प्रायोजन है कि वास्तव में कवर के तहत क्या हो रहा है। यदि आप नहीं जानते कि HTTP कैसे काम करता है, तो इसे JSF या किसी अन्य फ्रेमवर्क से पहले सीखें।

— एक्सट्रीम बाइकर

Answer 3

कुछ कमियां जो मन में आती हैं:

1. JSF एक घटक-आधारित ढांचा है। इसमें अंतर्निहित प्रतिबंध हैं जो घटक-मॉडल का पालन करने के साथ करना है।
2. AFAIK JSF केवल POST का समर्थन करता है, इसलिए यदि आप कहीं GET चाहते हैं तो आपको एक सादे सर्वलेट / JSP करना होगा।
3. अधिकांश घटक रिलेशनल डेटाबेस और फ्रंट-एंड जावास्क्रिप्ट जैसे डोमेन पर अमूर्तता प्रदान करने की कोशिश करते हैं, और कई बार ये सार "लीक" होते हैं और डीबग करने में बहुत कठिन होते हैं।
4. ये सार किसी जूनियर डेवलपर या किसी विशेष डोमेन (जैसे फ्रंट-एंड जावास्क्रिप्ट) के साथ सहज नहीं होने के लिए एक अच्छा शुरुआती बिंदु हो सकता है, लेकिन प्रदर्शन के लिए अनुकूलन करने के लिए बहुत कठिन हैं, क्योंकि इसमें कई परतें शामिल हैं, और अधिकांश लोग जो उनका उपयोग करते हैं। हुड के नीचे क्या हो रहा है की कम समझ है।
5. टेम्प्लेटिंग मैकेनिज्म जो आमतौर पर JSF के साथ उपयोग किए जाते हैं, उनका वेब डिस्इगर्स के काम करने के साथ कोई लेना-देना नहीं है। JSF के लिए WYSIWYG संपादक आदिम हैं और किसी भी स्थिति में, आपका डिज़ाइनर आपको HTML / CSS देगा, जिसे परिवर्तित करने में आपको उम्र बितानी होगी।
6. ईएल एक्सप्रेशन जैसी चीजें स्टेटिकली चेक नहीं की जाती हैं और कंपाइलर और आईडीई दोनों ही एरर खोजने में अच्छा काम नहीं कर रहे हैं, इसलिए आप उन एरर को खत्म कर देंगे जिन्हें आपको रन-टाइम पर पकड़ना होगा। यह रूबी या PHP जैसी गतिशील रूप से टाइप की गई भाषा के लिए ठीक हो सकता है, लेकिन अगर मुझे जावा इकोसिस्टम के विशाल ब्लोट का सामना करना पड़ता है, तो मैं अपने टेम्प्लेट के लिए टाइपिंग की मांग करता हूं।

योग करने के लिए: जेएसएफ / सर्वलेट / बीन बॉयलरप्लेट कोड लिखने से बचने से लेकर, जेएसएफ के साथ आप जिस समय को बचाएंगे, आप इसे बनाने के लिए x10 खर्च करेंगे और ठीक वही करेंगे जो आप इसे करना चाहते हैं।

Comments

वह स्पष्ट रूप से JSF 1.x का उल्लेख कर रहा है और इस तथ्य को ध्यान में रखते हुए कि यह MVC फ्रेमवर्क आधारित घटक है, जबकि MVC फ्रेमवर्क को ध्यान में रखते हुए।

— बालुसक

1) यदि आप MVC आधारित घटक नहीं चाहते हैं, तो आप JSF को क्यों देख रहे हैं? 2) JSF 2.0 के बाद से नहीं। 3) डोमेन हिस्सा असत्य है। जेएसएफ घटकों में से कोई भी ऐसा नहीं करता है। जेएस फँसाना चाहे, ठीक है, वहाँ किसी भी हैं? Mojarra अभी के रूप में बहुत परिपक्व है। 4) JSF के पास वास्तव में एक कठिन सीखने की अवस्था है, लेकिन यह जरूरी नहीं है कि यह बुरा हो। 5) विजुअल एडिटर वैसे भी एपिक फेल हैं। फिर से, घटक बनाम अनुरोधित एमवीसी पदार्थ बनाम। 6) यह सही उपकरण की बात है, JSF की नहीं। ग्रहण में प्लगइन्स होते हैं और IntelliJ अल्टीमेट बॉक्स को पूरा करता है।

— बालुसक

अगर मुझे असम्मानजनक लगता है तो @BalusC ने मुझे माफ़ कर दिया, लेकिन सवाल JSF 1 बनाम JSF 2 नहीं है, और आपका जवाब जो "JSF का इतिहास" जैसा है, अप्रासंगिक है। इसके अलावा आपका दावा है कि जेएसएफ के "कोई गंभीर नुकसान नहीं है" यह मूलभूत इंजीनियरिंग सिद्धांत को स्वीकार करने में विफल रहता है कि सभी उपकरणों की अपनी सीमाएं और उनका डोमेन है जहां वे अन्य समाधान करते हैं।

— काय पाले

मैं इतिहास को यह जानने के लिए बहुत प्रासंगिक मानता हूं कि जेएसएफ 2.0 ने पुराने नुकसानों को कैसे समाप्त किया है क्योंकि यह वास्तव में उन नुकसान थे जिन्होंने जेएसएफ को इतिहास में एक नकारात्मक इमोजी दिया था। अवशेष के रूप में, अच्छी तरह से तो हम सिर्फ एक असहमति है।

— बालुसक

मैं ईमानदारी से नहीं समझता कि आप "घटक आधारित" को नुकसान के रूप में क्यों सूचीबद्ध करते हैं। यह कहने जैसा है कि "http का नुकसान यह है कि यह स्टेटलेस है" .. जिसे संपादित किया जाना चाहिए। यकीन है कि कभी-कभी तथ्य यह है कि http बेकार है बेकार है, लेकिन कभी-कभी यह ठीक है कि हम इसका उपयोग क्यों करते हैं। JSF के साथ भी ऐसा ही है।

— arg20

Answer 4

मेरे लिए JSF 2.0 का सबसे बड़ा नुकसान न केवल JSF का सीखने की अवस्था है, बल्कि इसके लिए उपयोगी काम करने के लिए आपको जिन घटक पुस्तकालयों का उपयोग करना है। वास्तव में कुशल होने के लिए आपके द्वारा निर्दिष्ट विनिर्देशों और मानकों की चौंका देने वाली संख्या पर विचार करें:

• विभिन्न अवतारों में एच.टी.एम.एल. बहाना मत करो तुम्हें यह जानने की जरूरत नहीं है।
• HTTP - जब आप यह पता नहीं लगा सकते हैं कि आपके पास क्या चल रहा है तो Firebug को खोलें और देखें। उसके लिए आपको यह जानना आवश्यक है।
• सीएसएस - यह पसंद है या नहीं। यह वास्तव में इतना बुरा नहीं है और कम से कम वहाँ कुछ अच्छे उपकरण हैं।
• एक्सएमएल - जेएसएफ संभवत: पहला स्थान है जहां आप इस डिग्री के लिए नामस्थान का उपयोग करते हैं।
• सर्वलेट विशिष्टता। जल्दी या बाद में आप इस पैकेज में कॉलिंग के तरीकों में जुट जाएंगे। इसके अलावा आपको यह जानना होगा कि आपका फेसलेट्स XHTML या जो भी हो, कैसे हो जाता है।
• JSP (ज्यादातर तो आप जानते हैं कि आपको JSF में इसकी आवश्यकता क्यों नहीं है)
• JSTL (फिर से, ज्यादातर विरासत ढांचे का सामना करने के लिए)
• अभिव्यक्ति भाषा (ईएल) अपने विभिन्न रूपों में।
• ECMAScript, जावास्क्रिप्ट, या जो भी आप इसे कॉल करना चाहते हैं।
• JSON - यदि आप इसका उपयोग नहीं करते हैं, तो भी आपको यह जानना चाहिए।
• AJAX। मैं कहूंगा कि JSF 2.0 आपसे इसे छिपाने का एक अच्छा काम करता है लेकिन आपको अभी भी जानना होगा कि क्या चल रहा है।
• डोम। और एक ब्राउज़र इसका उपयोग कैसे करता है। ECMAScript देखें।
• डोम इवेंट्स - एक विषय है।
• Java Persistence Architecture (JPA) यदि आप चाहते हैं कि आपके ऐप का कोई बैक एंड डेटा बेस हो।
• जावा ही।
• जब आप उस पर हों तो JSEE।
• प्रसंग निर्भरता इंजेक्शन विनिर्देश (सीडीआई) और यह जेएसएफ 2.0 के साथ कैसे उपयोग किया जाता है और कैसे टकराता है
• JQuery - मैं आपको इसके बिना प्राप्त करना देखना चाहता हूं।

अब, एक बार जब आप उस के साथ कर रहे हैं, तो आप मालिकाना विनिर्देशों के साथ प्राप्त कर सकते हैं, अर्थात घटक पुस्तकालयों और प्रदाता पुस्तकालयों को आप जिस तरह से साथ लेंगे:

• प्राइमफेस (मेरी पसंद का घटक पुस्तकालय)
• RichFaces
• MyFaces
• ICEFaces
• एक्लिप्सलिंक (मेरा जेपीए प्रदाता)
• हाइबरनेट
• वेल्ड

और कंटेनर मत भूलना! और उन सभी विन्यास फाइल:

• GlassFish (2, 3, आदि)
• JBoss
• बिल्ला

तो - यह आसान है? निश्चित रूप से, जेएसएफ 2.0 "आसान" है जब तक आप करना चाहते हैं, सबसे सरल वेब पेज सबसे सरल इंटरैक्शन के साथ हैं।

सीधे शब्दों में कहें, JSF 2.0 सबसे जटिल और बोझिल मिश्श्म है जो एक साथ प्रौद्योगिकियों के रूप में सज्जित है, जो आज सॉफ्टवेयर ब्रह्मांड में मौजूद है। और मैं ऐसा कुछ भी नहीं सोच सकता जो मैं उपयोग करूं।

Comments

यह ज्यादातर किसी अन्य वेब फ्रेमवर्क पर भी लागू होता है। यह JSF की गलती कैसे है कि आपको इसके साथ उत्पादक होने के लिए jQuery जानना है?

— एड्रियन ग्रिगोर

JSF सिर्फ दृश्य परत है। अब आपको लगने लगा है कि अन्य तकनीकों के साथ आपको यह सब जानने की जरूरत नहीं है, क्या आप हमें दिखा सकते हैं?

— arg20

यद्यपि वे प्रौद्योगिकियां खुला स्रोत हैं, वे निजी संगठनों के लिए दृढ़ता से बाध्य हैं जो उन्हें बनाए रखते हैं। शायद मालिकाना शब्द आपके लिए सही नहीं है, लेकिन वे भी हो सकते हैं।

— एलनबोब्जेक्ट

मैं @AlanObject के बचाव में आना चाहूंगा ... मुझे लगता है कि वह मालिकाना कहने से मतलब हो सकता है, जैसा कि इस तथ्य में है कि सभी खुले स्रोत परियोजनाएं, वास्तव में किसी के द्वारा "स्वामित्व" हैं। उदाहरण के लिए MySQL ले लो। जब उन्होंने ओरेकल को बेचा तो उन्होंने वास्तव में बड़ा स्कोर किया। जैसा कि, जावा ने भी किया था !! इसलिए, कई बार ओपन सोर्स प्रोजेक्ट्स, भले ही वे उपयोग / संपादित / योगदान करने के लिए खुले हों, फिर भी प्रत्येक ओपन सोर्स टूल में निहित विशिष्टताओं के अधीन होते हैं, जो आप वर्तमान में उपयोग कर रहे हैं। किसी के द्वारा "मालिक" होने के कारण। आप उन चश्मे को अनदेखा नहीं कर सकते जो उनका उपयोग करने के लिए आवश्यक हैं। ऐसा नहीं है कि यह एक बुरी बात है :)

— CA मार्टिन

Answer 5

1. अनुभवहीन डेवलपर्स आमतौर पर ऐसे अनुप्रयोगों का निर्माण करेंगे जो दर्द से धीमा हैं और कोड बनाए रखने के लिए वास्तव में बदसूरत और कठिन होगा। भ्रामक रूप से शुरू करने के लिए सरल है, लेकिन वास्तव में सीखने में कुछ निवेश की आवश्यकता है यदि आप अच्छे कार्यक्रम लिखना चाहते हैं।
2. कम से कम शुरुआत में आप अक्सर किसी न किसी समस्या पर "अटक" जाते हैं और वास्तव में काम करने की तुलना में इंटरनेट पर balusc पोस्ट पढ़ने में अधिक समय बिताएंगे :) थोड़ी देर बाद यह कम और कम हो जाएगा, लेकिन यह अभी भी कष्टप्रद हो सकता है।
3. इससे भी अधिक कष्टप्रद जब आपको पता चलता है कि समस्या आपके ज्ञान / गलती की कमी के कारण नहीं है बल्कि वास्तव में एक बग है। मोअज़रा (था?) काफी छोटी है, और घटकों की एक और परत और भी अधिक समस्याएं जोड़ती है। रिचफेसेस क्रैप सॉफ्टवेयर का अब तक का सबसे बड़ा टुकड़ा था :) न जाने कैसे यह अब संस्करण 4 पर है। हमारे पास प्राइमफेस है जो बेहतर है, लेकिन फिर भी आप विशेष रूप से अधिक विदेशी घटकों के साथ बग या सुविधाओं की कमी में दौड़ेंगे। और अब आपको Primefaces अपडेट के लिए भुगतान करना होगा। तो मैं कहूंगा कि इसकी छोटी गाड़ी है, लेकिन इसके बेहतर होने के बाद विशेष रूप से 2.2 संस्करण ने कल्पना के साथ कुछ समस्याएं तय की हैं। फ्रेमवर्क अधिक परिपक्व हो रहा है, लेकिन अभी भी एकदम सही है (शायद बेहतर तरीके से?)।
4. मुझे यह विशेष रूप से लचीला नहीं लगता। अक्सर अगर आपको कुछ बहुत ही अनुकूलित की आवश्यकता होती है और कोई घटक नहीं होता है जो ऐसा करता है - यह थोड़ा दर्दनाक होगा। फिर से मैं औसत डेवलपर परिप्रेक्ष्य से बात कर रहा हूं - एक जो डेडलाइन, त्वरित पढ़ने के ट्यूटोरियल, और स्टैकओवरफ़्लो की खोज करता है, जब अटक जाता है क्योंकि यह जानने का कोई समय नहीं है कि यह वास्तव में कैसे काम करता है :) अक्सर कुछ घटकों को "लगभग" लगता है कि आपको क्या चाहिए, लेकिन ठीक नहीं है और कभी-कभी आप इसे बनाने के लिए बहुत अधिक समय खर्च कर सकते हैं। आप चाहते हैं :) यह मूल्यांकन करने में सावधानी बरतने की आवश्यकता है कि क्या यह बेहतर है कि आप अपना स्वयं का या मौजूदा घटक को यातना दें। वास्तव में यदि आप वास्तव में कुछ अनूठा बना रहे हैं तो मैं JSF की सिफारिश नहीं करूंगा।

तो संक्षेप में मेरी कमियां होंगी: जटिलता, बहुत चिकनी विकास प्रगति, छोटी गाड़ी, अनम्य।

बेशक इसके फायदे भी हैं, लेकिन आपने ऐसा नहीं पूछा। वैसे भी फ्रेमवर्क के साथ मेरा अनुभव अन्य लोगों के लिए अलग-अलग राय हो सकता है, इसलिए सबसे अच्छा तरीका यह है कि कुछ समय के लिए यह देखने की कोशिश करें कि क्या आपके लिए (बस कुछ और जटिल - भोली उदाहरण नहीं - जेएसएफ वास्तव में वहां चमकता है :) IMHO के लिए सबसे अच्छा उपयोग मामला JSF CRM आदि जैसे व्यावसायिक अनुप्रयोग हैं ...

Answer 6

"JSF व्यू-लेयर HTML और जावास्क्रिप्ट को आउटपुट करेगा जिसे आप कंट्रोलर कोड में जाए बिना कंट्रोल या चेंज नहीं कर सकते।"

वास्तव में JSF आपको लचीलापन देता है, आप या तो मानक / तीसरे पक्ष के घटकों का उपयोग कर सकते हैं या अपना खुद का बना सकते हैं, जिस पर आपका पूरा नियंत्रण है। यह सिर्फ एक एक्सएचटीएमएल है जिसे आपको जेएसएफ 2.0 के साथ अपने कस्टम घटक बनाने की आवश्यकता है।

Answer 7

मैं एक जावा सर्वर चेहरे विशेषज्ञ बिल्कुल नहीं हूँ। लेकिन IMHO मुख्य नुकसान यह है कि यह सर्वर साइड है। मैं ASP.NET वेब फॉर्म्स, ASP.NET MVC, जावा सर्वर फ़ेस, स्ट्रट्स, php चौखटे और रूबी चौखटे पर रूबी जैसे सर्वर साइड वेब प्रेजेंटेशन लेयर फ्रेमवर्क को सीखने और उपयोग करने से थक गया हूँ। मैंने उन सभी को अलविदा कहा, और मैंने एंगुलरज और टाइपस्क्रिप्ट को नमस्ते कहा। मेरी प्रस्तुति परत ब्राउज़र पर चलती है। मुझे इससे कोई फर्क नहीं पड़ता कि यह Windows IIS रनिंग php या ASP.NET द्वारा सेवित है, या यदि यह लिनक्स पर चलने वाले Apache वेब सर्वर द्वारा परोसा जाता है। मुझे सिर्फ एक फ्रेमवर्क सीखने की जरूरत है जो हर जगह काम करता है।

केवल मेरे दो सेंट्स।

Comments

और यह मत भूलो कि प्रत्येक क्लाइंटसाइड फ्रेमवर्क, सुरक्षा, सत्यापन आदि के लिए एकरवरसाइड समकक्ष की आवश्यकता है

— कुक्टेलजे

हां बिल्कुल। न केवल सुरक्षा और सत्यापन के लिए, बल्कि बैकएंड और बिजनेस लॉजिक के लिए। सभी restfull वेब सेवाओं के माध्यम से किया जाता है। यहाँ मुद्दा यह है कि सर्वर साइड पर html बनाने से बचें।

— जेसु लोजेज़

Answer 8

हमने JSF के साथ एक नमूना परियोजना विकसित की (यह एक तीन सप्ताह का शोध था इसलिए हम कुछ चीजों को खो सकते हैं!)

हम कोर जेएसएफ का उपयोग करने की कोशिश करते हैं, अगर एक घटक की आवश्यकता होती है तो हम प्राइमफेस का उपयोग करते हैं।

परियोजना नेविगेशन के साथ एक वेब साइट थी। मेनू क्लिक होने पर प्रत्येक पृष्ठ को अजाक्स के माध्यम से लोड किया जाना चाहिए।

साइट में दो usecases हैं:

1. ग्रिड वाला एक पृष्ठ। ग्रिड को अजाक्स के माध्यम से लोड किया गया है और इसे सॉर्ट और पेजिंग का समर्थन करना चाहिए
2. एक तीन कदम विज़ार्ड पृष्ठ। प्रत्येक पृष्ठ में क्लाइंट साइड सत्यापन (सरल सत्यापन के लिए) और सर्वर साइड एजैक्स आधार सत्यापन (जटिल सत्यापन के लिए) है। किसी भी सर्वर अपवाद (सेवा परत से) को अगले पृष्ठ पर नेविगेट किए बिना विज़ार्ड के एक ही पृष्ठ पर प्रदर्शित किया जाना चाहिए।

हमने पाया कि:

1. JSF व्यू स्टेट को निश्चित करने के लिए आपको omniFaces के कुछ हैक्स का उपयोग करने की आवश्यकता है। JSF राज्य दूषित हो जाएगा जब आप एक दूसरे में ajax के माध्यम से पृष्ठों को शामिल करेंगे। यह जेएसएफ में एक बग लगता है और अगले रिलीज (2.3 में नहीं) पर तय किया जा सकता है।
2. जेएसएफ फ्लो अजाक्स के साथ सही तरीके से काम नहीं कर रहा है (या हम इसे काम नहीं कर सकते!) हम इसके बजाय प्राइमफेस विजार्ड घटक का उपयोग करने की कोशिश करते हैं लेकिन क्लाइंट सत्यापन समर्थित नहीं है और इसका मतलब नहीं है जबकि यह मानक जेएसएफ प्रवाह मानक नहीं था।
3. JqGird जैसे कुछ jQuery के घटकों का उपयोग करते समय, और आपको JSON परिणाम लोड करने की आवश्यकता होती है, तो आपको शुद्ध सर्वलेट का उपयोग करने की सलाह दी जाती है, JSF आपके लिए कुछ नहीं करेगा। इसलिए यदि आप इस तरह के घटकों का उपयोग करते हैं, तो आपका डिज़ाइन JSF में फिट नहीं होगा।
4. हम कुछ क्लाइंट स्क्रिप्ट्स करने की कोशिश करते हैं, जब अजाक्स पूरा हो जाता है ajaxCompleteऔर हमने पाया कि पीएफ 4 ने अपनी स्वयं की अजाक्स घटनाओं को लागू किया है। हमारे पास कुछ jQuery घटक थे और हमें उनका कोड बदलने की आवश्यकता है।

यदि आप उपरोक्त नमूने को गैर अजाक्स में बदलते हैं परियोजना में (या कम से कम ajax परियोजना) तो आपको उपरोक्त कई मुद्दों का सामना नहीं करना पड़ेगा।

हम अपने शोध को इस प्रकार प्रस्तुत करते हैं:

जेएसएफ पूरी तरह से अजाक्स आधार वेबसाइट में अच्छा काम नहीं कर रहा है।

निश्चित रूप से हमें जेएसएफ में बहुत सारी अच्छी सुविधाएँ मिलती हैं जो कुछ परियोजनाओं में बहुत सहायक हो सकती हैं, इसलिए अपनी परियोजना की जरूरतों पर विचार करें।

कृपया JSF लाभों की समीक्षा करने के लिए JSF तकनीकी दस्तावेजों का संदर्भ लें, और मेरी राय में JSF का सबसे बड़ा फायदा, @BalusC; COMPLETE और HUGE का समर्थन; ;-)

Answer 9

मेरे लिए जेएसएफ की सबसे बड़ी कमी प्रोग्रामेटिकली (डायनामिकली) जेनरेट किए गए पेजों के लिए खराब सपोर्ट है।
यदि आप जावा कोड से अपने पृष्ठ (पेज कंपोनेंट मॉडल बनाएं) का निर्माण करना चाहते हैं। उदाहरण के लिए यदि आप WYSIWYG वेब पेज कंस्ट्रक्टर पर काम कर रहे हैं। इस उपयोग के मामले का पर्याप्त प्रलेखन आम तौर पर उपलब्ध नहीं है। ऐसे कई बिंदु हैं जहां आपको प्रयोग करना है और विकास धीमा है। बहुत सी चीजें बस काम नहीं करती हैं कि आप कैसे उम्मीद करेंगे। लेकिन आम तौर पर इसके संभावित हैक ने इसे किसी तरह से हैक कर लिया।
अच्छी बात यह है कि यह जेएसएफ के दर्शन या वास्तुकला में समस्या नहीं है। यह पर्याप्त रूप से विस्तृत नहीं है (जहाँ तक मुझे पता है)।

JSF 2 ने कंपोजिट कंपोनेंट्स लाए, जो कंपोनेंट डेवलपमेंट को आसान बनाने चाहिए, लेकिन डायनामिक (प्रोग्रामेटिक) कंस्ट्रक्शन के लिए उनका सपोर्ट बहुत खराब है। यदि आप गतिशील कम्पोजिट घटक के शांत जटिल और लगभग अनजाने प्रक्रिया को पार कर लेते हैं, तो आपको पता चलेगा कि यदि आप कुछ कंपोजिट घटकों को थोड़ा गहरा करते हैं, तो वे कुछ अपवादों को फेंकते हुए काम करना बंद कर देते हैं।

लेकिन ऐसा लगता है कि जेएसएफ समुदाय इस कमियों से अवगत है। वे इस पर काम कर रहे हैं जैसा कि आप इन दो बगों से देख सकते हैं
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

यदि हम विनिर्देश के बारे में बात कर रहे हैं तो कम से कम JSF 2.2 के साथ स्थिति बेहतर होनी चाहिए।

Answer 10

मेरे पिछले कुछ महीनों के प्राइमफेस / जेएसएफ अनुभव पर टिप्पणी करना:

• यदि आप "शेल्फ से" घटकों का उपयोग कर सकते हैं, तो मुझे लगता है कि यह भयानक नहीं है।
• हालाँकि, जैसे ही आप बाहर कदम रखते हैं और कस्टम UI की आवश्यकता होती है, यह अच्छा नहीं खेलता है। - उदाहरण के लिए, हमें अपने प्रोजेक्ट के लिए ट्विटर के बूटस्ट्रैप का उपयोग करने की आवश्यकता थी। (बूटस्ट्रैप नहीं है)।
  • अब हमारे पृष्ठ निम्नानुसार काम करते हैं:
    • पेज लोड होता है।
    • उपयोगकर्ता एक ऐसे इंटरफेस के साथ सहभागिता करता है जिसमें अजाक्स कार्यक्षमता होती है
    • बूटस्ट्रैप की जावास्क्रिप्ट बाइंडिंग टूट जाती है
    • हम सब कुछ रिबंड करने के लिए अतिरिक्त जावास्क्रिप्ट चलाते हैं

जेएसएफ लिखने से बचने के लिए जेएसएफ का वादा और अधिक जावास्क्रिप्ट लिखने में बदल गया, अगर हम प्राइमफेस का उपयोग नहीं कर रहे हैं - और उस जावास्क्रिप्ट को ठीक करना है जो प्राइमफेस को तोड़ता है।

यह एक समय सिंक है - जब तक आप फिर से "शेल्फ से दूर" सामान का उपयोग नहीं करते। सेलेनियम के साथ काम करने पर भी वास्तव में बदसूरत (प्राइमफेस)। यह सब किया जा सकता है - लेकिन फिर से - केवल इतना समय है।

निश्चित रूप से इससे बचें यदि आप एक यूएक्स / डिज़ाइन टीम के साथ काम कर रहे हैं और यूआई पर तेजी से पुनरावृत्ति करने की आवश्यकता है - तो आप jquery सीखने / सीधे HTML लिखने से समय बचा सकते हैं - या प्रतिक्रिया / कोणीय देख सकते हैं।

Comments

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

— कुकटेलजे

यहाँ एक सेलेनियम उदाहरण है। HTLM चेकबॉक्स: <input type="checkbox" name="versionsTab" value="version1"> प्राइमस्पेस चेकबॉक्स: <div class="ui-chkbox ui-widget"> <div class="ui-helper-hidden-accessible"> <input type="checkbox" name="datasetForm:tabView:versionsTable_checkbox"> </div> <div class="ui-chkbox-box ui-widget ui-corner-all ui-state-default"> <span class="ui-chkbox-icon ui-c"></span> </div> </div> सेलेनियम वास्तविक चेकबॉक्स नहीं खोज सका जो छिपा हुआ है। उदाहरण के लिए, मैं इसे चयनकर्ताओं / कोडिंग / आदि के साथ पा सकता था, लेकिन नहीं के रूप में तकनीकी क्यूए टीम नहीं कर सकी

— rprasad

आपका मतलब संक्षिप्त नाम है? सुंदरता देखने वाले की नजर में है। यदि आप थोड़ी सी xpath सीखते हैं, तो इसे बहुत परेशानी के बिना दरकिनार किया जा सकता है। और यह विशेष रूप से पीएफ की चीज नहीं है। और डिजाइन टीम की चीजों के बारे में। उन्हें टेम्पलेट डिज़ाइन करने दें और बाकी के लिए jquery-ui दिशानिर्देशों का पालन करें। हमारे लिए पूरी तरह से काम किया ...

— १६:४ कुक्टेलजे

मैं बाद में परियोजना में शामिल हो गया लेकिन इस प्रस्तुति के समान मुद्दे जहां परियोजना बूटफस के साथ शुरू हुई, लेकिन वास्तव में पूर्ण बूटस्ट्रैप (+ प्राइमफेस) की आवश्यकता थी: oracleus.activeevents.com/2014/connect/…

— rprasad

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

— rprasad

Answer 11

जेएसएफ के कई फायदे हैं, सवाल यह है कि मुझे नुकसान हो रहा है।

समय सीमा के साथ एक वेब परियोजना को लागू करने के व्यावहारिक परिदृश्य पर आपको निम्नलिखित कारकों पर नजर रखने की आवश्यकता है।

• क्या आपके पास अपनी टीम में पर्याप्त वरिष्ठ सदस्य हैं जो प्रत्येक परिदृश्य के लिए सबसे अच्छा नियंत्रण सुझा सकते हैं?

• क्या आपके पास प्रारंभिक सीखने की अवस्था को समायोजित करने के लिए बैंडविड्थ है?

• क्या आपके पास अपनी टीम में पर्याप्त विशेषज्ञता है जो
  डेवलपर्स द्वारा उत्पादित जेएसएफ सामान की समीक्षा कर सकते हैं ?

यदि आपका उत्तर प्रश्नों के लिए 'नहीं' है, तो आप एक गैर-रखरखाव योग्य कोडबेस में समाप्त हो सकते हैं।

Answer 12

जेएसएफ का केवल एक नुकसान है: "जेएसएफ" विकास शुरू करने से पहले आपको वेब विकास, कोर जावा और फ्रंट-एंड आर्किटेक्चर को स्पष्ट रूप से समझना चाहिए।

आजकल "नए" जावास्क्रिप्ट ढांचे सिर्फ "जेएसएफ" घटक-आधारित मॉडल को कॉपी / पेस्ट करने की कोशिश करते हैं।

Answer 13

स्प्रिंग एमवीसी, विकेट, टेपेस्ट्री आदि सभी "मुख्य धारा" रूपरेखाओं में, जावा ईई का जेएसएफ अपने समग्र घटकों के साथ सबसे विस्तृत प्रस्तुति-परत और घटक-उन्मुख तकनीक प्रदान करता है। यह HybridJava द्वारा प्रदान किए गए समाधानों की तुलना में थोड़ा बोझिल और अधूरा है।