Sdílet prostřednictvím

Třída XAMLServices a základní čtení nebo zápis XAML

  • Článek

XamlServices je třída poskytovaná rozhraním .NET, která se dá použít k řešení scénářů XAML, které nevyžadují konkrétní přístup ke streamu uzlu XAML nebo k informacím o systému typů XAML získaných z těchto uzlů. XamlServices rozhraní API je možné shrnout takto: Load nebo Parse pro podporu cesty načtení XAML, Save pro podporu cesty pro uložení XAML a Transform, která poskytuje techniku, která spojuje cestu načítání a ukládá cestu. Transform lze použít ke změně z jednoho schématu XAML na jiné. Toto téma shrnuje každou z těchto klasifikací rozhraní API a popisuje rozdíly mezi určitými přetíženími metod.

Náklad

Různá přetížení Load implementují úplnou logiku pro cestu načtení. Cesta načtení používá XAML v některých formulářích a vypíše datový proud uzlu XAML. Většina z těchto cest načítání používá XAML ve formuláři kódovaného textového souboru XML. Můžete ale také načíst obecný datový proud nebo můžete načíst předem načtený zdroj XAML, který je již obsažen v jiné XamlReader implementaci.

Nejjednodušší přetížení pro většinu scénářů je Load(String). Toto přetížení má fileName parametr, který je jednoduše názvem textového souboru, který obsahuje XAML k načtení. To je vhodné pro scénáře aplikací, jako jsou úplné důvěryhodné aplikace, které mají dříve serializovaný stav nebo data do místního počítače. To je také užitečné pro architektury, ve kterých definujete aplikační model a chcete načíst jeden ze standardních souborů, které definují chování aplikace, spouštění uživatelského rozhraní nebo jiné funkce definované architekturou, které používají XAML.

Load(Stream) mají podobné scénáře. Toto přetížení může být užitečné, pokud máte uživatel zvolit soubory k načtení, protože Stream je častým výstupem jiných rozhraní API System.IO, která mají přístup k systému souborů. Nebo můžete přistupovat ke zdrojům XAML prostřednictvím asynchronních stahování nebo jiných síťových technik, které také poskytují datový proud. (Načtení ze streamu nebo vybraného zdroje uživatelem může mít vliv na zabezpečení. Další informace najdete v tématu aspekty zabezpečení XAML.)

Load(TextReader) a Load(XmlReader) jsou přetížení, která spoléhají na čtenáře formátů z předchozích verzí rozhraní .NET. Pokud chcete použít tato přetížení, měli byste už vytvořit instanci čtečky a použít její Create rozhraní API k načtení XAML v příslušném formuláři (text nebo XML). Pokud jste už přesunuli ukazatele záznamů v ostatních čtenářích nebo s nimi provedli jiné operace, není to důležité. Logika cesty načítání z Load vždy zpracovává celý vstup XAML z kořenového adresáře dolů. Následující scénáře mohou zaručovat použití těchto přetížení:

  • Návrhové plochy, ve kterých poskytujete jednoduchou funkci úprav XAML z existujícího textového editoru specifického pro XML.

  • Varianty základních System.IO scénářů, kdy k otevírání souborů nebo datových proudů používáte vyhrazené čtenáře. Vaše logika provádí základní kontrolu nebo zpracování obsahu předtím, než se pokusí načíst jako XAML.

Můžete buď načíst soubor nebo datový proud, nebo můžete načíst XmlReader, TextReadernebo XamlReader, která zabalí vstup XAML načtením pomocí rozhraní API čtenáře.

Interně, každý z předchozích přetížení je nakonec Load(XmlReader)a předaný XmlReader se používá k vytvoření nového XamlXmlReader.

Podpis Load, který poskytuje pokročilejší scénáře, je Load(XamlReader). Tento podpis můžete použít pro jeden z následujících případů:

  • Definovali jste vlastní implementaci XamlReader.

  • Musíte zadat nastavení pro XamlReader, která se liší od výchozího nastavení.

Příklady jiných než výchozích nastavení:

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

