क्या XSLT इसके लायक है? [बन्द है]

Question

कुछ समय पहले, मैंने एक प्रोजेक्ट शुरू किया था, जहाँ मैंने एक html-esque XML स्कीमा डिज़ाइन किया था ताकि लेखक अपनी सामग्री (शैक्षिक पाठ्यक्रम सामग्री) को एक सरलीकृत प्रारूप में लिख सकें जो तब XSLT के माध्यम से HTML में बदल जाएगा। मैं थोड़ी देर के लिए इसके साथ (संघर्षरत) खेला और इसे बहुत ही मूल स्तर पर प्राप्त किया, लेकिन फिर मैं जो सीमाएँ (जो कि मेरे ज्ञान की अच्छी तरह से सीमाएँ हो सकती हैं) से बहुत नाराज थी और जब मैं एक ब्लॉग को पढ़ने का सुझाव दे रहा था XSLT और बस अपनी पसंद की भाषा में अपना XML-से-जो भी पार्सर लिखो, मैं उत्सुकता से उस पर कूद गया और यह शानदार ढंग से काम किया।

मैं अभी भी इस दिन पर काम कर रहा हूं ( मैं वास्तव में इस पर काम कर रहा हूं, बजाय SO पर खेलने के ), और मैं अधिक से अधिक चीजें देख रहा हूं, जो मुझे लगता है कि XSLT को खोदने का निर्णय था एक अच्छी पहल।

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

Comments

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

— मार्टिन वी। लोविस

@Martin, आप एक शीर्षक के रूप में क्या सुझाव देंगे? मुझे इस प्रश्न का उत्तर देने की आवश्यकता नहीं है, लेकिन मुझे लगता है कि यह दिलचस्प है, और किसी ऐसे व्यक्ति के लिए भी उपयोगी है जो यह निर्णय लेने की कोशिश कर रहा है कि XSLT में निवेश करना है या कोई विकल्प।

— बेंजोल

मुझे लगता है कि XSLT जल्दबाजी चक्र ( en.wikipedia.org/wiki/Hype_cycle ) के भीतर उत्पादकता के पठार पर पहुंच गया ।

— डर्क वोल्मार

मुझे व्यक्तिगत रूप से ऐसा लगता है कि मेरा XML तब तक कोई मूल्य नहीं जोड़ रहा है जब तक कि मैंने इसे कम से कम 1 या 2 परिवर्तनों के माध्यम से नहीं चलाया हो।

@ मार्टिनव.लोविस, आपके आश्वासन से सहमत हैं। यह भी वास्तव में उद्यम की चिंताओं के लिए नीचे आता है, जिसका अर्थ है कि अगर एक ही आदमी यह सब करता है, और विधि स्टार्ट-अप है .... ठीक है यह सबसे तेज़ कार्यान्वयन शैली है, वैसे भी उस मामले में अपने आप को केवल खराब करना। XSLT काफी मुश्किल है जब तक यह क्लिक नहीं करता है, इसके लिए डोमेन विशिष्ट ज्ञान की आवश्यकता होती है, लेकिन एक बड़े संगठन में .... हे मेरे भगवान आपको एहसास होता है कि सभी एक्सएमएल विरोधी लोग कितने गलत हैं। और भी, एक बार जब आप XSLT को जानते हैं, तो यह सबसे अच्छा विकल्प है, यह केवल तब लगता है जब आप XSLT नहीं जानते हैं, इसलिए आप सीखने के निवेश में कारक हैं।

— जेएम बेकर

Answer 1

XSLT के लाभ:

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

XSLT के नुकसान:

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

प्रक्रियात्मक व्यवहार प्राप्त करने का एक तरीका है, एक साथ कई परिवर्तनों को श्रृंखलाबद्ध करना। प्रत्येक चरण के बाद आपके पास काम करने के लिए एक नया DOM होता है, जिस पर उस चरण में परिवर्तन परिलक्षित होता है। कुछ XSL प्रोसेसर के पास विस्तार से प्रभावी रूप से एक परिवर्तन करने के लिए होता है, लेकिन मैं विवरण भूल जाता हूं।

इसलिए, यदि आपका कोड ज्यादातर आउटपुट है और बहुत तर्क नहीं है, तो XSLT इसे व्यक्त करने का एक बहुत ही साफ तरीका हो सकता है। यदि बहुत तर्क है, लेकिन ज्यादातर फॉर्म जो एक्सएसएलटी में निर्मित हैं (उन सभी तत्वों का चयन करें जो ब्लाह की तरह दिखते हैं, और प्रत्येक एक आउटपुट ब्ला के लिए), यह काफी अनुकूल वातावरण होने की संभावना है। यदि आप हर समय XML-ishly सोच रहे हैं, तो XSLT 2 को दें।

अन्यथा, मैं कहूंगा कि यदि आपकी पसंदीदा प्रोग्रामिंग भाषा में XPath का समर्थन करने वाला एक अच्छा DOM कार्यान्वयन है और आपको उपयोगी तरीके से दस्तावेज़ बनाने की अनुमति देता है, तो XSLT का उपयोग करने के कुछ लाभ हैं। Libxml2 और gdome2 से बाइंडिंग अच्छी तरह से करनी चाहिए, और सामान्य प्रयोजन की भाषाओं से चिपके रहने में कोई शर्म नहीं है, जिन्हें आप अच्छी तरह से जानते हैं।

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

Comments

XSLT कार्यात्मक नहीं है, यह घोषणात्मक (SQL की तरह) है।

— जेमाह

एक XSL टेम्प्लेट मुझे लगता है कि एक शुद्ध फ़ंक्शन के सभी मानदंड हैं, जो इसे कार्यात्मक के रूप में वर्णित होने से अयोग्य घोषित करता है? 'घोषणात्मक ’एक विकल्प क्यों है? a = 1; घोषणात्मक है।

— AnthonyWJones

यह प्रोलॉग की तरह घोषणात्मक है। en.wikipedia.org/wiki/Declarative_programming

— मार्टिन यॉर्क

मेरा मानना ​​है कि कार्यात्मक प्रोग्रामिंग एक प्रकार की घोषणात्मक प्रोग्रामिंग है।

— ज़िफ्रे

जबकि XSLT 2.0 के बारे में बात एक अच्छी बात है, यहां तक ​​कि जब मैं लिख रहा हूं तब भी XSLT 2.0 के लिए व्यापक समर्थन नहीं है।

