XSLT रूपांतरण का उपयोग करके XAML को विभिन्न प्लेटफार्मों के बीच परिवर्तित किया जा सकता है

WPF और सिल्वरलाइट प्लेटफ़ॉर्म उपयोगकर्ता इंटरफ़ेस तत्वों, टेम्पलेट्स और शैलियों का वर्णन करने के लिए XAML मार्कअप भाषा का उपयोग करते हैं। यदि आप अलग-अलग एक्सएएमएल प्लेटफार्मों के लिए एक साथ विकसित कर रहे हैं, तो स्वाभाविक रूप से, इन प्लेटफार्मों के लिए आम मार्कअप फाइलें रखने की इच्छा है।

WPF और सिल्वरलाइट में मार्कअप बहुत समान है, लेकिन ऐसे कष्टप्रद अंतर हैं जो इसके साझाकरण को बहुत जटिल करते हैं। हमारी कंपनी में, इस समस्या को WPF2SL नामक एक आंतरिक उपकरण के रूप में कई साल पहले हल किया गया था।

WPF2SL आम जनता के लिए उपयोगी होने के लिए बहुत विशिष्ट है, इसलिए हम इसे प्रकाशित करने की योजना नहीं बनाते हैं। इस लेख में, मैं एक्सएएमएल मार्कअप के संबंध में एक्सएसएलटी परिवर्तनों की सुविधाओं के बारे में और कुछ कठिनाइयों और उन विशेषताओं के बारे में बात करूंगा, जिनका हमने सामना किया था।

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

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

चलिए System.Xml.Xsl.XslCompiledTransform बनाकर शुरू करते हैं। यह वही है, जैसा कि MSDN में लिखा गया है। हालाँकि, यह याद रखना चाहिए कि XslCompiledTransform.Load विधि का उपयोग करके XSLT फ़ाइल लोड करने में बहुत समय लगता है, क्योंकि इस बिंदु पर XSLT फ़ाइल में वर्णित राज्य मशीन के लिए एक अस्थायी असेंबली स्मृति में बनाई जाएगी।

WPF2SL के पुराने संस्करणों में से प्रत्येक में, प्रत्येक इनपुट XAML फ़ाइल के लिए, XslCompiledTransform.Load पर कॉल के साथ पूर्ण आरंभीकरण किया गया था। इसने उपयोगिता को बहुत धीमा कर दिया। XslCompiledTransform में, स्रोत ट्री के नोड्स और विशेषताओं के लिए परिवर्तनों का विवरण युक्त एक XSLT फ़ाइल भरी हुई है। XSLT फ़ाइल में परिवर्तन प्राथमिकता के आरोही क्रम में क्रमबद्ध हैं। सबसे कम प्राथमिकता वाला नियम पहला है। यह एक कॉपी नियम है।

<xsl:template match="@* | node()"> <xsl:copy> <xsl:apply-templates select="@* | node()"/> </xsl:copy> </xsl:template> 

यदि नोड या विशेषता के लिए कोई उच्च प्राथमिकता नियम नहीं है, तो इसे से कॉपी किया जाएगा।

सिल्वरलाइट में डायनामिकसोर्स का अभाव

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

 <xsl:template match="@*"> … <xsl:attribute name="{local-name(.)}" namespace="{namespace-uri(.)}"> <xsl:variable name="tempValue1"> <xsl:call-template name="globalReplace"> <xsl:with-param name="outputString" select="."/> <xsl:with-param name="target" select="'DynamicResource'"/> <xsl:with-param name="replacement" select="'StaticResource'"/> </xsl:call-template> </xsl:variable> <xsl:value-of select="normalize-space($tempValue1)"/> </xsl:attribute> </xsl:template> 

समस्या तब जटिल होती है जब किसी अन्य फ़ाइल में घोषित संसाधनों के लिंक होते हैं। समस्या का यह हिस्सा XSLT परिवर्तनों के साथ हल नहीं किया जा सका। इसके लिए, हमारे पास एक अलग पोस्ट-प्रोसेसिंग चरण है, जिसके बारे में हमें एक अलग लेख लिखने की आवश्यकता है।

कटिंग नोड्स और एट्रीब्यूट्स सिल्वरलाइट में उपलब्ध नहीं हैं

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

 <xsl:template match="@FocusVisualStyle"/> 

सबट्री काटने का उदाहरण:

 <xsl:template match="wpf:Style.Triggers"/> 

संसाधन कुंजी अनुवाद सुविधाएँ

WPF और Silvelight दोनों में, आप XAML मार्कअप में एक संसाधन सूची निर्दिष्ट कर सकते हैं जिसमें संसाधन संग्रहीत किए जाएंगे। संसाधन कुंजी द्वारा उपलब्ध हैं। WPF में, कुंजी किसी भी वस्तु हो सकती है, और SL में, कुंजी एक स्ट्रिंग कुंजी होनी चाहिए।

