Dela via

XAMLServices-klass och grundläggande XAML-läsning eller skrivning

  • Artikel

XamlServices är en klass som tillhandahålls av .NET och som kan användas för att hantera XAML-scenarier som inte kräver specifik åtkomst till XAML-nodströmmen eller till systeminformation av XAML-typ som hämtats från dessa noder. XamlServices API kan sammanfattas på följande sätt: Load eller Parse för att stödja en XAML-inläsningssökväg, Save för att stödja en XAML-sökväg och Transform för att tillhandahålla en teknik som ansluter en inläsningssökväg och spara sökväg. Transform kan användas för att ändra från ett XAML-schema till ett annat. Det här avsnittet sammanfattar var och en av dessa API-klassificeringar och beskriver skillnaderna mellan specifika metodöverlagringar.

Last

Olika överlagringar av Load implementera den fullständiga logiken för en inläsningssökväg. Belastningssökvägen använder XAML i någon form och matar ut en XAML-nodström. De flesta av dessa inläsningssökvägar använder XAML i ett kodat XML-textfilsformulär. Men du kan också läsa in en allmän ström, eller så kan du läsa in en förinstallerad XAML-källa som redan finns i en annan XamlReader implementering.

Den enklaste överlagringen för de flesta scenarier är Load(String). Den här överlagringen har en fileName parameter som helt enkelt är namnet på en textfil som innehåller XAML som ska läsas in. Detta är lämpligt för programscenarier, till exempel program med fullständigt förtroende som tidigare har serialiserat tillstånd eller data till den lokala datorn. Detta är också användbart för ramverk där du definierar programmodellen och vill läsa in en av de standardfiler som definierar programbeteende, start av användargränssnitt eller andra ramverksdefinierade funktioner som använder XAML.

Load(Stream) har liknande scenarier. Den här överlagringen kan vara användbar om användaren väljer vilka filer som ska läsas in, eftersom en Stream är ett vanligt utdata från andra System.IO API:er som kan komma åt ett filsystem. Eller så kan du komma åt XAML-källor via asynkrona nedladdningar eller andra nätverkstekniker som också tillhandahåller en ström. (Inläsning från en ström eller en användarvald källa kan få säkerhetskonsekvenser. Mer information finns i XAML-säkerhetsöverväganden.)

Load(TextReader) och Load(XmlReader) är överlagringar som förlitar sig på läsare av format från tidigare versioner av .NET. Om du vill använda dessa överlagringar bör du redan ha skapat en läsarinstans och använt dess Create API för att läsa in XAML i relevant formulär (text eller XML). Om du redan har flyttat postpekare i andra läsare eller utfört andra åtgärder med dem är detta inte viktigt. Logiken för inläsningssökväg från Load bearbetar alltid hela XAML-indata från roten och nedåt. Följande scenarier kan motivera användningen av dessa överlagringar:

  • Designytor där du tillhandahåller enkel XAML-redigeringsfunktion från en befintlig XML-specifik textredigerare.

  • Varianter av kärnscenarier System.IO, där du använder dedikerade läsare för att öppna filer eller strömmar. Logiken utför rudimentär kontroll eller bearbetning av innehållet innan det försöker läsa in som XAML.

Du kan antingen läsa in en fil eller dataström eller läsa in en XmlReader, TextReadereller XamlReader som omsluter XAML-indata genom att läsa in med läsarens API:er.

Internt är var och en av de föregående överlagringarna i slutändan Load(XmlReader), och den skickade XmlReader används för att skapa en ny XamlXmlReader.

Den Load signatur som ger mer avancerade scenarier är Load(XamlReader). Du kan använda den här signaturen i något av följande fall:

  • Du har definierat din egen implementering av en XamlReader.

  • Du måste ange inställningar för XamlReader som varierar från standardinställningarna.

Exempel på icke-standardinställningar:

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

Standardläsaren för XamlServices är XamlXmlReader. Om du anger egna XamlXmlReader med inställningar är följande egenskaper för att ange icke-standard XamlXmlReaderSettings:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Parsa

Parse är som Load eftersom det är ett API för inläsningssökväg som skapar en XAML-nodström från XAML-indata. I det här fallet tillhandahålls dock XAML-indata direkt som en sträng som innehåller all XAML som ska läsas in. Parse är en enkel metod som är lämpligare för programscenarier än för ramverksscenarier. Mer information finns i Parse. Parse är bara ett omslutet Load(XmlReader)-anrop som omfattar en StringReader internt.

Spara

Olika överlagringar av Save implementera sökvägen spara. Alla Save metoder tar alla ett objektdiagram som indata och producerar utdata som en ström, fil eller XmlWriter/TextWriter instans.

Indataobjektet förväntas vara rotobjektet för en viss objektrepresentation. Detta kan vara den enda roten för ett affärsobjekt, roten i ett objektträd för en sida i ett användargränssnittsscenario, arbetsredigeringsytan från ett designverktyg eller andra rotobjektbegrepp som är lämpliga för scenarier.

I många scenarier är objektträdet som du sparar relaterat till en ursprunglig åtgärd som läste in XAML antingen med Load eller med annat API som implementerats av en ramverks-/programmodell. Det kan finnas skillnader i objektträdet som beror på tillståndsändringar, ändringar där programmet hämtade körningsinställningar från en användare, ändrade XAML eftersom ditt program är en XAML-designyta osv. Med eller utan ändringar kallas begreppet att först läsa in XAML från markering och sedan spara det igen och jämföra de två XAML-markeringsformulären ibland som en återkopplingsrepresentation av XAML.

Utmaningen med att spara och serialisera ett komplext objekt som anges i en markeringsform är att uppnå en balans mellan fullständig representation utan informationsförlust, jämfört med verbositet som gör XAML mindre läsbart för människor. Dessutom kan olika kunder för XAML ha olika definitioner eller förväntningar på hur saldot ska ställas in. De Save API:erna representerar en definition av saldot. De Save API:erna använder tillgängliga XAML-schemakontexter och standard-CLR-baserade egenskaper för XamlType, XamlMemberoch andra XAML-systembegrepp av typen XAML för att avgöra var vissa XAML-nodströmskonstruktioner kan optimeras när de sparas tillbaka till pålägg. Till exempel kan XamlServices spara sökvägar använda CLR-baserad standard-XAML-schemakontext för att lösa XamlType för objekt, kan fastställa en XamlType.ContentPropertyoch sedan utelämna egenskapselementtaggar när de skriver egenskapen till XAML-innehållet i objektet.

Transformera

Transform konverterar eller transformerar XAML genom att länka en inläsningssökväg och en sparad sökväg som en enda åtgärd. Ett annat schemakontext eller ett annat stödtypssystem kan användas för XamlReader och XamlWriter, vilket påverkar hur den resulterande XAML omvandlas. Detta fungerar bra för breda transformeringsåtgärder.

För åtgärder som är beroende av att undersöka varje nod i en XAML-nodström använder du vanligtvis inte Transform. I stället måste du definiera en egen åtgärdsserie för sökvägssparande sökväg och interject din egen logik. I en av sökvägarna använder du ett XAML-läsare/XAML-skrivarpar runt din egen nodslinga. Läs till exempel in den första XAML med XamlXmlReader och gå in i noderna med efterföljande Read-anrop. Om du arbetar på XAML-nodströmnivån kan du nu justera enskilda noder (typer, medlemmar, andra noder) för att tillämpa en transformering eller lämna noden as-is. Sedan skickar du noden vidare till relevant Write API för en XamlObjectWriter och skriver ut objektet. Mer information finns i Understanding XAML Node Stream Structures and Concepts.

Se även