— पीटरअलेनवेब

Answer 2

इतनी नकारात्मकता!

मैं अब कुछ वर्षों के लिए XSLT का उपयोग कर रहा हूं, और वास्तव में इसे पसंद करता हूं। आपको महसूस करने के लिए महत्वपूर्ण बात यह है कि यह एक प्रोग्रामिंग भाषा नहीं है, यह एक टेम्प्लेटिंग भाषा है (और इस संबंध में मैं इसे asp.net / spit से बेहतर रूप से बेहतर पाता हूं)।

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

फिर उपयोगिता क्षमताएं हैं: नामस्थानों को धोना, अलग-अलग स्कीमा परिभाषाओं को पहचानना, दस्तावेजों का विलय करना।

यह करना होगा अपने खुद के घर में तरीके विकसित कर की तुलना में XSLT से निपटने के लिए बेहतर हो। कम से कम XSLT एक मानक और कुछ ऐसा है जिसे आप किराए पर ले सकते हैं, और यदि यह वास्तव में आपकी टीम के लिए कभी समस्या है तो यह बहुत ही स्वाभाविक है कि आप अपनी अधिकांश टीम को सिर्फ XML के साथ काम करने देंगे।

एक वास्तविक दुनिया का उपयोग मामला: मैंने अभी एक ऐप लिखा है जो पूरे सिस्टम में इन-मेमोरी XML डॉक्स को हैंडल करता है, और अंत उपयोगकर्ता द्वारा अनुरोध किए गए JSON, HTML, या XML में रूपांतरित करता है। मेरे पास एक्सेल डेटा के रूप में प्रदान करने के लिए काफी यादृच्छिक अनुरोध था। एक पूर्व सहयोगी ने प्रोग्राम के समान कुछ किया था, लेकिन इसके लिए कुछ क्लास फ़ाइलों के मॉड्यूल की आवश्यकता थी और सर्वर में MS ऑफिस स्थापित था! एक्सेल बाहर कर देता है XSD: 3 घंटे में न्यूनतम बेसब्रो प्रभाव के साथ नई कार्यक्षमता।

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

जाहिर है, मेरा मानना ​​है कि यह "इसके लायक" है।

Comments

डीबगिंग के बारे में अपनी बात के लिए एक छोटा सा अतिरिक्त। विज़ुअल स्टूडियो के नवीनतम संस्करण आपको XSL फ़ाइलों के भीतर सीधे डीबग करने की अनुमति देते हैं। ब्रेकपॉइंट्स का निरीक्षण करना, निरीक्षण करना आदि

— क्रेग बोविस

यह एक अच्छा जवाब है, विशेष रूप से एक्सेल xsd की ताज़ा कहानी!

— लगुन

@annakata, क्या आप एक msdn लेख का लिंक प्रदान कर सकते हैं या कुछ ट्यूटोरियल कैसे एक्सेल बात कर सकते हैं? मुझे लगता है कि कुछ ऐसा हो सकता है जिसका उपयोग मैं अपने प्रोजेक्ट के लिए भी कर सकता हूं। धन्यवाद!

— लगुन

JSON और JAML XML की तुलना में बेहतर डेटा प्रारूप हैं। इसके मूल में XML मार्कअप भाषा है; और यह बहुत दुर्भाग्यपूर्ण है कि संरचित डेटा प्रतिनिधित्व के लिए इसका व्यापक रूप से दुरुपयोग किया गया है।

— ulidtko

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

— जेएम बेकर

Answer 3

मुझे यहाँ एक पूर्वाग्रह को स्वीकार करना होगा क्योंकि मैं एक जीविका के लिए XSLT सिखाता हूँ। लेकिन, यह उन क्षेत्रों को कवर करने के लायक हो सकता है जिन्हें मैं अपने छात्रों को काम करते हुए देखता हूं। वे आम तौर पर तीन समूहों में विभाजित होते हैं: प्रकाशन, बैंकिंग और वेब।

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

कई परिस्थितियों में यह वेबसाइट बनाने के लिए एक अनुपयुक्त उपकरण है - एक सामान्य उद्देश्य प्रोग्रामिंग भाषा बेहतर हो सकती है। मुझे अक्सर बहुत बड़े XML दस्तावेज़ लेने और उन्हें वेब पर प्रस्तुत करने की आवश्यकता होती है; XSLT उस तुच्छ बनाता है। जिन छात्रों को मैं इस अंतरिक्ष में देख रहा हूं, वे डेटा सेट को संसाधित कर रहे हैं और उन्हें वेब पर प्रस्तुत कर रहे हैं। XSLT निश्चित रूप से इस स्पेस में एकमात्र लागू टूल नहीं है। हालांकि, उनमें से कई ऐसा करने के लिए DOM का उपयोग कर रहे हैं और XSLT निश्चित रूप से कम दर्दनाक है।

जिन बैंकिंग छात्रों को मैं देख रहा हूँ वे सामान्य रूप से डेटापावर बॉक्स का उपयोग करते हैं। यह एक XML उपकरण है और इसका उपयोग सेवाओं के बीच अलग-अलग XML बोलियों के बीच बैठने के लिए किया जाता है। एक XML भाषा से दूसरे में परिवर्तन XSLT में लगभग तुच्छ है और इस पर मेरे पाठ्यक्रमों में भाग लेने वाले छात्रों की संख्या बढ़ रही है।

मेरे द्वारा देखे जाने वाले छात्रों का अंतिम सेट एक प्रकाशन पृष्ठभूमि (मेरी तरह) से आता है। इन लोगों के पास XML में अपार दस्तावेज़ होते हैं (मेरा विश्वास करें, एक उद्योग के रूप में प्रकाशन XML में बहुत हो रहा है - वर्षों से तकनीकी प्रकाशन हो रहा है और अब व्यापार प्रकाशन हो रहा है)। इन दस्तावेजों को संसाधित करने की आवश्यकता है (DocBook to ePub यहाँ ध्यान में आता है)।

ऊपर किसी ने टिप्पणी की कि लिपियाँ 60 रेखाओं से नीचे की होती हैं या वे अस्पष्ट हो जाती हैं। यदि यह स्पष्ट नहीं है, तो कोडर्स वास्तव में विचार नहीं कर पाए हैं - XSLT कई अन्य भाषाओं से बहुत अलग मानसिकता है। यदि आपको मानसिकता नहीं मिली तो यह काम नहीं करेगा।