एकीकरण के लिए, निश्चित रूप से, आप WPF में एक प्रतिबंध लगा सकते हैं ताकि केवल स्ट्रिंग ही कुंजी हो, लेकिन हम मजबूत टाइपिंग पसंद करते हैं, जो ऑब्जेक्ट कुंजियों पर प्राप्त होता है। WPF में इस तरह लिखना संभव है

 <SolidColorBrush x:Key="{dxt:FloatingContainerThemeKey ResourceKey=FloatingContainerBackground}" Color="#FFA3C3EC" /> 

जहां FloatingContainerThemeKey, System.Windows.ResourceKey से विरासत में मिली एक विशेष सामान्य वस्तु है। जेनेरिक एक Enum प्रकार को एक पैरामीटर के रूप में स्वीकार करता है, जो संभावित प्रमुख नामों का वर्णन करता है।

 public class FloatingContainerThemeKeyExtension : ThemeKeyExtensionBase<FloatingContainerThemeKey> { } public enum FloatingContainerThemeKey { FloatingContainerAdornerTemplate, FloatingContainerPopupTemplate, FloatingContainerWindowTemplate, } 

इसके कारण, WPF में संसाधन घोषणा में या संसाधन लिंक में प्रमुख नाम में गलती करना अधिक कठिन है।

XAML परिवर्तन पर वापस जाएं। सिल्वरलाइट में कोई ऑब्जेक्ट कुंजियाँ नहीं हैं, इसलिए

 <SolidColorBrush x:Key="{dxt:FloatingContainerThemeKey ResourceKey=FloatingContainerBackground}" Color="#FFA3C3EC" /> 

लाइन में परिवर्तित

 <SolidColorBrush x:Key="FloatingContainerThemeKey_FloatingContainerBackground" Color="#FFA3C3EC" /> 

XML नाम स्थान

WPF और सिल्वरलाइट में कई समान तत्व अलग-अलग xml नामस्थान में हैं। इस अंतर ने इस तरह के पैटर्न को जन्म दिया।

 <xsl:template match="wpf:Label"> <sdk:Label xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"> <xsl:apply-templates select="@* | node()"/> </sdk:Label> </xsl:template> <xsl:template match="wpf:TreeView"> <sdk:TreeView xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"> <xsl:apply-templates select="@* | node()"/> </sdk:TreeView> </xsl:template> 

जब हमें महसूस हुआ कि हमें इस तरह के बहुत सारे टेम्प्लेट करने होंगे, तो हमने अपना वंशज स्टैंडर्ड क्लास XmlTextWriter से बनाया, जिसने राइटस्ट्रीमिंग विधि को ओवरलोड किया।

 public override void WriteString(string text) { if(NamespacesReplacementTable.ContainsKey(text)) base.WriteString(NamespacesReplacementTable[text]); else base.WriteString(text); … } 

यह उत्तराधिकारी एक दूसरे पैरामीटर के रूप में XslCompiledTransform.Transfrom (रीडर, लेखक) पद्धति को दिया जा सकता है। रिप्लेसमेंट टेबल के अनुसार ओवरलोडेड राइटस्ट्रीमिंग नेमस्पेस को लिखते समय बदल देता है।

संकलन प्रक्रिया में एकीकरण

WPF2SL एक कंसोल एप्लिकेशन है। प्री-बिल्ड इवेंट में हमारे SL प्रोजेक्ट्स में, उपयुक्त मापदंडों के साथ एक WPF2SL कॉल पंजीकृत है।

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

XSLT रूपांतरण में समस्याओं का निदान

दुर्भाग्य से, XSLT परिवर्तनों के लिए कोई सुविधाजनक नैदानिक ​​उपकरण नहीं है (कम से कम लेखक उनके बारे में नहीं जानता है)। जब कुछ XSLT रूपांतरण अपेक्षित रूप से काम नहीं करते हैं, तो परिणामों का विश्लेषण करने के लिए XSLT को पुन: संशोधित करने का सबसे कुशल तरीका है। यदि रूपांतरण का परिणाम अपेक्षा से बहुत अलग है, तो टिप्पणी में XSLT फ़ाइल का आधा हिस्सा लगाने के लिए स्वतंत्र महसूस करें; यदि अभी भी स्पष्ट नहीं है, तो एक और आधा और इसी तरह। इस पद्धति को हमारा नाम मिल गया है: "अर्ध-टिप्पणी विधि"।

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

निष्कर्ष

XSLT ट्रांसफ़ॉर्मेशन विभिन्न प्लेटफ़ॉर्म के बीच XAML मार्कअप को बदलने के कार्य में अच्छी तरह से काम करता है, और XslCompiledTransform ट्रांसफॉर्म का .NET XSLT कार्यान्वयन काफी लचीला, उत्पादक और एक्स्टेंसिबल है।

साहित्य

साल मैंगानो। XSLT। पकाने की विधि संग्रह