क्या जेएसपी टैग में <rtexprvalue> झूठी</ rtexprvalue> का उपयोग करने का कोई अच्छा कारण है?

Question

क्या विशेषता मूल्य के रूप में डालने के लिए स्क्रिप्टलेट या ईएल अभिव्यक्ति को अस्वीकार करने का कोई अच्छा कारण है?

<tag> 
    <name>mytag</name> 
    <tag-class>org.apache.beehive.netui.tags.tree.Tree</tag-class> 
    <attribute> 
     <name>attr</name> 
     <required>false</required> 
     <rtexprvalue>false</rtexprvalue> 
     <type>boolean</type> 
    </attribute> 
</tag> 

क्या नीचे dissallowing के लिए एक अच्छा कारण हो सकता है:

मान लीजिए कि हम टैग करते हैं?

<my:mytag attr="${setting}" /> 

Answer 1

मैं कहना चाहता हूँ यह ज्यादातर एक पीछे की ओर-संगतता उपाय है, बस एक दिया JSP के लिए ईएल बंद करने के लिए पूरी तरह से क्षमता।

शायद ईएल से पहले टैग लाइब्रेरी मौजूद थी, और अपने स्वयं के उद्देश्यों के लिए विशेष वाक्यविन्यास $ {} का उपयोग करता है। हो सकता है कि विशेषता मान अक्सर उन मूल्यों को लेता है जिनमें एक शाब्दिक $ {} शामिल है।

ऐसी सेटिंग के बिना, मौजूदा कोड (टैग लाइब्रेरी या जेएसपी में) को सर्वलेट spec के नवीनतम संस्करण में अपग्रेड करने के बाद भी काम करने के लिए संशोधित करने की आवश्यकता होगी।

Answer 2

संभावित रूप से टैग्स को संदर्भित करने के लिए गुण हो सकते हैं (उदाहरण के लिए id) कि यह रन-टाइम पर सेट करने के लिए उपयुक्त नहीं है। आप शायद उस परिदृश्य के साथ आ सकते हैं जहां आप सचमुच सादा पाठ के लिए ${} चाहते थे, या जहां किसी भी ईएल सामग्री का मूल्यांकन किसी प्रकार के कस्टम संदर्भ में किया गया था।

लेकिन मुझे लगता है कि स्विच का वास्तविक कारण पीछे की संगतता है। कस्टम टैग ईएल के लिए जेएसपी के अंतर्निहित समर्थन की भविष्यवाणी करते हैं; एक टैगलिब के नीचे परिभाषा को बदलना ताकि ${} अब एक विशेष अर्थ है कि उस टैग के मौजूदा टेम्पलेट्स के उपयोग को तोड़ने की संभावना है। बैक-कॉम्पैट के लिए rtexprvalue-false के लिए डिफ़ॉल्ट से सुरक्षित और जेएसपी 2.0 के लिए नई टैगलिब्स को निर्दिष्ट करें कि वे नया व्यवहार चाहते हैं।

[हाँ। थिलो ने क्या कहा। :-)]