यह निश्चित रूप से मरने वाली भाषा नहीं है (मुझे जो काम मिलता है वह मुझे बताता है)। अभी, यह थोड़ा 'अटका' है, जब तक कि Microsoft XSLT 2 का अपना (बहुत देर से) कार्यान्वयन समाप्त नहीं कर लेता है, लेकिन यह अभी भी वहां है और लगता है कि यह मेरे दृष्टिकोण से मजबूत हो रहा है।

Comments

मैं एक जावा डेवलपर हूं और मुझे एक्सएमएल और एक्सएसएलटी भी पसंद है। काश लोग इन की ताकत का एहसास करते।

— निकोलस

Answer 4

हम XSLT का उपयोग बड़े पैमाने पर प्रलेखन जैसी चीजों के लिए करते हैं, और कुछ जटिल विन्यास सेटिंग्स को उपयोगकर्ता-सेवा करने योग्य बनाते हैं।

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

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

और फिर XSLT (जो DocBook को ऊपर रूपांतरित करता है) का उपयोग करते हुए हम अच्छे रिलीज नोट्स (पीडीएफ या HTML आमतौर पर) के साथ समाप्त होते हैं जहां बग आईडी हमारे बग ट्रैकर से स्वचालित रूप से जुड़े होते हैं, कीड़े घटक द्वारा समूहीकृत होते हैं, और सब कुछ का प्रारूप पूरी तरह से संगत है । और उपरोक्त XML हमारे बग ट्रैकर को क्वेरी के द्वारा स्वचालित रूप से उत्पन्न किया जा सकता है जो कि संस्करणों के बीच बदल गया है।

दूसरी जगह जहां हमने XSLT को उपयोगी पाया है, वास्तव में हमारे मुख्य उत्पाद में है। कभी-कभी थर्ड-पार्टी सिस्टम के साथ इंटरफेस करते समय हमें किसी जटिल एचटीएमएल पेज में डेटा को प्रोसेस करने की आवश्यकता होती है। HTML को पार्स करना बदसूरत है, इसलिए हम डेटा को कुछ ऐसे TagSoup के माध्यम से फ़ीड करते हैं(जो उचित SAX XML घटनाओं को उत्पन्न करता है, अनिवार्य रूप से हमें HTML से निपटने की अनुमति देता है जैसे कि यह ठीक से XML लिखा गया था) और फिर हम इसके खिलाफ कुछ XSLT चला सकते हैं, ताकि डेटा को "ज्ञात स्थिर" प्रारूप में बदल सकें जो हम वास्तव में काम कर सकते हैं । उस परिवर्तन को एक XSLT फ़ाइल में अलग करके, इसका मतलब है कि यदि और जब HTML प्रारूप बदलता है, तो एप्लिकेशन को स्वयं अपग्रेड करने की आवश्यकता नहीं होती है, इसके बजाय अंतिम-उपयोगकर्ता केवल XSLT फ़ाइल को स्वयं संपादित कर सकता है, या हम ई-मेल कर सकते हैं पूरे सिस्टम को अपग्रेड किए जाने की आवश्यकता के बिना उन्हें एक अद्यतन XSLT फ़ाइल।

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

Comments

धन्यवाद, यह एक ठोस उदाहरण के साथ एक अच्छा जवाब है।

— बेंजोल

और फिर भी किसी को मेरे जवाब में क्या गलत था के रूप में एक टिप्पणी छोड़ने के बिना इसे नीचे वोट करने की आवश्यकता महसूस की

— एडम बैटकिन

शायद इसलिए कि वे सहमत नहीं थे ...

— बेंजोल

TagSoup के समान एक और कार्यक्रम था जो HTML से एक उचित XML ट्री बनाता है ... लेकिन मुझे नाम याद नहीं है। क्या कोई इसे जानता है?

— 12

Tidy इस उद्देश्य के लिए एक अच्छा कार्यक्रम है

— Erlock

Answer 5

XSLT एक घोषित प्रोग्रामिंग भाषा का एक उदाहरण है ।

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

हालांकि, सॉफ़्टवेयर डेवलपर आमतौर पर ऐसी भाषाओं से नफरत करते हैं, क्योंकि वे अधिक मुख्यधारा ओओ या प्रक्रियात्मक भाषाओं से इतने अलग हैं कि उन्हें सीखना और बहस करना कठिन है। उनकी कॉम्पैक्ट प्रकृति आमतौर पर अनजाने में बहुत नुकसान करना आसान बनाती है।

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

Comments

XSLT कार्यात्मक है, लेकिन मुझे लगता है कि यह बहस का विषय है कि क्या यह घोषणात्मक है (आदेश निर्भरता आदि हैं)। हालांकि, मैं आपकी बात से सहमत हूं कि यह (चाहे कार्यात्मक या घोषणात्मक) दोनों एक शक्तिशाली बात है, साथ ही अधिकांश ओओ / प्रक्रियात्मक प्रोग्रामर के लिए निराशा का स्रोत है। हालाँकि, XSLT के मामले में मेरा मानना ​​है कि, एक कार्यात्मक भाषा के रूप में, इसमें बहुत सारी विशेषताओं का अभाव है जो अधिकांश कार्यात्मक भाषाओं को प्रयोग करने योग्य बनाता है। परिणामस्वरूप आप आमतौर पर कॉम्पैक्ट होने के बजाय बहुत अधिक कोड लिखते हैं । क्या आपने XSLT (1.0) में स्ट्रिंग्स को विभाजित करने की कोशिश की है, उदाहरण के लिए?

— philsquared

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

— पावेल मिनेव

XSLT सामान्य रूप से एक घोषित प्रोग्रामिंग भाषा और PLs का भयानक विकृति है। यहां तक ​​कि INTERCAL अधिक सुसंगत है और उत्पादक के रूप में कुछ उपयोग-मामलों के लिए। हां, कुछ पेड़ परिवर्तन XSLT में सीधे हैं, लेकिन मुझे XPath और a (छद्म-) कार्यात्मक पारंपरिक भाषा का एक संयोजन मिला है जो लिखने के लिए बहुत आसान है और पढ़ने और समझने में बहुत आसान है।

— pm

