मेरे द्वारा किसी टेम्प्लेटिंग इंजन का उपयोग क्यों किया जाएगा? jsp में शामिल हैं और jstl बनाम टाईल्स, फ्रीमार्कर, वेलोसिटी, साइटेम


95

मैं अपने दृश्य को व्यवस्थित करने के तरीके को चुनने वाला हूं (स्प्रिंग-एमवीसी के साथ, लेकिन यह ज्यादा मायने नहीं रखना चाहिए)

जहाँ तक मैं देख रहा हूँ 6 विकल्प हैं (हालाँकि वे परस्पर अनन्य नहीं हैं):

  • टाइल्स
  • Sitemesh
  • Freemarker
  • वेग
  • <jsp:include>
  • <%@ include file="..">

टाइलें और सितमेश को समूहीकृत किया जा सकता है; तो फ्री पासवर्डर और वेलोसिटी हो सकता है । उपयोग करने के लिए प्रत्येक समूह में से कौन एक इस चर्चा का विषय नहीं है, इसके बारे में पर्याप्त प्रश्न और चर्चाएं हैं।

यह एक दिलचस्प रीड है , लेकिन मुझे टाइल्स का उपयोग करने के लिए काफी आश्वस्त नहीं कर सकता।

मेरा प्रश्न है - ये रूपरेखाएँ क्या देती हैं जो <@ include file=".."> JSTL के साथ ठीक से नहीं की जा सकतीं। मुख्य बिंदु (कुछ लेख से लिया गया है):

  1. शीर्षलेख और पाद लेख जैसे पृष्ठों के कुछ हिस्सों को शामिल करना - इनमें कोई अंतर नहीं है:

    <%@ include file="header.jsp" %>

    तथा

    <tiles:insert page="header.jsp" />
  2. हेडर में मापदंडों को परिभाषित करना - जैसे शीर्षक, मेटा टैग आदि, यह बहुत महत्वपूर्ण है, विशेष रूप से एसईओ दृष्टिकोण से। टेम्प्लेटिंग विकल्पों के साथ आप एक प्लेसहोल्डर को परिभाषित कर सकते हैं जिसे प्रत्येक पृष्ठ को परिभाषित करना चाहिए। लेकिन इसलिए आप JSTL के साथ jsp में , <c:set>( <c:out>सम्मिलित पृष्ठ में ) और (शामिल पृष्ठ में) का उपयोग कर सकते हैं

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

  4. सामान्य घटकों और विशिष्ट सामग्री के बीच युग्मन - मुझे इसमें कोई समस्या नहीं आती। यदि आप कुछ अंशों का पुन: उपयोग करना चाहते हैं, तो इसे ऐसे पृष्ठ पर ले जाएं, जिसमें कोई शीर्ष लेख / पाद लेख शामिल नहीं है, और जहाँ भी आवश्यक हो, इसे शामिल करें।

  5. दक्षता - <%@ include file="file.jsp" %>किसी भी चीज़ की तुलना में अधिक कुशल है, क्योंकि यह एक बार संकलित है। अन्य सभी विकल्पों को कई बार पार्स / निष्पादित किया जाता है।

  6. जटिलता - सभी गैर-जेएसपी समाधानों के लिए अतिरिक्त xml फ़ाइलों की आवश्यकता होती है, अतिरिक्त शामिल हैं, पूर्व-प्रोसेसर कॉन्फ़िगरेशन, आदि। यह एक सीखने की अवस्था है और विफलता के अधिक संभावित बिंदुओं को पेश कर रहा है। इसके अलावा, यह समर्थन और अधिक थकाऊ परिवर्तन करता है - आपको यह समझने के लिए कि क्या हो रहा है, कई फाइलों / कॉन्फ़िगरेशन की जांच करनी होगी।

  7. प्लेसहोल्डर - क्या JSTL की तुलना में वेग / फ़्रीमार्कर कुछ भी देता है? जेएसटीएल में आप प्लेसहोल्डर डालते हैं और इन प्लेसहोल्डर्स को भरने के लिए मॉडल (रिक्वेस्ट या सेशन स्कोप द्वारा, कंट्रोलर्स द्वारा) का इस्तेमाल करते हैं।

इसलिए, मुझे समझाएं कि मुझे सादे JSP के अलावा / के बजाय ऊपर के किसी भी फ्रेमवर्क का उपयोग करना चाहिए।


मुझे यकीन नहीं है कि मैं उनकी तुलना कैसे करूँगा, जब तक मैं कुछ समय के लिए स्ट्राइप्स लेआउट टेम्प्लेट का उपयोग कर रहा था और मुझे लगता है कि यह सादे आरएसपी की तुलना में बहुत अच्छा है। मैं कुछ jsp का उपयोग करता हूं: कॉल शामिल हैं, लेकिन वे आम तौर पर काफी विशेष मामले हैं। लेआउट टेम्पलेट तंत्र वास्तव में सुविधाजनक और शक्तिशाली उपकरण है।
पॉइंट जूल

