XML को ब्राउज़रों को भेजने और XSLT को लागू करने में क्या कमियां हैं?

14

प्रसंग

एक फ्रीलांस डेवलपर के रूप में काम करते हुए, मैंने अक्सर वेबसाइटों को पूरी तरह से XSLT पर आधारित बनाया। दूसरे शब्दों में, प्रत्येक अनुरोध पर, एक XML फ़ाइल उत्पन्न होती है, जिसमें हमें पृष्ठ सामग्री के बारे में जानने की आवश्यकता होती है: वर्तमान में लॉग इन किया गया उपयोगकर्ता का नाम, शीर्ष मेनू प्रविष्टियाँ, यदि यह मेनू गतिशील / विन्यास योग्य है, तो पाठ पृष्ठ के एक विशिष्ट क्षेत्र में प्रदर्शन, आदि। फिर XSL प्रक्रिया (कैश आदि) ब्राउज़र को भेजने के लिए इसे HTML / XHTML पृष्ठ पर भेजते हैं।

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

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

सवाल

आधुनिक ब्राउज़रों में XML फ़ाइल लेने की क्षमता है और इसे XML में घोषित एक्सएलएस फ़ाइल के साथ बदलना है <?xml-stylesheet href="demo.xslt" type="text/xsl"?>। फ़ायरफ़ॉक्स 3 कर सकते हैं। Internet Explorer 8 इसे भी कर सकते हैं।

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

इस तकनीक की कमियां क्या हैं?

मैंने कई लोगों के बारे में सोचा, लेकिन यह इस स्थिति में लागू नहीं होता है:

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

web-development

— आर्सेनी मूरज़ेंको
स्रोत

1

इससे कोई फर्क नहीं पड़ता कि कच्चा HTML कैसा दिखता है। फायरबग जैसे उपकरण आपके लिए इसे प्रारूपित करते हैं।

— जेरेमी हेइलर

क्या किसी भी ब्राउज़र में XSLT 2.0 अभी तक है? व्यक्तिगत रूप से, मैं XSLT 1 पर वापस नहीं जाना चाहता।

— क्रिस्टोफर क्रुट्ज़िग