@ जेफ एटवुड: रेगेक्स के साथ, एक्सएसएलटी की सुंदरता अवधारणा में है, वाक्य रचना में नहीं। उन लोगों के लिए जो उन्हें नहीं पढ़ सकते हैं, regexes अर्थहीन अक्षरों और प्रतीकों का एक विशाल मश्मश हैं। यह regex के पीछे की मानसिकता है जो उन्हें सुंदर बनाती है।

— तोमलक

@ जेफ एटवुड आप एक ऐसे क्षेत्र के बारे में इस तरह के स्पष्ट बयान क्यों लिखते हैं जिसे आप स्पष्ट रूप से नहीं जानते हैं? XSLT और XPath में अच्छी RegEx क्षमताएं हैं और इनमें से कुछ का उपयोग SO पर प्रश्नों के उत्तर में किया गया है। मैंने लेक्सर के लिए XSLT में RegEx का उपयोग करते हुए एक से अधिक पार्सर लिखे हैं। XPath 2.0 के लिए सबसे जटिल पार्सर था। पहले पढ़े बिना लिखना - जैसा कि चुचे के चुटकुले में :)

— दिमित्रे नोवाचेव

Answer 6

मुझे याद है कि XSLT के आसपास के सभी प्रचार जब मानक को जारी किया गया था। एक 'सरल' परिवर्तन के साथ एक संपूर्ण HTML यूआई बनाने में सक्षम होने के आसपास सभी उत्तेजना।

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

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

Comments

असहनीय रूप से धीमा ?? क्या की तुलना में?

— AnthonyWJones

VB6 में रूपांतरण को हाथ से लिखने की तुलना में जैसा मैंने किया था। XSLT करने से अधिक परिमाण का आदेश (मैं ADO रिकॉर्ड्स को HTML में परिवर्तित कर रहा था - 2002 में वापस या कुछ और :-)

— एंडियन

यह ऑक्सीजन की तरह उपकरण का उपयोग करके डिबग करना बहुत आसान है जितना आप उम्मीद करेंगे।

— एंडी डेंट

Answer 7

मैंने XSLT (और भी XQuery) का उपयोग विभिन्न चीजों के लिए बड़े पैमाने पर किया है - निर्माण प्रक्रिया के हिस्से के रूप में C ++ कोड उत्पन्न करने के लिए, doc टिप्पणियों से दस्तावेज़ीकरण का उत्पादन करने के लिए, और एक ऐसे अनुप्रयोग के भीतर जो सामान्य रूप से XML और XHTML के साथ विशेष रूप से बहुत काम करना था। । कोड जनरेटर विशेष रूप से XSLT 2.0 कोड की 10,000 लाइनों से अधिक के आसपास था, लगभग एक दर्जन अलग-अलग फाइलों में फैल गया (इसने बहुत कुछ किया - ग्राहकों के लिए हेडर, प्रॉक्सिस / स्टब्स, COM रैपर, .NET रैपर, ORM - का नाम बदलने के लिए। कुछ)। मुझे यह एक और लड़के से विरासत में मिला, जो वास्तव में अच्छी तरह से भाषा को नहीं समझता था, और पुराने बिट्स इसके परिणामस्वरूप काफी गड़बड़ थे। नया सामान, जो हमने लिखा था, ज्यादातर समझदार और पठनीय था, हालांकि, और मुझे इसे प्राप्त करने के साथ किसी विशेष समस्या को याद नहीं है। यह निश्चित रूप से सी ++ के लिए करने की तुलना में कोई कठिन नहीं था।

संस्करणों की बात करें तो, XSLT 2.0 से निपटने से निश्चित रूप से आपको समझदार बनाए रखने में मदद मिलती है, लेकिन 1.0 सरल रूपांतरों के लिए अभी भी ठीक है। इसके आला में, यह एक बहुत ही उपयोगी उपकरण है, और कुछ विशिष्ट डोमेन-विशिष्ट सुविधाओं (सबसे महत्वपूर्ण बात, टेम्पलेट मिलान के माध्यम से डायनामिक प्रेषण) से मिलने वाली उत्पादकता का मिलान करना कठिन है। XSLT के XML- आधारित सिंटैक्स की कथित शब्दावलियों के बावजूद, LINQ से XML में (यहां तक ​​कि XML शाब्दिक के साथ VB में भी) एक ही बात आमतौर पर कई बार लंबी होती थी। अक्सर, हालांकि, पहले स्थान पर किसी मामले में एक्सएमएल के अनावश्यक उपयोग के कारण यह अवांछनीय फ्लैक हो जाता है।

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

Answer 8

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

1. मैं हमारे maven pom.xml फ़ाइलों पर बड़े पैमाने पर संपादन करने के लिए लघु XSLT रूपांतरण लिखता हूं।

2. मैंने एक्सएमआई (यूएमएल आरेख) से एक्सएमएल स्कीमा उत्पन्न करने के लिए परिवर्तनों की एक पाइपलाइन लिखी है। इसने थोड़ी देर के लिए काम किया, लेकिन आखिरकार यह बहुत जटिल हो गया और हमें इसे खलिहान के पीछे ले जाना पड़ा।

3. मैंने एक्सएमएल स्कीमा को रिफलेक्टर करने के लिए ट्रांसफॉर्मेशन का उपयोग किया है।

4. मैंने XSLT में कुछ सीमाओं के इर्द-गिर्द काम किया है ताकि वास्तविक काम करने के लिए XSLT उत्पन्न कर सके। (कभी एक XSLT लिखने की कोशिश की, जो नामस्थान का उपयोग करके एक आउटपुट का निर्माण करता है जो रनटाइम तक ज्ञात नहीं हैं?)

मैं इसके लिए वापस आ रहा हूं क्योंकि यह एक बेहतर काम है जो मैंने कोशिश की अन्य दृष्टिकोणों की तुलना में XML को राउंड-ट्रिपिंग कर रहा है, जो अनावश्यक रूप से हानिपूर्ण लग रहा है या बस एक्सएमएल को गलत समझ रहा है। XSLT अप्रिय है, लेकिन मुझे लगता है कि ऑक्सीजन का उपयोग करना इसे सहने योग्य बनाता है।