2
हाँ, मैंने सुना है कि ये सभी "सुविधाजनक और शक्तिशाली" हैं, लेकिन मैंने इसे नहीं देखा है। हालांकि जो मैंने देखा है वह कॉन्फ़िगरेशन फ़ाइलों की जटिल जटिलता और ढेर है। (मैं विशेष रूप से धारियों के बारे में बात नहीं कर रहा हूं, लेकिन सामान्य तौर पर)
Bozho


मेरा मानना ​​है कि jsp: शामिल बहुत कुशल है - यह सर्वलेट से शामिल करने के लिए विधि कॉल के लिए संकलित है। इसके परिणामस्वरूप @include की तुलना में कम उत्पन्न कोड होता है, जो कैश प्रभावों के कारण प्रदर्शन में सुधार कर सकता है।
टॉम एंडरसन

StringTemplate डेवलपर सबसे अच्छा तर्क मैंने देखा है, जो बहुत ही के समान है बनाता है कम से कम बिजली का नियम
पॉल Sweatte

जवाबों:


17

वेग के लिए कुछ तर्क (मैंने फ्रीमार्कर का उपयोग नहीं किया है):

  • एक वेब संदर्भ के बाहर टेम्पलेट्स का पुन: उपयोग करने की क्षमता, जैसे ईमेल भेजने में
  • वेलोसिटी का टेम्प्लेट लैंग्वेज सिंटैक्स JSP EL या टैग लाइब्रेरी से कहीं अधिक सरल है
  • किसी अन्य प्रकार के तर्क से दृश्य तर्क का सख्त अलगाव - स्क्रिप्ट टैग का उपयोग करने और अपने टेम्प्लेट में खराब चीजों को करने का कोई संभावित विकल्प नहीं है।

प्लेसहोल्डर - क्या JSTL से अधिक वेग / फ्रीमेकर कुछ भी देता है? जेएसटीएल में आप प्लेसहोल्डर डालते हैं और इन प्लेसहोल्डर्स को भरने के लिए मॉडल (रिक्वेस्ट या सेशन स्कोप द्वारा, कंट्रोलर्स द्वारा) का इस्तेमाल करते हैं।

हाँ, संदर्भ वास्तव में वीटीएल के मूल हैं:

<b>Hello $username!</b>

या

#if($listFromModel.size() > 1)
    You have many entries!
#end

दक्षता - <%@ include file="file.jsp" %>किसी भी चीज़ की तुलना में अधिक कुशल है, क्योंकि यह एक बार संकलित है। अन्य सभी विकल्पों को कई बार पार्स / निष्पादित किया जाता है।

यकीन नहीं होता कि मैं इस बात से सहमत हूं या समझ रहा हूं। वेलोसिटी में कैश टेम्प्लेट का एक विकल्प है, जिसका अर्थ है कि वे जिस सार वाक्यविन्यास वृक्ष को पार्स कर रहे हैं उसे डिस्क से पढ़ने के बजाय कैश किया जाएगा। किसी भी तरह से (और मेरे पास इसके लिए ठोस संख्या नहीं है), वेग हमेशा मेरे लिए सिर्फ तेजी से महसूस किया है।

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

यह अंतर है, एक JSP दृष्टिकोण के साथ, क्या आप हर JSP फाइल में इस लेआउट को फिर से व्यवस्थित नहीं करेंगे जो एक ही हेडर / पाद का उपयोग करता है? टाइलें और साइटमैप आपको आधार लेआउट पृष्ठ (JSP, वेलोसिटी टेम्पलेट, आदि - दोनों उनके दिल में JSP फ्रेमवर्क) निर्दिष्ट करने की अनुमति देते हैं) जहाँ आप जो चाहें निर्दिष्ट कर सकते हैं और फिर मुख्य सामग्री के लिए "सामग्री" टुकड़े / टेम्पलेट को सौंप सकते हैं। । इसका मतलब है कि हेडर को स्थानांतरित करने के लिए सिर्फ एक फ़ाइल होगी।


3
आपके द्वारा दिए गए वेग के उदाहरण JSTL के साथ आसानी से किए जा सकते हैं। दक्षता बिंदु के साथ मेरा मतलब है कि jsps को सर्वलेट्स के लिए संकलित किया जाता है, और कुछ भी पार्स नहीं किया जाता है। लेकिन कैशिंग टेम्प्लेट भी एक अच्छा समाधान है, हाँ। पुनर्गठन के लिए - नहीं, मैं आमतौर पर एक तरह से शामिल करता हूं, जिसमें मुझे केवल शामिल करना है, न कि "शामिल करना"। शायद अधिक जटिल मामलों में यह संभव नहीं है।
Bozho

