2009-04-29 14 views
23

वर्तमान प्रोजेक्ट के लिए निर्णय लेना है कि HTML का उत्पादन करने के लिए एक्सएमएल और एक्सएसएल-ट्रांसफॉर्मेशन का उपयोग करना है या सीधे HTML-टेम्पलेट्स का उपयोग करना है।एक्सएसएल-रूपांतरण क्यों चुनें?

मुझे एक्सएसएल-दृष्टिकोण के लिए या उसके खिलाफ तर्कों में दिलचस्पी होगी। मैं समझता हूं कि उन मामलों में जहां आपको कई अलग-अलग लेआउट का समर्थन करना है, एक एक्सएसएल-समाधान में बहुत सारे फायदे हैं, लेकिन आप उन मामलों में क्यों चुनेंगे जहां आपको केवल एक लक्ष्य लेआउट का समर्थन करना होगा?

संपादित करें: हम यहां जावा के बारे में बात कर रहे हैं।

+0

आप [ReXSL] (http://www.rexsl.com), एक जावा रूपरेखा है कि XSL, JAXB, और JAX-आरएस – yegor256

उत्तर

5

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

1

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

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

4

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

+2

वास्तव में एकीकृत करता है, मैं vim वास्तव में अच्छा लगता है की समीक्षा करने के रुचि हो सकती है एक्सएमएल संपादन पर। इसके अलावा: विजुअल स्टूडियो 2008 एक्सएमएल/एक्सएसएलटी (डीबगिंग सहित) के लिए बहुत अच्छा है! –

+2

सिंगस्टार पर काम करते समय, हमें (http://www.oxygenxml.com/) एक महान एक्सएमएल और एक्सएसएलटी संपादक होने के लिए मिला। यह बाईं ओर इनपुट एक्सएमएल के साथ तीन पैनल दिखाता है, एक्सएसएलटी बीच में बदलता है और दाईं ओर आउटपुट होता है। बाएं या दाएं पैनल पर एक पंक्ति पर क्लिक करें और सभी संबंधित लाइनों को अन्य पैनलों में हाइलाइट किया गया है (एक्सएसएलटी देखें जो इस लाइन को उत्पन्न करता है + स्रोत एक्सएमएल)। –

4

एक्सएसएलटी का अन्य दस्तावेज प्रकारों (यानी पीडीएफ) में उत्पादन का उत्पादन करने में सक्षम होने का लाभ है और पीडीएफ आउटपुट आजकल बहुत संभावना है। एक्सएमएल/एक्सएसएलटी दृश्य से डेटा भी अलग करता है।

+0

+1 बिल्कुल। पीडीएफ के लिए एफओपी एक अच्छा उदाहरण है। –

+0

सभी ईमानदारी में, हालांकि आप गैर-एक्सएमएल उत्पन्न कर सकते हैं, यह शायद ही कभी किया जाता है - समर्थन सिर्फ अच्छा नहीं है। शायद पीडीएफ को छोड़कर। तो मैं इसे पीडीएफ से अलग एक महत्वपूर्ण कारक नहीं मानूंगा। मैं डेटा डेटा को अलग/अलग नहीं सोचता, अगर स्रोत डेटा स्वाभाविक रूप से एक्सएमएल नहीं है; यदि हां, तो पहले से ही संभावित अलगाव (इनपुट डेटा -> प्रस्तुति के लिए टेम्पलेट) – StaxMan

2

मैं देखता हूं कि आपका डेटा पहले से एक्सएमएल होने पर एक्सएसएल दृष्टिकोण कैसे आसान हो सकता है।
लेकिन आमतौर पर यह नहीं है। यह किसी डेटाबेस में कहीं है, स्पॉट पर उत्पन्न होने की आवश्यकता है या कुछ सेवा से आता है।
इस स्रोत से एक्सएमएल बनाना तब उस एक्सएमएल से एचटीएमएल बनाने में सक्षम होना मेरी राय में बेकार है। मैं (एक्स) एचटीएमएल टेम्पलेट्स के साथ रहना होगा।

+1

एक पूरी तरह से व्यक्तिगत स्तर पर, मुझे लगता है कि एक्सएसएल पूरे एक्सएमएल-सब-सब कुछ विचार का बच्चा है। इसका सामना करें, एक्सएमएल सभी समाधानों के लिए एक अच्छा डेटा प्रारूप नहीं है। –

+0

मैं बिल्कुल सहमत हूं - यदि स्रोत डेटा xml में है, तो xslt अधिक समझ में आता है। यदि यह नहीं है, तो यह शायद थोड़ा सा समझ में आता है। क्लाइंट में बदलने की संभावना का उल्लेख करने के लिए – StaxMan

2

आपके आवेदन के आधार पर, एक XML परत है कि तब के माध्यम से XSLT भी meens, कि आप XML परत करने के लिए आसान WebServices लिख सकते हैं एक्सएचटीएमएल को तब्दील हो जाता है होने - अपने ग्राहकों को अपनी साइटों डेटा का उपभोग करने के लिए अनुमति ...

XML को एक रूपांतरण लिंक के साथ ब्राउज़र में भेजा गया (सटीक वाक्यविन्यास भूल गया ...) भी कम बैंडविड्थ की आवश्यकता है, क्योंकि एक्सएसएलटी फ़ाइल वही रहेगी और आपको केवल कच्चे एक्सएमएल को पास करने की आवश्यकता है - अपने मार्कअप में शैली विशेषताओं को जोड़ने के बजाय बाहरी सीएसएस स्टाइल शीट का उपयोग करना;)

+0

+1, जो मैं करता हूं। –

21

एक्सएसएलटी एक कार्यात्मक प्रोग्रामिंग भाषा है और आप इसे किसी भी टेम्पलेटिंग सिस्टम के रूप में समृद्ध बनाने के लिए इसका उपयोग कर सकते हैं । हालांकि, आपको नहीं करना चाहिए - आप और आपकी टीम पागल हो जाएंगी।

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

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

यदि आप तर्कसंगत रूप से निर्मित, वैध एक्सएमएल इकाइयों को बदलने की सुंदरता से आकर्षित हैं, तो इसके बजाय एक प्रकार की सुरक्षित टेम्पलेटिंग प्रणाली पर विचार करें जो इसके बजाय सेम को बदल देती है। Google XML Pages देखें, और तार्किक रूप से संगठित, टाइप-सुरक्षित टेम्पलेट बनाएं जो भविष्य के इंजीनियरों को लेने और विस्तार करने के लिए आसान होगा।

+0

लिंक किए गए Google एक्सएमएल पेज अभी भी 24 अगस्त, 2015 के बाद से Google Code पृष्ठ के अनुसार बीटा 0.2 में हैं। – surfmuggle

4

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

हालांकि, जैसा ऊपर बताया गया है, एक्सएसएलटी वाक्यविन्यास और कार्यात्मक प्रोग्रामिंग मानसिकता प्रभावी ढंग से टेम्पलेट का उत्पादन करना मुश्किल बना सकती है। हमने पाया कि हमें उन चालों से चिपकना पसंद आया जो हमने सीखा और जब हमारे पास ग्राहक अनुरोध थे जो कि हम पहले से ही जानते थे, तो कोई भी टिकट के लिए स्वयंसेवक नहीं बनना चाहता था। आम तौर पर किसी ने अंततः यह पता लगाया कि कार्य कैसे करें और हमारे "चाल का थैला" बड़ा हो गया है, लेकिन अक्सर नई चीजों को समझने में बहुत बोझिल होता था।

यदि आप कभी भी UI को बदलने की अपेक्षा नहीं करते हैं, या कम से कम नहीं, तो XSLT अतिरिक्त प्रयास के लायक नहीं हो सकता है।

0

हम अपने सामग्री प्रबंधन प्रणाली में एचटीएमएल उत्पन्न करने के लिए एक्सएसएलटी का उपयोग करते हैं और यह ठीक काम करता है।

कुछ संकेत: एक बड़े बालों वाले एक्सएमएल से एक बार में सभी पेज जेनरेट करने की कोशिश न करें, आप पागल हो जाएंगे। एम्बेडेड मार्करों (जैसे <) के साथ HTML टेम्पलेट (शैलियों, सजावट और मूल मार्कअप के साथ सादे पाठ/एचटीएमएल फ़ाइल) का उपयोग करें - जैसे, <! - मेनू - >, <! - सामग्री - >), और एक्सएसएलटी-रूपांतरण के साथ मार्करों को प्रतिस्थापित करें उचित डेटा का।