उस ने कहा, मैं XML का रूपांतरण करने के लिए क्लोजर (एक लिस्प) का उपयोग कर जांच कर रहा हूं , लेकिन मुझे अभी तक यह पता नहीं चला है कि क्या वह दृष्टिकोण मुझे लाभ पहुंचाएगा।

Comments

एक्सएसएलटी ने मुझे हैकिश स्क्रिप्ट में पीओएम मॉडिफ़ैक्शंस को लिखने से बचाया है। मैं XML के साथ आया हूँ, यह बुरा है .... लेकिन मार्कअप के लिए इसके अलावा और कुछ भी बेहतर है। XSLT, यह बुरा है, लेकिन यह XML से किसी भी चीज़ में रूपांतरित करने का सबसे अच्छा तरीका है। XQuery शांत है, लेकिन XML बकवास के उस ढेर को ठीक करने का सबसे अच्छा तरीका नहीं है, जिसे XML अर्थ के एक संगठित सेट में बदलना होगा।

— जेएम बेकर

Answer 9

व्यक्तिगत रूप से मैंने XSLT का बिल्कुल अलग संदर्भ में उपयोग किया। कंप्यूटर गेम जो मैं उस समय काम कर रहा था, जिसमें XML का उपयोग करके परिभाषित UI पृष्ठों का उपयोग किया गया था। एक रिलीज के तुरंत बाद एक प्रमुख रिफ्लेक्टर के दौरान हम इन XML दस्तावेजों की संरचना को बदलना चाहते थे। हमने खेल के इनपुट प्रारूप को बेहतर और स्कीमा जागरूक संरचना का अनुसरण किया।

XSLT पुराने प्रारूप -> नए प्रारूप से इस अनुवाद के लिए एकदम सही विकल्प था। दो हफ़्तों के भीतर हमारे सैकड़ों पृष्ठों के लिए मेरे पास पुराने से नए रूपांतरण का काम था। मैं अपने यूआई पृष्ठों के लेआउट पर बहुत सारी जानकारी निकालने के लिए भी इसका उपयोग करने में सक्षम था। मैंने उन घटकों की सूची बनाई, जिनमें घटकों को आसानी से शामिल किया गया था, जिन्हें मैंने अपनी स्कीमा परिभाषाओं में लिखने के लिए XSLT का उपयोग किया था।

साथ ही, C ++ बैकग्राउंड से आना, यह एक बहुत ही मजेदार और दिलचस्प भाषा थी।

मुझे लगता है कि XML को एक प्रारूप से दूसरे प्रारूप में अनुवाद करने के उपकरण के रूप में यह शानदार है। हालाँकि, यह एल्गोरिथ्म को परिभाषित करने का एकमात्र तरीका नहीं है जो XML को इनपुट के रूप में लेता है और कुछ को आउटपुट करता है । यदि आपका एल्गोरिथ्म पर्याप्त रूप से जटिल है, तो यह तथ्य कि इनपुट एक्सएमएल आपकी पसंद के उपकरण के लिए अप्रासंगिक हो जाता है - यानी C ++ / Python / जो भी हो उसमें अपना रोल करें।

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

Answer 10

हां, मैं इसका भरपूर इस्तेमाल करता हूं। अलग-अलग xslt फ़ाइलों का उपयोग करके, मैं कई बहुभुज (X) HTML फ़ाइलों को बनाने के लिए एक ही XML स्रोत का उपयोग कर सकता हूं (एक ही डेटा को अलग-अलग तरीकों से प्रस्तुत करना), एक आरएसएस फ़ीड, एक एटम फ़ीड, एक आरडीएफ विवरणक फ़ाइल और एक साइट मानचित्र का टुकड़ा ।

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

Answer 11

मैं निश्चित रूप से इसे बाहर छड़ी करने के लिए आगे बढ़ना होगा। विशेष रूप से यदि आप दृश्य स्टूडियो का उपयोग कर रहे हैं, जो कि XSLT के लिए संपादन, देखने और डिबगिंग टूल में बनाया गया है।

हाँ, यह एक दर्द है जब आप सीख रहे हैं, लेकिन अधिकांश दर्द परिचित होने के साथ है। भाषा सीखते ही दर्द कम हो जाता है।

W3schools के दो लेख हैं जो विशेष मूल्य के हैं: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Answer 12

मैंने XSLT के साथ काम करना काफी मुश्किल पाया है।

मुझे आपके द्वारा वर्णित किसी प्रणाली के समान काम करने का अनुभव है। मेरी कंपनी ने नोट किया कि हम जो डेटा "मिडिल टियर" से एक्सएमएल में ला रहे थे, और यह था कि पृष्ठों को HTML में प्रस्तुत किया जाना था, जो एक्सएचटीएमएल भी हो सकते हैं, साथ ही उन्होंने सुना होगा कि एक्सएसएल XML के बीच रूपांतरण के लिए एक मानक था। प्रारूपों। तो "आर्किटेक्ट्स" (मेरा मतलब है कि वे लोग जो गहन डिजाइन विचार सोचते हैं, लेकिन स्पष्ट रूप से कभी भी कोड नहीं करते हैं) ने फैसला किया कि हमारे फ्रंट टीयर को XSLT स्क्रिप्ट लिखकर लागू किया जाएगा, जिसने डेटा को प्रदर्शन के लिए XHTML में बदल दिया।

चुनाव विनाशकारी निकला। XSLT, यह पता चला है, लिखने के लिए एक दर्द है। और इसलिए हमारे सभी पृष्ठों को लिखना और बनाए रखना मुश्किल था। हमने JSP (यह जावा में था) या कुछ इसी तरह के दृष्टिकोण का उपयोग किया है, जो आउटपुट प्रारूप (HTML) के लिए एक प्रकार के मार्कअप (कोण कोष्ठक) और दूसरे प्रकार के मार्कअप (जैसे <% ... मेटा डेटा के लिए%>)। XSLT के बारे में सबसे भ्रमित करने वाली बात यह है कि यह XML में लिखा गया है, और यह XML से XML में अनुवाद करता है ... सभी 3 अलग XML दस्तावेजों को सीधे किसी के दिमाग में रखना काफी मुश्किल है।

