JSF का उपयोग करने के कारण [बंद]


64

मैं StackExchange में नया हूं, लेकिन मुझे लगा कि आप मेरी मदद कर पाएंगे।

हम एक नया जावा एंटरप्राइज एप्लिकेशन तैयार कर रहे हैं, जो एक विरासत JSP समाधान की जगह ले रहा है। कई कई परिवर्तनों के कारण, यूआई और व्यापार तर्क के कुछ हिस्सों को पूरी तरह से पुनर्निर्मित और पुन: लागू किया जाएगा।

हमारा पहला विचार JSF था, क्योंकि यह जावा EE में मानक है। पहले तो मुझे अच्छा आभास हुआ। लेकिन अब मैं एक कार्यात्मक प्रोटोटाइप को लागू करने की कोशिश कर रहा हूं, और इसका उपयोग करने के बारे में कुछ गंभीर चिंताएं हैं।

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

दूसरे, यह रास्ता बहुत जटिल है। इसकी जटिलता बकाया है। यदि आप मुझसे पूछते हैं, तो यह मूल वेब तकनीकों का एक खराब अमूर्त हिस्सा है, जो अंत में अपंग और बेकार है। मुझे क्या लाभ है? कोई नहीं, अगर आप इसके बारे में सोचते हैं। सैकड़ों घटक? मुझे दस-हजारों HTML / CSS स्निपेट्स, दस-हजारों जावास्क्रिप्ट स्निपेट्स और हजारों jQuery प्लग-इन दिखाई दे रहे हैं। यह वास्तव में कई समस्याओं का हल करता है - अगर हम JSF का उपयोग नहीं करते तो हमारे पास नहीं होता। या फ्रंट-कंट्रोलर पैटर्न बिल्कुल।

और अंत में, मुझे लगता है कि हमें 2 वर्षों में शुरू करना होगा। मैं यह नहीं देखता कि मैं अपने पहले जीयूआई मॉक-अप को कैसे लागू कर सकता हूं (इसके अलावा, हमारी टीम में कोई जेएसएफ विशेषज्ञ नहीं है)। शायद हम इसे किसी तरह एक साथ हैक कर सकते थे। और तब और भी होगा। मुझे यकीन है कि हम अपना हैक हैक कर सकते हैं। लेकिन कुछ बिंदु पर, हम अटक जाएगा। सेवा स्तरीय के ऊपर सब कुछ के कारण JSF का नियंत्रण है। और हमें शुरू करना होगा।

मेरा सुझाव JAX-RS का उपयोग करके REST एपि को लागू करना होगा। फिर क्लाइंट साइड MVC के साथ एक HTML5 / जावास्क्रिप्ट क्लाइंट बनाएं। (या MVC का कुछ स्वाद ..) वैसे; हमें वैसे भी REST एपीआई की आवश्यकता होगी, क्योंकि हम एक आंशिक एंड्रॉइड फ्रंट-एंड भी विकसित कर रहे हैं।

मुझे संदेह है, कि जेएसएफ आजकल सबसे अच्छा समाधान है। जैसा कि इंटरनेट विकसित हो रहा है, मैं वास्तव में यह नहीं देखता कि हमें इस 'रेक' का उपयोग क्यों करना चाहिए।

अब, क्या पेशेवरों / विपक्ष हैं? मैं JSF का उपयोग न करने के लिए अपनी बात पर कैसे जोर दे सकता हूं? मेरे सुझाव पर JSF का उपयोग करने के लिए मजबूत बिंदु क्या हैं?


24
यह एक नए उपयोगकर्ता का एक लिखित प्रश्न है। एक टिप्पणी छोड़ने पर विचार करें जब downvoting।
ThiefMaster

2
चूंकि आप वह सब कुछ लिख रहे हैं जो मैं न केवल जेएसएफ का उपयोग करने पर विचार करूंगा बल्कि जावा का उपयोग नहीं करने पर भी विचार करूंगा। आधुनिक पटकथा भाषाओं (यानी नहीं PHP या पर्ल) बहुत अच्छा और डेवलपर के अनुकूल है।
ThiefMaster

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

4
यदि आपकी एप्लिकेशन बहुत बड़ी है (या तो जटिल और / या स्केलेबल) और / या वितरित की जा रही है, तो कई विकल्प हैं। यदि आपका आवेदन इस श्रेणी में फिट नहीं है (यह इतना जटिल नहीं है और इसे स्केलेबल होने की आवश्यकता नहीं है) तो पायथन (Django) या रूबी (रेल्स) बेहतर विकल्प होंगे। जेएसएफ की जटिलता, इसके साथ आने वाली शक्ति का लाभ है; इसके विकल्प के रूप में आपको अन्य वेब फ्रेमवर्क जैसे स्प्रिंग एमवीसी या स्ट्रट्स 2 पर एक नज़र डालनी चाहिए यदि जावा अनिवार्य है।
m3th0dman