ऐसा कहकर, मुझे संदेह है कि आपको वास्तव में xslt की आवश्यकता है यदि आप केवल एक लेआउट, हमेशा के लिए जा रहे हैं।

2

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

XPATH और XSLT में उच्च सीखने की वक्र है और कार्यात्मक प्रोग्रामिंग आपकी बाहों को पाने के लिए चुनौतीपूर्ण हो सकती है। समय की कमी में यह सही विकल्प नहीं हो सकता है।

फ्रंट एंड वर्क के लिए जेएसओएन का हल्का पेलोड है, और इसे आसानी से jQuery और अन्य जावास्क्रिप्ट पुस्तकालयों द्वारा समर्थित किया जाता है। आप जेएसओएन को डेटा प्रोटोकॉल के रूप में विचार करना चाह सकते हैं क्योंकि jQuery लाइब्रेरी डेवलपर्स के लिए कहीं अधिक सुलभ है और फ्रेमवर्क के साथ उत्पादकता का समय एक्सएसएलटी के साथ बहुत कम है, टैग में एम्बेडेड जावास्क्रिप्ट, भयानक वाक्यविन्यास और साथ आने वाले अन्य सभी मिनीटिया फ्रंट एंड पर एक्सएमएल/एक्सपीएटीएच/एक्सएसएलटी।