2
वेब संदर्भ से बाहर टेम्पलेट्स का पुन: उपयोग करने के अलावा, वेलोसिटी आपको क्लाइंट को प्रदर्शित करने से पहले आसानी से प्रदान किए गए वेब पेज को हड़पने देता है। यह उपयोगी है जब आप अपनी साइट को HTML फ़ाइलों के रूप में उत्पन्न करना चाहते हैं। JSP के साथ - कोई आसान समाधान नहीं। यह प्राथमिक कारण था कि हमने JSP से वेलोसिटी पर स्विच किया। गति के बारे में - मैंने कुछ बेंचमार्किंग की और वेलोसिटी जेएसपी की तुलना में पृष्ठों को 2 गुना तेजी से प्रदान कर रहा था। तो गति कोई मुद्दा नहीं है। अब कुछ साल वेलोसिटी के साथ बिताने के बाद मैं फिर कभी जेएसपी में वापस नहीं जाऊंगा। यह इतना सरल, हल्का और क्लीनर है।
जूल

@ serg555 क्या आपके पास उन बेंचमार्क हैं जो कहीं भी पोस्ट किए गए हैं? मैं इस बारे में अधिक डेटा देखना पसंद करूंगा। मुझे यह देखने में दिलचस्पी होगी कि आपने कैसे बेंचमार्क भी निभाया है। मुझे लगता है कि यह "वेलोसिटी बनाम जेएसपी बनाम अन्य इंजनों" के प्रश्न पर विचार करने वाले अन्य लोगों के लिए अच्छी जानकारी होगी।
मैट बी

मेरे पास परिणाम पोस्ट नहीं हैं। बस मैंने अपनी साइट से कई पृष्ठ बदले और पहले और बाद के रेंडरिंग समय को मापा। कुछ भी वैज्ञानिक नहीं है :)
सर्ग

@ serg555 jsp का प्लेटफॉर्म / सर्वलेट कंटेनर / संस्करण क्या था?
बोझो

12

के बीच विकल्प jsp:includeऔर टाइलें / Sitemesh / आदि के बीच विकल्प है सादगी और शक्ति है कि डेवलपर्स के लिए हर समय का सामना। यकीन है, अगर आपके पास केवल कुछ फाइलें हैं या आपके लेआउट को बहुत बार बदलने की उम्मीद नहीं है, तो बस उपयोग करें jstlऔर jsp:include

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

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


5

मैं आपको अन्य तकनीकों का उपयोग करने के लिए मनाने नहीं जा रहा हूं। सभी के लिए मुझे पता है कि हर किसी को JSP से चिपके रहना चाहिए अगर यह उनके लिए काम करता है।

मैं मुख्य रूप से स्प्रिंग एमवीसी के साथ काम करता हूं और मुझे साइटमैप के साथ संयोजन में जेएसपी 2+ मिला के का सही मेल मिला।

साइटमेश 2/3

डेकोरेटर्स को उन विचारों पर लागू करने के लिए प्रदान करें जैसे कि अन्य टेम्प्लेटिंग इंजनों में विरासत के काम आते हैं। इस तरह की सुविधा आजकल काम करने के लिए अकल्पनीय है।

JSP 2+

लोगों का दावा है कि JSP को टेम्प्लेट में जावा कोड से बचना मुश्किल हो जाएगा। आपको बस ऐसा नहीं करना चाहिए और इस संस्करण के साथ ऐसा करना अनावश्यक है। संस्करण 2 ईएल का उपयोग करके कॉलिंग विधियों का समर्थन करता है जो पिछले संस्करणों की तुलना में एक बड़ा लाभ है।

JSTL टैग के साथ आपका कोड अभी भी HTML जैसा दिखेगा इसलिए यह कम अजीब है। स्प्रिंग जेपीएल के लिए टैगलिब के माध्यम से बहुत अधिक समर्थन पैक करता है जो बहुत शक्तिशाली है।

टैगलीब भी आसान हैं ताकि आपके खुद के वातावरण को अनुकूलित करना एक हवा हो।


मुझे साइटमेश का कोई लाभ नहीं दिख रहा है। Jsp टैग साइटमेश के समान ही सजाने की कार्यक्षमता प्रदान करते हैं, लेकिन अधिक लचीलेपन, कम भंगुर सेटअप के साथ, और मैं अधिक दक्षता का अनुमान लगाता हूं क्योंकि कोई भी पोस्ट-प्रोसेस पार्सिंग शामिल नहीं है।
मैग्नस

2

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


हाँ, JSF facelets के लिए है बस दुभाषिया के साथ तंग एकीकरण की वजह से समाधान। लेकिन यहाँ यह मामला नहीं है :)
Bozho