Výchozí čtečka pro XamlServices je XamlXmlReader. Pokud zadáte vlastní XamlXmlReader s nastavením, následující vlastnosti nastaví jiné než výchozí XamlXmlReaderSettings:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Udělat rozbor

Parse je jako Load, protože se jedná o rozhraní API pro načtení cesty, které vytvoří datový proud uzlu XAML ze vstupu XAML. V tomto případě je však vstup XAML poskytován přímo jako řetězec, který obsahuje veškerý XAML, který se má načíst. Parse je jednoduchý přístup, který je vhodnější pro scénáře aplikací než scénáře architektury. Další informace najdete v tématu Parse. Parse je jen zabalené volání Load(XmlReader), které zahrnuje StringReader interně.

Uložit

Různé přetížení Save implementují cestu uložení. Všechny Save metody přebírají objektový graf jako vstup a vytvářejí výstup jako stream, soubor nebo instanci XmlWriter/TextWriter.

Očekává se, že vstupní objekt bude kořenovým objektem určité reprezentace objektu. Může se jednat o jediný kořen obchodního objektu, kořen stromu objektů pro stránku ve scénáři uživatelského rozhraní, pracovní plochu pro úpravy z návrhového nástroje nebo jiné koncepty kořenových objektů, které jsou vhodné pro scénáře.

V mnoha scénářích souvisí strom objektů, který uložíte, s původní operací, která načetla XAML buď s Load, nebo s jiným rozhraním API implementovaným modelem architektury nebo aplikace. Ve stromu objektů můžou být zachycené rozdíly, které jsou způsobeny změnami stavu, změnami, kdy aplikace zachytila nastavení modulu runtime od uživatele, změnila XAML, protože vaše aplikace je návrhová plocha XAML atd. Při změně nebo bez nich se koncept prvního načtení XAML z revize a jeho následné opětovné uložení a porovnání dvou formulářů značek XAML se někdy označuje jako reprezentace XAML zaokrouhlit.

Problém s uložením a serializací složitého objektu, který je nastaven ve formuláři revize, spočívá v dosažení rovnováhy mezi úplnou reprezentací bez ztráty informací a podrobností, díky čemuž je XAML méně čitelný pro člověka. Kromě toho můžou mít různí zákazníci pro XAML různé definice nebo očekávání, jak by se měl tento zůstatek nastavit. Rozhraní API Save představují jednu definici tohoto zůstatku. Rozhraní API Save používají dostupný kontext schématu XAML a výchozí charakteristiky založené na CLR XamlType, XamlMembera další koncepty systému typů XAML a xaml k určení, kde lze určité konstrukty streamu uzlu XAML optimalizovat při jejich uložení zpět do značek. Například XamlServices uložit cesty mohou použít výchozí kontext schématu XAML založený na CLR k překladu XamlType pro objekty, může určit XamlType.ContentPropertya potom může vynechat značky elementu vlastnosti při zápisu vlastnosti do obsahu XAML objektu.

Transformovat

Transform převede nebo transformuje XAML propojením cesty načtení a cesty pro uložení jako jedinou operací. Pro XamlReader a XamlWriterlze použít jiný kontext schématu nebo jiný systém typů backingu, což ovlivňuje způsob transformace výsledného KÓDU XAML. To funguje dobře pro rozsáhlé transformační operace.

Pro operace, které spoléhají na zkoumání každého uzlu ve streamu uzlu XAML, obvykle nepoužíváte Transform. Místo toho je potřeba definovat vlastní řadu operací ukládání cest pro načtení a interject vlastní logiku. V jedné z cest použijte dvojici pro čtení XAML nebo zapisovač XAML kolem vlastní smyčky uzlu. Například načtěte počáteční XAML pomocí XamlXmlReader a přejděte do uzlů s následnými voláními Read. Provoz na úrovni datového proudu uzlu XAML teď můžete upravit jednotlivé uzly (typy, členy, další uzly), aby se použila transformace, nebo ponechat uzel as-is. Pak odešlete uzel dál do příslušného Write rozhraní API XamlObjectWriter a zapíšete objekt. Další informace najdete v tématu Principy struktur a konceptů datových proudů uzlů XAML.

Viz také