1

मैं पिछले एक परियोजना, वित्तीय वेब साइटों में एक्सएमएल & XSLT का उपयोग किया है, और यह हमारे लिए अच्छी तरह से काम किया, लेकिन:

  1. हम कई ग्राहकों है, जो आउटपुट हम था की संख्या अलग-अलग था। हम एक्सएसएलटी स्टाइलशीट को प्रतिस्थापित कर सकते हैं और इसने डेवलपर
  2. के लिए प्रबंधित करने के लिए साइट साइट में परिवर्तन किए हैं। हमारे पास टीम पर एक विशेषज्ञ वेब संपादक था। हमने उन्हें उदाहरण XML & दिया है, वे स्टाइलशीट को सीधे
  3. संपादित कर सकते हैं यदि कल वेबसाइट पर जाने के लिए आवश्यक कोई भी शब्द परिवर्तन था (यह एक बैंक था, यह आश्चर्यजनक रूप से अक्सर हुआ), हम केवल नए एक्सएसएलटी को तैनात कर सकते थे पूरी साइट को फिर से तैनात करना।
  4. एकाधिक अलग-अलग आउटपुट स्वरूपों की आवश्यकता थी। हम पीडीएफ, जो प्रौद्योगिकी के एक ही प्रकार पर आधारित है करने के लिए परिवर्तन के लिए FOP इस्तेमाल किया, इसलिए हमें समझने के लिए :-)

मुख्य कारण मैं XSLT प्रयोग करने के लिए देख रहा है, तो आप एक से अधिक है बहुत कठिन नहीं था सभी एक ही एक्सएमएल पर आधारित साइटें, लेकिन विभिन्न HTML आउटपुट की आवश्यकता होती है।

+0

अंक 1 + 3 किसी भी टेम्पलेटिंग सिस्टम से आसानी से संतुष्ट हैं –

+0

यह सच है।लेकिन उस समय उनमें से बहुत से लोग नहीं थे। –

2

इसे आसान रखें। यह एक सिद्धांत है कि किसी को अधिक से अधिक सराहना मिलती है।

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

19

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