आपकी स्थिति थोड़ी अलग है: XSLT में प्रत्येक पृष्ठ को लिखने के बजाय जैसा कि आपने किया था, आपको केवल XSLT में एक बिट कोड लिखने की जरूरत है (कोड को डिस्प्ले में बदलने के लिए कोड)। लेकिन ऐसा लगता है कि आप उसी तरह की कठिनाई में पड़ गए होंगे, जो मैंने किया था। मैं कहूंगा कि आप एक सरल XML-आधारित DSL (डोमेन विशिष्ट भाषा) की व्याख्या करने की कोशिश कर रहे हैं जैसे आप कर रहे हैं XSLT के मजबूत बिंदुओं में से एक नहीं है। (हालांकि यह काम कर सकता है ... आखिरकार, यह पूरा हो रहा है!)

हालाँकि, यदि आपके पास जो सरल था: आपके पास एक XML प्रारूप में डेटा है और वह इसमें साधारण परिवर्तन करना चाहता है - पूर्ण पृष्ठ-वर्णन डीएसएल नहीं, लेकिन कुछ सरल सीधे संशोधन, तो XSLT उस उद्देश्य के लिए एक उत्कृष्ट उपकरण है। यह घोषणात्मक है (प्रक्रियात्मक नहीं) प्रकृति वास्तव में उस उद्देश्य के लिए एक फायदा है।

- माइकल चर्मसाइड

Answer 13

XSLT के साथ काम करना मुश्किल है, लेकिन एक बार जब आप इसे जीत लेते हैं तो आपको DOM और स्कीमा की बहुत अच्छी समझ होगी। यदि आप XPath भी करते हैं, तो आप कार्यात्मक प्रोग्रामिंग सीखने के लिए अपने रास्ते पर हैं और यह नई तकनीकों और समस्याओं को हल करने के तरीकों के बारे में बताएगा। कुछ मामलों में, क्रमिक समाधान प्रक्रियात्मक समाधानों की तुलना में अधिक शक्तिशाली है।

Comments

हे - आपको अपने स्वयं के कस्टम परिवर्तन कोड लिखते समय xpath और DOM की बहुत अच्छी सराहना मिलती है। बहुत सी चीजें थीं, जिनमें शामिल हैं, लेकिन इन तक सीमित नहीं हैं: छवियों का आकार बदलना, जावास्क्रिप्ट (एक्सएमएल से) उत्पन्न करना, नेविगेशन उत्पन्न करने के लिए फाइलसिस्टम से पढ़ना, आदि

— निकल

Answer 14

मैं XSLT का बड़े पैमाने पर उपयोग करता हूं, एक कस्टम MVC शैली के सामने के छोर के लिए। मॉडल xml (xml serializaiton के माध्यम से नहीं) के लिए "क्रमबद्ध" है, और फिर HTML को xslt के माध्यम से परिवर्तित किया गया है। ASP.NET पर लाभ XPath के साथ प्राकृतिक एकीकरण में निहित है, और अधिक कठोर अच्छी तरह से गठित आवश्यकताओं (यह अधिकांश अन्य भाषाओं की तुलना में xslt में दस्तावेज़ संरचना के बारे में तर्क करना बहुत आसान है)।

दुर्भाग्य से, भाषा में कई सीमाएँ हैं (उदाहरण के लिए, एक और परिवर्तन के उत्पादन को बदलने की क्षमता) जिसका अर्थ है कि यह कभी-कभी काम करने के लिए निराशाजनक है।

फिर भी, आसानी से प्राप्त होने वाली, दृढ़ता से लागू होने वाली चिंताओं को अलग करना, जो कि वह अनुदान नहीं है, जिसे मैं अभी एक और तकनीक प्रदान कर रहा हूं - इसलिए दस्तावेज़ में परिवर्तन के लिए यह अभी भी कुछ है जो मैं सुझाऊंगा।

Answer 15

मैंने 2004 में कभी-कभी बहुत ही समान-डीबी सिस्टमों के बीच एक एकीकरण परियोजना पर XML, XSD और XSLT का उपयोग किया था। मुझे XSD और XSLT को स्क्रैच से सीखना था, लेकिन यह कठिन नहीं था। इन उपकरणों के बारे में महान बात यह थी कि इसने मुझे डेटा को स्वतंत्र C ++ कोड लिखने में सक्षम किया, जो XML दस्तावेजों को मान्य / सत्यापित करने और फिर XML दस्तावेजों को बदलने के लिए XSD और XSLT पर निर्भर था। डेटा प्रारूप बदलें, XSD और XSLT दस्तावेज़ों को C ++ कोड न बदलें जो Xerces पुस्तकालयों को नियोजित करता है।

ब्याज के लिए: मुख्य XSD 150KB था और XSLT का औसत आकार <5KB IIRC था।

अन्य महान लाभ यह है कि XSD एक विनिर्देश दस्तावेज है जो XSLT पर आधारित है। दोनों सद्भाव में काम करते हैं। और इन दिनों सॉफ्टवेयर विकास में चश्मा दुर्लभ हैं।

हालाँकि मुझे घोषित प्रकृति XSD और XSLT सीखने में बहुत अधिक परेशानी नहीं हुई, लेकिन मैंने पाया कि अन्य C / C ++ प्रोग्रामर को घोषणात्मक तरीके से तालमेल बिठाने में बहुत परेशानी हुई। जब उन्होंने देखा कि यह था, आह प्रक्रियात्मक वे विकृत, अब मुझे समझ में आया! और वे प्रक्रियात्मक XSLT लिखने के लिए आगे बढ़े (दंड!)। बात यह है कि आपको एक्सपीथ सीखना होगा और एक्सएमएल के अक्षों को समझना होगा। पुराने समय के सी प्रोग्रामर को याद दिलाता है कि C ++ लिखते समय OO को नियोजित करना है।

मैंने इन उपकरणों का इस्तेमाल किया क्योंकि उन्होंने मुझे एक छोटा सी ++ कोड बेस लिखने में सक्षम किया जो डेटा संरचना संशोधनों के सबसे बुनियादी और बाद के सभी तरीकों से अलग था। भले ही मैं किसी भी अन्य भाषा में C ++ को पसंद करता हूं, लेकिन मैं एक सॉफ्टवेयर प्रोजेक्ट के दीर्घकालिक व्यवहार्यता को लाभ पहुंचाने के लिए उपयोगी होने के लिए उपयोग करता हूं।

Answer 16

मुझे लगता है कि XSLT एक महान विचार था। मेरा मतलब है कि यह है एक बहुत अच्छा विचार।

जहां यह विफल होता है वह निष्पादन है।