मैंने सिर्फ इसका उल्लेख किया है कि इनमें से किसी में भी यही विशेषता है - जो मेरे लिए एक निर्णायक विशेषता होगी।
थोरबजोरन रावन एंडरसन

2

एक अच्छा दृश्य प्रौद्योगिकी सबसे और सबसे अधिक परेशान करता है अगर / स्विच / सशर्त बयान, सरल शामिल नहीं है। 'जटिल' दृश्य प्रौद्योगिकी के प्रयोग से 'सरल' अनुप्रयोग का परिणाम मिलता है।


1

आपने अपने एप्लिकेशन के विशिष्ट के बारे में जानकारी प्रदान नहीं की। उदाहरण के लिए मैं केवल कुछ कारणों से JSP का उपयोग नहीं करता:

JSP टेम्प्लेट में जावा कोड के उपयोग से बचना कठिन है, इसलिए शुद्ध दृश्य की आपकी अवधारणा, और परिणामस्वरूप आपको दृश्य और नियंत्रक के रूप में कई स्थानों पर कोड बनाए रखने में कठिनाइयाँ होंगी

JSP स्वतः JSP संदर्भ बनाता है जो एक सत्र की स्थापना करता है। मैं इससे बचना चाह सकता हूं, हालांकि यदि आपके आवेदन हमेशा सत्र का उपयोग करते हैं तो यह आपके लिए कोई समस्या नहीं हो सकती है

JSP को संकलन की आवश्यकता होती है और यदि लक्ष्य प्रणाली में जावा कंपाइलर नहीं है, तो किसी भी मामूली ट्वीकिंग के लिए अन्य सिस्टम का उपयोग करना होगा और फिर redeploy

मिनिमल जेएसपी इंजन लगभग 500k बाईटकोड प्लस JSTL है, इसलिए यह एम्बेडेड सिस्टम के लिए उपयुक्त नहीं हो सकता है

टेम्पलेट इंजन एक ही मॉडल के विभिन्न कंटेंट प्रकार उत्पन्न कर सकता है, JSON पेलोड, वेबपेज, ई-मेल बॉडी, CSV इत्यादि कह सकते हैं।

गैर जावा प्रोग्रामर को जेएसपी टेम्प्लेट के साथ काम करने में कठिनाइयाँ हो सकती हैं, जब गैर तकनीकी लोगों को नियमित टेम्प्लेट को संशोधित करने में कभी कठिनाई नहीं हुई।

मैं बहुत समय पहले एक ही सवाल पूछ रहा था और अपनी रूपरेखा (निश्चित रूप से टेम्पलेट इंजन आधारित) लिखकर समाप्त हो गया था, जो अन्य समाधानों में मैंने देखा कि सभी नुकसानों से मुक्त था। कहने की जरूरत नहीं कि यह बाइट कोड के बारे में 100k है।


0

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

इसका कुछ भाग स्केल के बारे में है। आप सोच सकते हैं कि इसमें हर बिट उतना ही शक्तिशाली है जितना कि साइटमैप कहते हैं, और यह निश्चित रूप से सच है, कम से कम पृष्ठों की संख्या के लिए (मैं शायद 100 के बारे में कहूंगा), लेकिन अगर आपके पास कई हजारों हैं तो यह असहनीय होने लगता है। (तो eBay के लिए यह जरूरी नहीं है, Salesforce के लिए यह शायद है)

इसके अलावा, जैसा कि पहले उल्लेख किया गया है, फ़्रीमार्क और वेग सर्वलेट विशिष्ट नहीं हैं। आप उन्हें किसी भी चीज़ के लिए उपयोग कर सकते हैं (मेल टेम्प्लेट, ऑफ़लाइन प्रलेखन, आदि)। आपको फ्रीमार्क या वेग का उपयोग करने के लिए एक सर्वलेट कंटेनर की आवश्यकता नहीं है।

अंत में आपकी बात 5 आंशिक रूप से सही है। इसे हर बार संकलित किया जाता है यदि यह पहले से ही उपलब्ध नहीं है। इसका मतलब यह है कि जब भी आप कुछ बदलते हैं तो आपको अपने सर्वलेट कंटेनरों को "काम" निर्देशिका को हटाने के लिए याद रखने की आवश्यकता होती है, ताकि यह जेएसपी को फिर से स्थापित कर सके। यह एक अस्थायी इंजन के साथ अनावश्यक है।

TL, DR टमप्लिंग इंजन JSP + JSTL की कुछ (कथित या वास्तविक) कमियों को दूर करने के लिए लिखे गए थे। आपको उनका उपयोग करना चाहिए या नहीं यह पूरी तरह से आपकी आवश्यकताओं और आपकी परियोजना के पैमाने पर निर्भर करता है।

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