सकारात्मक:

  • XSL एक शक्तिशाली कथात्मक भाषा, अनुभवी डेवलपर्स के लिए उपयोगी & मज़ा है, और रूपांतरण कोड की कुछ लाइनें
  • XSL XML के साथ उपयोग के लिए डिज़ाइन किया गया है में बहुत अद्भुत काम कर सकते हैं, इसलिए यदि आपका डेटा पहले से एक्सएमएल है तो यह भावना का एक बहुत बनाता है
  • चिंताओं (बनाम डेटा प्रतिपादन) का पृथक्करण है कई टेम्पलेट भाषाओं से बेहतर
  • एक्सएसएल-आधारित प्रतिपादन आसानी से "उपclassed" किया जा सकता है। इसका मतलब है: मान लीजिए कि आपके पास संबंधित टेम्पलेट एएक्सएसएलटी के साथ डेटा क्लास ए है। ए से प्राप्त कक्षा बी के लिए, आप आसानी से केवल छोटे अंतरों के साथ बीएक्सएसएलटी बना सकते हैं, और विरासत वाले व्यवहारों के लिए एक्सएसएलटी शामिल कर सकते हैं। यह एक्सएसएलटी में बदलावों के कारण टूटने के लिए कम सफल बनाता है।
  • उपर्युक्त बिंदु आपको ओवरराइड करने की शक्ति भी देता है। क्लास ए के लिए संबंधित एक्सएसएलटी के साथ, हम आसानी से संबंधित टेम्पलेट को ए-custom.xslt पर स्विच कर सकते हैं, जो कुछ छोटे बदलाव और एक्सएलटीटी की विरासत है। हम इसे क्षेत्र में फ्लाई पर कर सकते हैं और फिर, लाभ यह है कि ए-custom.xslt केवल कुछ पंक्तियां हैं, मूल एक्सएलटीटी की पूरी संशोधित प्रति नहीं। छोटे पदचिह्न का मतलब है कि यह एक्सेल के कई संस्करणों के साथ काम करने की अधिक संभावना है।
  • .NET 2.0 में, एक्सएसएलटी संकलित और बहुत तेज़ हो जाता है। जावा के लिए समान तकनीक हो सकती है। (अधिकांश टेम्पलेट भाषाएं अब भी यह करती हैं।)
  • .NET में, "ऑब्जेक्ट XPath नेविगेटर" बनाना संभव है, जो आपको अपने डेटा ऑब्जेक्ट को किसी XML ऑब्जेक्ट में परिवर्तित किए बिना बदलने देता है।

    • XSL, एक शक्तिशाली कथात्मक भाषा है भ्रामक: फिर वहाँ जावा में समान तकनीक हो सकता है
    • XSLT & बचने हैंडल, सफेद स्थान मुद्दों, आदि अच्छी तरह से

    विपक्ष HTML के बारे में स्मार्ट है नए प्रोग्रामर - और कम लोगों को एक्सएसएलटी अच्छी तरह से पता है

  • एक्सएसएल वर्बोज़ है। एक्सएमएल अक्सर verbose भी है।
  • एक्सएसएल ट्रांसफॉर्म शायद "मूल" टेम्पलेट्स से धीमे हैं। यहां तक ​​कि संकलित होने पर भी अधिकांश टेम्पलेट भाषाओं की तुलना में एक्सएसएल के लिए अधिक राज्य ओवरहेड है
  • एक्सएसएल को पैरामीटर पास करना मुश्किल है, आपको या तो उन्हें अपने डेटा (अतिरिक्त एक्सएमएल बनाने के लिए मजबूर करना) या सिस्टम-विशिष्ट विधियों के माध्यम से उन्हें भेजना होगा
  • (जो भी XML डेटा का निर्माण शामिल हो सकता है) आप एक ObjectXPathNavigator या समकक्ष की जरूरत नहीं है, तो आप महत्वपूर्ण ओवरहेड उठाना, जब मोड़ अपने डेटा के लिए परिवर्तन
  • एक्सएमएल में वस्तुओं अपने ट्रांसफार्मर की क्षमता पर निर्भर करता है आपको जब आप एक स्ट्रिंग बफर में बदलते हैं तो बफरिंग ओवरहेड भी ले सकते हैं और फिर आउटपुट डिवाइस
  • पर उस स्ट्रिंग को भेज सकते हैं आपके एक्सएसएलटी उपयोग को और अधिक उन्नत, कम पसंद y यह है कि आपके उपकरण आपको समर्थन देंगे (विशेष रूप से जब आप एक्सएमएल डेटा पास करने के लिए शामिल या तेज तरीके से उपयोग करना शुरू करते हैं)

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