समय के साथ मुझे पता चला कि XML में प्रोग्रामिंग भाषाएं केवल एक बुरा विचार हैं। यह पूरी बात को अभेद्य बनाता है। विशेष रूप से मुझे लगता है कि XSLT बहुत कठिन सीखने, कोड और समझने के लिए है। कार्यात्मक पहलुओं के शीर्ष पर एक्सएमएल पूरी बात को भी भ्रमित करता है। मैंने अपने करियर में इसे 5 बार सीखने की कोशिश की है, और यह सिर्फ छड़ी नहीं करता है।

ठीक है, आप इसे 'टूल' कर सकते हैं - मुझे लगता है कि यह आंशिक रूप से डिज़ाइन का बिंदु था - लेकिन यह दूसरी असफलता है: बाजार पर सभी एक्सएसएलटी उपकरण बहुत सरल हैं ... बकवास!

Comments

यह मुझे लगता है कि आपने XSLT के साथ अपनी समस्याओं का वर्णन किया है, न कि किसी भी भाषा की समस्याओं के साथ। मुझे यह कहना होगा कि आप शायद गलत टूल का उपयोग कर रहे हैं :)

— निक गिब्सन

Answer 17

XSLT विनिर्देश परिभाषित करता है "अन्य XML दस्तावेज़ों में XML दस्तावेज़ों बदलने के लिए एक भाषा" के रूप में XSLT। यदि आप किसी भी चीज़ को करने की कोशिश कर रहे हैं, लेकिन XSLT के भीतर सबसे बुनियादी डेटा प्रोसेसिंग संभवत: बेहतर समाधान हैं।

यह भी ध्यान देने योग्य है कि XSLT की डेटा प्रोसेसिंग क्षमताओं को .NET में बढ़ाया जा सकता है, कस्टम एक्सटेंशन फ़ंक्शन का उपयोग कर:

• MSDN प्रलेखन
• CSharpFriends: ट्यूटोरियल

Comments

गैर-मानक एक्सटेंशन के साथ मानक भाषा का विस्तार करना सबसे बुरा काम है। जो आप समाप्त करते हैं, वह न तो एक्सएसएलटी है और न ही सीएलआर कोड।

— Piotr Dobrogost

फेयर, इसका मतलब यह नहीं है कि यह कभी

— एरिक शूनओवर

Answer 18

मैं अपनी कंपनी के लिए एक ऑनलाइन प्रलेखन प्रणाली बनाए रखता हूं। लेखक SGML (भाषा की तरह एक xml) में प्रलेखन बनाते हैं। SGML को तब XSLT के साथ जोड़ दिया गया और HTML में बदल दिया गया।

यह हमें किसी भी कोडिंग के बिना दस्तावेज़ लेआउट में आसानी से बदलाव करने की अनुमति देता है। यह सिर्फ XSLT को बदलने की बात है।

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

इसके अलावा, XSLT का उपयोग करके, आप अपने समस्या डोमेन (HTML) के करीब काम कर रहे हैं। मैं हमेशा अच्छा विचार रखता हूं।

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

Answer 19

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

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

Answer 20

मेरा अब भी मानना ​​है कि XSLT उपयोगी हो सकता है लेकिन यह एक बदसूरत भाषा है और इससे एक भयानक अपठनीय, अचूक गड़बड़ हो सकती है। आंशिक रूप से क्योंकि XML एक "भाषा" बनाने के लिए पर्याप्त रूप से मानव पठनीय नहीं है और आंशिक रूप से क्योंकि XSLT घोषणात्मक और प्रक्रियात्मक होने के बीच कहीं अटक गया है। ऐसा कहने के बाद, और मुझे लगता है कि इसकी तुलना नियमित अभिव्यक्तियों के साथ की जा सकती है, इसका उपयोग तब होता है जब यह सरल अच्छी तरह से परिभाषित समस्याओं की बात आती है।

वैकल्पिक दृष्टिकोण का उपयोग करना और कोड में XML को पार्स करना समान रूप से बुरा हो सकता है और आप वास्तव में किसी प्रकार की XML marshalling / बाइंडिंग तकनीक (जैसे जावा में JiBX) को नियोजित करना चाहते हैं, जो आपके XML को सीधे ऑब्जेक्ट में बदल देगा।

Answer 21

यदि आप एक घोषणा शैली में XSLT का उपयोग कर सकते हैं (हालांकि मैं पूरी तरह से सहमत नहीं हूं कि यह घोषणात्मक भाषा है) तो मुझे लगता है कि यह उपयोगी और अभिव्यंजक है।