14
यह बैकअप के लिए एक शेख़ी है, इस तरह का सवाल नहीं है।

जवाबों:


26

जेएसएफ पर विचार करने के लिए कम से कम एक बहुत अच्छा कारण है।

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

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


4
मैं इस बारे में निश्चित नहीं हूं। J2EE के लिए, 'मानक' और 'वर्किंग' शब्द पत्थर में नहीं लिखे गए हैं, विशेष रूप से जब हम एक ऐसी प्रणाली पर बात करते हैं, जिसका उपयोग कई वर्षों तक किया जाना चाहिए, जिसमें उपयोग किए जाने वाले j2ee के संस्करण में परिवर्तन शामिल हैं।
मैगलन

7
जेएसएफ के साथ मेरे (सीमित) अनुभव में यह तर्क वास्तव में पकड़ में नहीं आता है। मैंने जेएसएफ के एक संस्करण और नए संस्करण के लिए कोई भी माइग्रेशन पथ के साथ अटक जाने वाले अनुप्रयोगों को नहीं देखा है। सुनिश्चित करें कि ऐप सर्वर ने अभी भी इसे निष्पादित किया है, लेकिन अगर आप ओवरराइड समर्थन अनुबंधों को जलाने के लिए बड़ी मात्रा में पैसा नहीं कमाते तो आपको मिलने वाले सभी समर्थन के बारे में था।
जेन्स स्काउडर

@JensSchauder मेरा अनुभव सिर्फ इतना है कि आप पोर्टेबल एप्लिकेशन लिख सकते हैं, उनका संस्करण jsf में माइग्रेट और अपग्रेड कर सकते हैं। इसमें कल्पना को जानना और इसे लागू करना शामिल है, इसके कार्यान्वयन के लिए नहीं। यह काम करता है, हाइबरनेट कार्यों के बजाय जेपीए के लिए कोडिंग के रूप में। वर्षों से कर रहे हैं।
यमजोरोस

14

अब, क्या पेशेवरों / विपक्ष हैं? मैं JSF का उपयोग न करने के लिए अपनी बात पर कैसे जोर दे सकता हूं? मेरे सुझाव पर JSF का उपयोग करने के लिए मजबूत बिंदु क्या हैं?

आप पहले से ही अपने दिमाग को विपक्ष के बारे में बना चुके हैं, और मुझे उनमें से कुछ से अलग होना है (यह लेआउट और तर्क को अलग नहीं करता है, और परिणामस्वरूप HTML अक्सर अत्याचार करता है), लेकिन दूसरों पर असहमत (यदि आप उपयोग करते हैं) फेसलेट्स, जिन्हें मैं बहुत सुझाऊंगा, फिर आउटपुट निश्चित रूप से मान्य होना चाहिए)।

तो यहाँ कुछ पेशेवरों:

  • कुछ बहुत शक्तिशाली घटक लाइब्रेरी हैं जैसे कि PrimceFaces या RichFaces जो बॉक्स से बहुत अधिक कार्यक्षमता प्रदान करते हैं। यदि वे आपकी आवश्यकताओं को कवर करते हैं (यदि आप उनके द्वारा कवर नहीं किए गए गैर-परक्राम्य आवश्यकताएं हैं तो बहुत अधिक नहीं) ये आपको बहुत सारे काम बचा सकते हैं।
  • समग्र घटक आपके पृष्ठों को संशोधित करने के लिए एक बहुत ही स्वच्छ तरीका प्रदान करते हैं
  • जेएसएफ बाकी जावा ईई के साथ बहुत अच्छी तरह से एकीकृत करता है
  • AJAX के घटक पुन: प्रतिपादन वास्तव में आसान और सुविधाजनक है

लेकिन निश्चित रूप से इन लाभों में से कोई भी इतना बड़ा नहीं है कि आपको जेएसएफ का उपयोग किसी अन्य ढांचे पर करना चाहिए जो आपकी टीम के पास पहले से ही अनुभव है।


1
यह आईडी नहीं है, यह अमान्य विशेषताएँ हैं। टैब दृश्य में "भूमिका" और "आरिया-विस्तारित" की तरह। क्या आप जानते हैं कि इसे कैसे ठीक किया जाए?
ब्रूनो शेपर