आशा है कि मदद करता है!

1

एक्सएमएल + एक्सएसएलटी वास्तव में अच्छा है। आपके पास भविष्य में कई प्रकार के लक्षित प्रारूपों को आउटपुट करने की क्षमता है। लेकिन एक्सएमएल में एम्बेडेड एचटीएमएल के बारे में पता है। फ़ायरफ़ॉक्स एक्सएसएलटी "अक्षम-आउटपुट-एस्केपिंग" का समर्थन नहीं करता है। Bugzilla देखें।

18

मैंने एक्सएसएलटी का उपयोग करके महत्वपूर्ण विकास किया है और यह दोनों अलग-अलग साइटों पर बेहद सफल और पूरी विफलता रही है।

एक निष्कर्ष से पहले कुछ विचार:

  • मुझे नहीं लगता कि किसी को भी कि XSLT तर्क है है कहीं अधिक एक टेम्पलेट पार्स इंजन की तुलना में शक्तिशाली है, यह एक कार्यात्मक भाषा है।

  • हालांकि यह अधिकतर प्रक्रियात्मक भाषाओं के रूप में व्यापक रूप से अपनाया नहीं गया है, फिर भी यह वास्तविक भाषा है जिसका उपयोग वास्तविक परियोजनाओं के लिए किया जा रहा है, लोगों को पहले से ही एक्सएसएलटी के ज्ञान के साथ किराए पर लिया जा सकता है और यह आपके वर्तमान कर्मचारियों के लिए एक हस्तांतरणीय कौशल है।

  • एक्सएसएलटी कुछ समय से भी आसपास रहा है, कार्यान्वयन परिपक्व हैं, मुझे यकीन है कि यह लंबे समय तक चलने वाले टेम्पलेट इंजन (वेग की तरह) के मामले में है लेकिन नए इंजन कम मजबूत हो सकते हैं।

  • जो भी टेम्पलेट भाषा आप तय करते हैं उस पर एक्सएसएलटी के रूप में भी दस्तावेज होने की संभावना नहीं है। एक महान संदर्भ पुस्तक कैसे करें इस पर एक उदाहरण के लिए माइकल के प्रोग्रामर की संदर्भ श्रृंखला में से कोई भी देखें।

  • उपकरण समर्थन आमतौर पर बहुत अच्छा है ... यदि आपके पास बजट है। एक्सएमएलएसपी और स्टाइलस स्टूडियो दोनों अतीत में मेरे लिए बहुत उपयोगी रहे हैं।

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

  • एक्सएसएलटी ट्रांसफॉर्म धीमा हो सकता है और बहुत सारी मेमोरी ले सकता है। यदि आपके पास एक बड़े XML इनपुट के साथ स्टाइलशीट है तो आपको समस्या हो सकती है।

मैं XSLT प्यार लेकिन है कि क्या आप इसका इस्तेमाल करना चाहिए या नहीं कुछ बिंदुओं के लिए नीचे आता है:

आप XSLT करने के लिए प्रतिबद्ध हैं? क्या आपके पास एक्सएसएलटी में गंभीर घर की विशेषज्ञता है? क्या आप कुछ पाने के लिए तैयार हैं?

क्या आपका डेटा एक्सएमएल में है? क्या यह एक्सएमएल में समझ में आता है? क्या आपके पास कोई घर है जो यह सुनिश्चित करने के लिए पर्याप्त डेटा को प्यार करता है कि यह अच्छी तरह से संरचित है और हमेशा एक उपयुक्त स्कीमा है?

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

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

संबंधित मुद्दे