मैंने ऐसे वेब ऐप्स लिखे हैं जो डेटा / प्रोसेसिंग लेयर को हैंडल करने के लिए OO लैंग्वेज (मेरे मामले में C #) का उपयोग करते हैं, लेकिन HTML के बजाय XML को आउटपुट करते हैं। इसके बाद इसे क्लाइंट द्वारा डेटा API के रूप में सीधे उपभोग किया जा सकता है, या XSLT द्वारा HTML के रूप में प्रस्तुत किया जा सकता है। क्योंकि C # XML को आउटपुट कर रहा था जो संरचनात्मक रूप से इस उपयोग के साथ संगत था यह सब बहुत ही सहज था, और प्रस्तुति तर्क को घोषणात्मक रखा गया था। C # से टैग भेजने की तुलना में इसका अनुसरण करना और बदलना आसान था।

हालाँकि, जैसा कि आपको XSLT स्तर पर अधिक प्रोसेसिंग लॉजिक की आवश्यकता होती है, यह जटिल और वर्बोज़ हो जाता है - भले ही आपको "फंक्शनल" मिल जाए।

बेशक, इन दिनों मैंने शायद उन वेब ऐप्स को एक RESTful इंटरफ़ेस का उपयोग करके लिखा होगा - और मुझे लगता है कि डेटा "भाषाएं" जैसे कि JSON उन क्षेत्रों में कर्षण प्राप्त कर रहा है जो XML पारंपरिक रूप से XSLT द्वारा बदल दिए गए हैं। लेकिन अभी के लिए XSLT अभी भी एक महत्वपूर्ण, और उपयोगी, तकनीक है।

Answer 22

मैंने XSLT में बहुत समय बिताया है और पाया है कि जबकि यह कुछ स्थितियों में एक उपयोगी उपकरण है, यह निश्चित रूप से सभी को ठीक नहीं करता है। यह B2B उद्देश्यों के लिए बहुत अच्छी तरह से काम करता है जब इसका उपयोग मशीन-पठनीय XML इनपुट / आउटपुट के लिए डेटा अनुवाद के लिए किया जाता है। मुझे नहीं लगता कि आप अपनी सीमाओं के अपने बयान में गलत रास्ते पर हैं। मुझे निराश करने वाली चीजों में से एक एक्सएसएलटी के कार्यान्वयन में बारीकियां थीं।

शायद आपको उपलब्ध कुछ अन्य मार्कअप भाषाओं को देखना चाहिए। मेरा मानना ​​है कि जेफ़ ने स्टैक ओवरफ़्लो के विषय में इस विषय पर एक लेख किया।

क्या HTML एक मानवीय मार्कअप भाषा है?

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

Answer 23

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

Answer 24

मैंने पहले XSLT का उपयोग किया है। 6 .xslt फ़ाइलों का समूह (एक बड़ी एक से निकाली गई) लगभग 2750 पंक्तियाँ थी इससे पहले कि मैंने इसे C # में लिखा। C # कोड वर्तमान में 4000 लाइनें हैं जिनमें बहुत सारे तर्क हैं; मैं इस बारे में सोचना भी नहीं चाहता कि XSLT में लिखने के लिए क्या करना होगा।

वह बिंदु जहां मैंने हार मान ली है, जब मुझे एहसास हुआ कि XPATH 2.0 के न होने से मेरी प्रगति को काफी नुकसान पहुंच रहा है।

Comments

हाँ, XSLT सभी खराब नहीं है और कुछ वास्तव में शांत उपयोग के मामले हैं, लेकिन Microsoft XSLT 2.0 को गले नहीं लगा रहा है।

— डैरन थॉमस

हमें बताएं कि XSLT की इन 2750 लाइनों को फिर से लिखने के ठीक बाद C # कोड का आकार क्या था। वर्तमान आकार देते हुए हमें कुछ भी नहीं बताता है।

— पियोत्र डोब्रोगोस्ट

Answer 25

आपके तीन सवालों के जवाब देने के लिए:

1. मैंने कुछ साल पहले एक बार XSLT का उपयोग किया है।
2. मेरा मानना ​​है कि कुछ परिस्थितियों में XSLT सही समाधान हो सकता है। (नेवर से नेवर)
3. मैं आपके आश्वासन से सहमत हूं कि यह ज्यादातर 'सरल' परिवर्तनों के लिए उपयोगी है। लेकिन मुझे लगता है कि जब तक आप XSLT को अच्छी तरह से समझते हैं, तब तक इसे वेबसाइट पर प्रकाशित करने जैसे बड़े कार्यों के लिए उपयोग करने के लिए एक मामला है क्योंकि XML HTML में तब्दील हो गया है।

मेरा मानना ​​है कि कई डेवलपर्स XSLT को नापसंद करते हैं क्योंकि वे मूलभूत रूप से अलग-अलग प्रतिमान को नहीं समझते हैं जो कि इस पर आधारित है। लेकिन कार्यात्मक प्रोग्रामिंग में हाल ही में रुचि के साथ हम XSLT को वापसी करते हुए देख सकते हैं ...

Answer 26

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

Answer 27

पिछली कंपनी में हमने XML और XSLT के साथ बहुत कुछ किया था। XML और XSLT दोनों बड़े।

हां एक सीखने की अवस्था है, लेकिन फिर आपके पास XML को संभालने के लिए एक शक्तिशाली उपकरण है। और आप XSLT पर XSLT (जो कभी-कभी उपयोगी हो सकते हैं) का उपयोग कर सकते हैं।

प्रदर्शन भी एक समस्या है (बहुत बड़े एक्सएमएल के साथ) लेकिन आप स्मार्ट एक्सएसएलटी का उपयोग करके और (उत्पन्न) एक्सएमएल के साथ कुछ प्रीप्रोसेसिंग कर सकते हैं।

XSLT के ज्ञान के साथ कोई भी तैयार उत्पाद की उदासीनता को बदल सकता है क्योंकि यह संकलित नहीं है।

Answer 28

मैं व्यक्तिगत रूप से XSLT को पसंद करता हूं, और आप सरलीकृत सिंटैक्स को एक लुक देना चाहते हैं (कोई स्पष्ट टेम्पलेट नहीं, बस एक नियमित पुरानी HTML फ़ाइल कुछ XSLT टैग के साथ इसमें मान थूकने के लिए), लेकिन यह सभी के लिए नहीं है।

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

Answer 29

एक्सएसएलटी अंत-सब नहीं है-एक्सएमएल परिवर्तन के सभी। हालांकि, यह दी गई जानकारी के आधार पर आंकना बहुत मुश्किल है कि क्या यह आपकी समस्या का सबसे अच्छा समाधान होता या यदि अन्य अधिक कुशल और बनाए रखने योग्य दृष्टिकोण होते। आप कहते हैं कि लेखक अपनी सामग्री को सरलीकृत प्रारूप में दर्ज कर सकते हैं - क्या प्रारूप? पाठ बक्से? आप इसे किस तरह के html में परिवर्तित कर रहे थे? यह निर्धारित करने के लिए कि क्या XSLT नौकरी के लिए सही उपकरण है, यह इस परिवर्तन की विशेषताओं को और अधिक विस्तार से जानने में मदद करेगा।

Comments

लेखक पाठ संपादक में XML लिखते हैं। मूल रूप से यह एक सरलीकृत HTML है - लगातार स्टाइल को मजबूर करने के लिए कुछ चीजों को हटा दिया गया है, अधिक जटिल HTML के लिए शॉर्टहैंड के रूप में <video /> टैग जैसी चीजों को जोड़ा गया है। अन्य तत्वों का उपयोग मेनू / ग्रंथ सूची / शब्दावलियाँ, आदि उत्पन्न करने के लिए किया जाता है

— निक सिप

Answer 30

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

XSLT 2.0 में बहुत अधिक स्ट्रिंग फ़ंक्शंस शामिल थे, लेकिन मुझे लगता है कि यह भाषा के लिए एक अच्छा फिट नहीं है, और XSLT 2.0 के कई कार्यान्वयन नहीं हैं।