क्या एक जटिल ईएल एक्सप्रेशन को एक सिंगल जाबबीन गेट्टर द्वारा प्रतिस्थापित किया जाना चाहिए?

10

जेएसएफ में अगर मेरे पास एक घटक है जो सशर्त रूप से कई चर पर आधारित है, तो रेंडर स्टेटमेंट को संभालने का इष्टतम तरीका क्या है ... क्या तर्क को घटक घोषणा में या किसी सहायक वर्ग में रहना चाहिए?

पाठ वूफ केवल तभी प्रदर्शित किया जाता है जब कोई जानवर हाथी या कुत्ता हो और जानवर मूक न हो।

विकल्प 1:

दृश्य में कार्यान्वयन:

<h:outputText id="text" value="woof" 
  rendered="#{animal.type == 'elephant' 
                  or animal.type == 'dog' and not(animal.mute)}"/>

या विकल्प 2:

encapsulation:

<h:outputText id="text" value="woof" rendered="#{animal.barkingAnimal}"/>

कार्यान्वयन के साथ:

public class Animal {
     public boolean isBarkingAnimal() {
         return ("dog".equals(getType()) || "elephant".equals(getType())) && !isMute();
     }
...

तो दोनों काम करते हैं ... लेकिन परिदृश्य को संभालने का सही तरीका क्या है?

jsf

— दूरभाष
स्रोत

उस विशेष उदाहरण के लिए मैं एल का उपयोग करूंगा। यह केवल संबंधित डेटा को देखने के लिए लगता है। यदि आपके पास अपने जावा कोड में कुछ तर्क हैं, तो barking animalsमैं उस पद्धति को कॉल करूंगा, क्योंकि यह पहले से मौजूद है। यदि इसका एक व्यू लॉजिक आप कई साइटों पर उपयोग करते हैं, तो आप इससे एक el फंक्शन बना सकते हैं।

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

— मैकडॉवेल

5

ज्यादातर मामलों में, यह केवल एक स्वाद का मामला है। यदि आपकी चिंता बस स्थिति का पुन: उपयोग कर रही है, तो आप ऐसा कर सकते हैं:

<ui:param name="animalCanBark" value="#{animal.type == 'elephant' 
              or animal.type == 'dog' and not(animal.mute)}" />
...
<h:outputText id="text" value="woof" rendered="#{animalCanBark}"/>

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

<ui:param name="showBarking" value="#{animal.type == 'elephant'
              and not facesContext.validationFailed" />

मुझे लगता है कि बहुत से लोग इस प्रकार के तर्क को ईएल के बजाय जावा में लिखना पसंद करते हैं क्योंकि जावा कंपाइलर जावा कोड में टाइप चेकिंग कर सकता है (साथ ही, ज्यादातर आईडीई के पास जावा के लिए बेहतर ऑटोकंप्लीशन है। एक्सएचटीएमएल फ़ाइलों के लिए), जो एक चिंता का विषय है। कुछ के लिए।

यह कहने के बाद कि, यदि यह उस मॉडल के बारे में जानकारी है जो किसी अन्य स्थान पर इस्तेमाल किया जा सकता है (न कि किसी अन्य फेसलेट्स / जेएसएफ पृष्ठ पर), तो यह आपके जावा कोड में होने का एक अच्छा कारण होगा। आपके द्वारा दिए गए उदाहरण में, विधि isBarkingAnimal()मॉडल के बारे में कुछ जानकारी देती है ( Animal), जो किसी दिन तब उपयोगी हो सकती है जब किसी अन्य वस्तु (न कि केवल दूसरे फेसलेट्स पृष्ठ) को यह जानना हो कि क्या किसी दिए गए जानवर की छाल है। तो, मैं शायद उसके साथ जाऊंगा।

— एलियास
स्रोत

3

अंगूठे के एक नियम के रूप में, .xhtml फ़ाइलों को यथासंभव तर्क-मुक्त रखने का प्रयास करें, इसलिए वे केवल प्रस्तुति से निपटते हैं। तो, विकल्प 2 के लिए स्पष्ट रूप से जाएं।

— SJuan76
स्रोत

2

क्या यह तर्क है कि मॉडल की देखभाल करने की आवश्यकता है? यदि यह एक से अधिक बार उपयोग किया जाता है, तो इसका उपयोग क्यों नहीं किया जाएगा <c:set>या <ui:param>इसका विकल्प नहीं होगा?