@ChristopherCreutzig: मुझे याद है कि सर्वर-साइड XSLT 2.0 सपोर्ट बहुत सीमित है (हालाँकि मुझे ठीक से याद नहीं है कि यह समस्या C #, Python, PHP, nginx ngx_http_xslt_moduleया सभी चार के साथ थी)। मुझे अत्यधिक संदेह है कि XSLT 2.0 का क्लाइंट-साइड सपोर्ट बेहतर है।

— बजे आर्सेनी मौरज़ेंको

@ मेनमा मुझे सर्वर पर उपयोग करने से रोकता है, जैसे, सर्वर पर सैक्सन, पूरी तरह से अनदेखा करना कि क्या मेरा सर्वर रूबी, पीएचपी, जावा, सी #, या x86 असेंबली में लिखा गया है? सर्वर एक ऐसी जगह है जहाँ मैं स्वतंत्र रूप से उन सभी भाषाओं और परिवेशों से कोड मिला सकता हूँ - जो मैं चाहता हूँ - यह मानते हुए कि मेरे पास कुछ अपंग होस्टिंग समाधान नहीं है जहाँ मैं बाहरी कार्यक्रमों को नहीं बुला सकता हूँ, निश्चित रूप से।

— बजे क्रिस्टोफर क्रेतुज़िग

1

@ChristopherCreutzig: मैंने अक्सर उन वातावरणों में काम किया है जहाँ कोई भी सिस्टम एडमिनिस्ट्रेटर को सर्वर के लिए जो भी चाहता है उसे तैनात करने के लिए नहीं कह सकता। इसने सैक्सन को व्यावहारिक रूप से मेरे लिए उपयोग करना असंभव बना दिया।

— आर्सेनी मूरज़ेंको

27

ब्राउज़र XSLT को उत्तरोत्तर रेंडर नहीं कर सकते हैं

इसका मतलब यह है कि सभी डेटा लोड होने और संसाधित होने तक कुछ और लोड नहीं होता है और कुछ भी प्रदर्शित नहीं होता है।

आप प्रगतिशील प्रतिपादन और छवियों, सीएसएस और जेएस के प्रीफ़ेटिंग को याद कर रहे हैं।

एक अन्य अनुरोध द्वारा प्रारंभिक लोड में देरी हो रही है

छोटी-ईश फ़ाइलों (<20kb) के लिए अनुरोधों की संख्या, बैंडविड्थ नहीं, फ्रंट-एंड प्रदर्शन के लिए अड़चन है , और अधिकांश पृष्ठ और स्टाइलशीट इस श्रेणी में आएंगे।

यदि आपके पास बड़े पृष्ठ हैं, तो यह और भी बुरा है - पहला बिंदु देखें।

आप शायद किसी भी बैंडविड्थ की बचत नहीं कर रहे हैं

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

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

कैश खत्म हो गए हैं

ब्राउज़र कैश उतना महान नहीं हैं :

याहू के उपयोगकर्ताओं का 40-60% खाली कैश अनुभव है और सभी पेज व्यू का ~ 20% खाली कैश के साथ किया जाता है।

और मोबाइल पर, जहां विलंबता अतिरिक्त अनुरोधों को सबसे महंगा बनाती है, कैश भी बदतर हैं ।

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

`gzip` एक रिवर्स XSLT है

एक्सएसएलटी के माध्यम से किए गए अधिकांश परिवर्तन एक से अधिक क्रिया को दोहराव में बदलने और पुनरावृत्ति को जोड़ने के लिए आते हैं। लेकिन gzip फ़ाइलों से पुनरावृत्ति / अतिरेक को हटाने में महान है!

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

ग्राहक धीमे हो सकते हैं

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

सर्वर-साइड पर आप सभी प्रकार के ऑप्टिमाइज़ेशन ट्रिक्स (जैसे, कैश प्रोसेस्ड टुकड़े या पूरे पृष्ठ) कर सकते हैं। आप नवीनतम, सबसे तेज़ XSLT प्रोसेसर का उपयोग कर सकते हैं (ब्राउज़र में केवल XSLT 1.0 है और संभवतः बहुत अनुकूलित नहीं है)। और आपके सर्वर में संभवतः कई सस्ते कार्यालय कंप्यूटर, फोन आदि की तुलना में बीफियर सीपीयू है।

— कोर्नेल
स्रोत

बहुत बढ़िया जवाब! काश, मैं इसे कई बार अप-वोट कर सकता।

— गौरव

1

+1 विशेष रूप से gzipबिंदु के लिए

— निकोल

3

ऐसा कोई कारण नहीं है कि इस सर्वरसाइड को करने के साथ-साथ HTML को सीधे उत्पन्न न किया जाए। PHP की तुलना में एक बड़े स्थिर ओवरहेड के लिए बहुत अधिक कारण नहीं है। जाहिर तौर पर XSLT> JVM / CLR कंपाइलर हैं और मुझे लगता है कि आप इसे देशी कोड में भी ट्रांसलेट कर सकते हैं।

हालाँकि, डेटा और प्रस्तुति संरचना को अलग-अलग परिवहन करने का विचार अच्छा है।
यह बहुत सारे बैंडविड्थ और यहां तक कि सर्वर के प्रदर्शन को बचा सकता है। लेकिन अनार ने कई बिंदुओं का उल्लेख किया है।

ब्राउज़रों के समुचित समर्थन के लिए, xslt.js मदद कर सकता है।

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

— back2dos
स्रोत

लेकिन आपको अपने डेटा को सही ढंग से प्रीसेट करने के लिए या फिर पहले से ही आने वाले XML / XSLT के विपरीत, अपने डेटा को ठीक से प्रीसेट करने के लिए "jsonlt" विकसित करने की आवश्यकता होगी।

— वॉलफ्रैट

2

कॉम्पैक्ट XML भेजना और क्लाइंट पर कैशेड XSLT होने से आपका बैंडविड्थ भी बच सकता है।

आप ऐसे किसी भी ब्राउज़र को छोड़ देते हैं जो स्मार्टफोन की तरह XSLT का समर्थन नहीं करते हैं। लेकिन आपको इन के लिए किसी भी तरह से एक स्थानिक संस्करण बनाना चाहिए।

— 9000
स्रोत

2

ब्राउज़र के लिए कोई विशेष संस्करण नहीं है जो XSLT (IE6, स्मार्टफोन ब्राउज़र, आदि) का समर्थन नहीं करता है। उन ब्राउज़रों के लिए, XSL ट्रांस्फ़ॉर्म सर्वर द्वारा , उसी XSLT फ़ाइल के आधार पर किया जाता है , और अंतिम HTML इसके बजाय भेजा जाता है।

— आर्सेनी मूरज़ेंको

2

MainMa: हाँ, लेकिन आप आमतौर पर स्मार्टफ़ोन के लिए एक अलग XSL लागू करते हैं, क्योंकि स्क्रीन का आकार काफी अलग होता है, आप उपयोग नहीं कर सकते :hover। आदि

— 9000

1

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

1

यदि उन कुछ ब्राउज़रों को अधिकांश उपयोगकर्ताओं द्वारा उपयोग किया जाता है, तो यह परेशानी के लायक हो सकता है।

— user281377

साथ ही, क्लाइंट सिस्टम XSLT के लिए किस स्तर का समर्थन करता है, इस पर आपका कोई नियंत्रण नहीं है। यदि वे कुछ गैर-मानक-अनुरूप प्लग-इन या कुछ का उपयोग कर रहे हैं (मुझे पता है, कि लगभग कभी नहीं होता है ...), तो आपकी साइट काम नहीं करेगी और समर्थन करना लगभग असंभव होगा।

— TMN