1
@ मुख्य: नहीं, एक अलग मुद्दा लगता है, शायद एक घटक के साथ जिसका मैंने उपयोग नहीं किया या जो नया है। वैकल्पिक रेंडरर निर्दिष्ट करके जेएसएफ घटकों के HTML आउटपुट को बदलना संभव है (जो आदर्श रूप से डिफ़ॉल्ट रेंडरर के एक या दो तरीकों को ओवरराइड करता है), लेकिन निश्चित रूप से यह ऐसा कुछ नहीं है जो आपको केवल वैध मार्कअप प्राप्त करने के लिए करना चाहिए।
माइकल बोर्गवर्ड

1
उपयोग किए गए कार्यान्वयन के कारण अत्याचारी HTML है। यह मेरी समझ है कि संदर्भ JSF कार्यान्वयन का डिबग मोड इस पर विशेष रूप से खराब है। क्या आप बेहतर HTML का निर्माण करने के लिए बेहतर सेटिंग्स के बारे में जानते हैं?

1
@ Thorbjørn Ravn Andersen हाँ, अमान्य HTML की समस्या वास्तव में प्राइमफेस की समस्या है। हम इसका उपयोग करते हैं क्योंकि यह jQuery-UI पर निर्मित है। आपकी क्या सलाह है; क्या मुझे अन्य पुस्तकालय का उपयोग करना चाहिए? मुझे वास्तव में मान्य HTML पसंद है। मेरे लिए यह केवल एक जरूरी है।
ब्रूनो शापर

1
यहाँ अपने पहले प्रश्न पर फिर से विचार करते हुए, मैं आपके पेशेवरों के बारे में कुछ अनुभव साझा करना चाहूंगा: हम JSF के साथ काम कर रहे हैं, और उस अनुभव के साथ हम इसे फिर से नहीं चुनेंगे। बमुश्किल कुछ भी उम्मीद के मुताबिक और बॉक्स से बाहर काम करता है। हाँ, शक्तिशाली पुस्तकालय हैं। लेकिन हमने अपने सभी घटकों को खुद करना समाप्त कर दिया, क्योंकि वे बहुत काम नहीं करेंगे क्योंकि हमें इसकी आवश्यकता थी। यह आश्चर्यजनक है कि स्क्रॉल करते समय आलसी लोडिंग के साथ हमारा अपना 'डेटाटेबल' कितना तेज था। समग्र घटक हमारे लिए काम नहीं करते, मैं आपको बता नहीं सकता कि, वे क्यों छोटी गाड़ी हैं जो मुझे लगता है। AJAX री-रेंडरिंग वास्तव में क्लाइंट साइड JS के लिए एक दर्द है।
ब्रूनो शेपर

9

JSF जावा के लिए पर्याप्त स्टेटफुल वेब फ्रेमवर्क है जो एक मानक है जिसका अर्थ है कि कई प्रमुख विक्रेताओं (FOSs सहित) द्वारा बॉक्स से बाहर समर्थित है। इसमें मजबूत 3 पार्टी लाइब्रेरी सपोर्ट (प्राइमफेस, आइसफेस आदि) है। हालांकि, यह अपने स्टेटफुल नेचर (और अन्य चीजों का एक गुच्छा) के कारण मौलिक रूप से 'वेब को तोड़ देता है'। जेवीएम आधारित वेब फ्रेमवर्क की मैट राईबल की तुलना देखें , जेएसएफ आमतौर पर अंतिम के करीब आता है।

संपादित करें - JSF 2.2 के साथ - आप यह तर्क देना शुरू कर सकते हैं कि यह वेब को उतना नहीं तोड़ता जितना उसने एक बार किया था। वास्तव में यह HTML5 एकीकरण सभी भयानक :-) नहीं है।


1
यह 'वेब को तोड़ता है', वास्तव में .. और मैट रायबल की तुलना के लिए धन्यवाद, यह नहीं पता था।
ब्रूनो शापर

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

फेयर पॉइंट अर्जन, मुझे लगता है कि मैंने अभी कई राजकीय उपयोगों को देखा है।
मार्टिज़न वेरबर्ग

: के लिए RAIBLE की प्रस्तुति लिंक slideshare.net/mraible/...
zaidaus

6

हम एक विरासत JSP / स्ट्रट्स 1.0 आवेदन किया था। हमने स्ट्रट्स 2, जेएसएफ और अन्य सभी चीजों को छोड़ दिया है जो स्ट्रट्स 1 के बाद से हुआ है और स्प्रिंग 3.0 में कूद गया है। हमारी इच्छा सूची के लिए इसका समर्थन (और एक सक्रिय समुदाय) है - ग्रहण आईडीई, एमवीसी और रीस्ट। इसके अलावा हम jquery के लिए हमारे विंटेज होमग्राउन जावास्क्रिप्ट / अजाक्स को खाई।

YMMV लेकिन स्प्रिंग हमारे लिए एक सहज प्रवास रहा है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.