उस उदाहरण के पीछे कोई मॉडल तर्क नहीं है। आप लॉजिक को मॉडल लॉजिक में बदल देंगे, जो जावा कोड बनाता है जिसे जावा के भीतर भी नहीं कहा जाता है। यदि कक्षा Animalअन्य वातावरण (दूरस्थ) या प्रोग्रामर में है, तो इसके लिए अप्रासंगिक है।

1

व्यक्तिगत रूप से, मैं विकल्प # 2 का उपयोग करूंगा। जबकि मुझे पता है कि ईएल का उपयोग करके समस्या को हल करना और कार्यों या यूआई का उपयोग करके एक्सएचटीएमएल दस्तावेजों में कुछ बिट पुन: उपयोग करना संभव है: यह वास्तव में जावा बीन कार्यान्वयन की पोर्टेबिलिटी, स्थिरता और परीक्षण की कमी लगती है।

यदि कोई डेवलपर EL और Java दोनों में धाराप्रवाह है और दोनों xHTML और Java सेम का मालिक है, तो EL को किसी भी आकार के साथ सशर्त मूल्यांकन करने के लिए बहुत अधिक समझ में नहीं आता है> 1।

बस जावा पक्ष पर लागू करने के लिए बहुत अधिक लाभ प्रतीत होते हैं:

आईडीई + कंपाइलर पर झुकाव की क्षमता
स्थिरांक या एनम ("डॉग" और "बार्क" के लिए) का उपयोग करें, संभावना है कि वे तुलना के लिए कोड में कहीं और उपयोग कर रहे हैं ... यदि स्ट्रिंग मान बदलता है, तो यह वास्तविक रूप से मज़ेदार है कि इसे मैन्युअल रूप से हर जगह बदलने के लिए। कोड आधार
उपयुक्त डेटा के साथ प्रश्न में पृष्ठ पर नेविगेट करने के बजाय मैं यूनिट परीक्षणों का उपयोग करके तर्क का उपयोग कर सकता हूं

विकल्प 1 के पक्ष में मैंने मुख्य दलीलों में से एक (स्टैक के बाहर) सुनी है:

"जब आप इस तर्क को दृष्टि में रखते हैं तो घटक को प्रस्तुत करना बहुत आसान होता है।"

मैंने पाया है कि यह जीवन के प्रारंभिक चरण में एक आवेदन के लिए मामला हो सकता है जहां यह हल्का वजन और कम जटिल है। हालाँकि इस अभ्यास को बड़े पैमाने पर लागू करना और एक छोटे से अनुप्रयोग के रूप में परिपक्व होने पर यह चूहों के घोंसले का कारण बन सकता है और बनाए रखने के लिए एक बुरा सपना बन सकता है। यहाँ कुछ उदाहरण हैं जो मैंने जंगल में देखे हैं:

<h:outputText value="grrr" 
    render="#{animal.type == 'dog' or animal.type == 'cat' or animal.type == 'horse' 
        or animal.type == 'pony' or animal.type == 'mule' or animal.type == 'lion'
        or animal.type == 'tiger' or (animal.type == 'bird' 
        and animal.subType == 'macaw') or .... continue this for another line or two}"
/>

या मेरे पसंदीदा, रेंडर शर्तों के साथ कई घटकों का उपयोग करते हुए जो प्रदर्शित किए जा सकने वाले विभिन्न मूल्यों का प्रतिनिधित्व करने के लिए एक दूसरे के अनन्य हैं:

<h:outputText value="grr" render="#{theMonstrosityFromPreviousExample} />
<h:outputText value="cry" 
    render="#{animal.type == 'human' and animal.subType == 'baby'}" />
<h:outputText value="yo" 
    render="#{animal.type == 'human' and animal.subType == 'teenager'}" />
<h:outputText value="hello" 
    render="#{animal.type == 'human' and animal.subType == 'adult'}"/>

एक बार में अधिकतम 4 पाठ प्रदर्शित किए जा सकते हैं? पहली नज़र में आप यह नहीं बता सकते हैं कि प्रत्येक स्थिति की जाँच आवश्यक होगी। एक साइड नोट के रूप में मुझे लगता है कि यह उदाहरण भी खराब डिजाइन है, क्योंकि इन्हें एसी में रखा जा सकता है: चुनें ... लेकिन मैंने इसे पहले भी देखा है।

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

— दूरभाष
स्रोत