XamlReader Klass

Definition

public ref class XamlReader

public class XamlReader

type XamlReader = class

Public Class XamlReader

Arv

Object

XamlReader

Exempel

I följande exempel konverteras en Button till en sträng med hjälp av XamlWriter klassen. Strängen läses sedan in i en Button med hjälp av den statiska Load metoden i XamlReader klassen.

// Create the Button.
Button originalButton = new Button();
originalButton.Height = 50;
originalButton.Width = 100;
originalButton.Background = Brushes.AliceBlue;
originalButton.Content = "Click Me";

// Save the Button to a string.
string savedButton = XamlWriter.Save(originalButton);

// Load the button
StringReader stringReader = new StringReader(savedButton);
XmlReader xmlReader = XmlReader.Create(stringReader);
Button readerLoadButton = (Button)XamlReader.Load(xmlReader);

' Create the Button.
Dim originalButton As New Button()
originalButton.Height = 50
originalButton.Width = 100
originalButton.Background = Brushes.AliceBlue
originalButton.Content = "Click Me"

' Save the Button to a string.
Dim savedButton As String = XamlWriter.Save(originalButton)

' Load the button
Dim stringReader As New StringReader(savedButton)
Dim xmlReader As XmlReader = XmlReader.Create(stringReader)
Dim readerLoadButton As Button = CType(XamlReader.Load(xmlReader), Button)

Kommentarer

Synkrona Load metoder är statiska, men de asynkrona LoadAsync metoderna är inte statiska och kräver att en instans av XamlReader klassen används.

Utdata från Load metoderna är ett enda objekt som representerar rotobjektet i ett skapat objektträd eller objektdiagram. Objektdiagram som skapas av XamlReader läggs vanligtvis till i det befintliga objektträdet i ett WPF program vid körning. Annars anses det nya objektdiagrammet vara frånkopplat i syfte att WPF programmodellen. Det innebär att det inte renderas och inte kan nås med någon av objektträdsteknikerna som tillämpas på WPF-programmets huvudobjektträd (till exempel API:erna FindName, LogicalTreeHelper, VisualTreeHelper). Mer information om objektträdsbegrepp finns i Trees i WPF.

XamlReader stöder följande primära scenarier:

• Cloning/object factory: Utan ytterligare mekanismer kan en referenstyp vanligtvis inte ingå i mer än en position i ett WPF objektträd. (Exempel på ytterligare mekanismer som ger stöd för delning eller återanvändning i WPF inkluderar objekt som baseras på Freezable eller stöd för objekt som ofta kan delas, till exempel Brush som refereras som ett objekt från en ResourceDictionary.) Ett sätt att klona ett objekt som redan finns i objektträdet är att serialisera objektet med hjälp av XamlWriter.Save. Sedan använder du den serialiserade strängen som indata för ett anrop till Load, med en ström eller XmlReader som mellanhand.

• Konstruera objekt baserat på just-in-time-information: Det finns ofta andra sätt att få sena bindningar eller användarindata att ändra tillståndet för befintliga objekt. Du kan till exempel använda samma värde för att ange mer än en egenskap eller använda databindning. Men om du har ett scenario där även typen av objekt som ska skapas endast kan bestämmas vid körning eller med användarinteraktion, är det ofta en användbar teknik att skapa ett sådant objekt genom att skapa en sträng för Load indata.

• Använda befintliga resurstekniker: Typen Stream används ofta i andra ramverk eller tekniker för överföring av data eller objekt över programgränser eller i liknande situationer. Du kan sedan använda teknikerna Stream för att lagra eller hämta XAML-formaterade data som du så småningom använder för att skapa ett objekt som en del av ditt program.

• Fixed documents: Programmet kan läsa in lokala eller nedladdade XPS-dokument för inkludering i ett WPF programobjektträd och användargränssnitt.

Code Access Security, Loose XAML och XamlReader

XAML är ett markeringsspråk som direkt representerar instansiering och körning av objekt. Därför har element som skapats i XAML samma möjlighet att interagera med systemresurser (till exempel nätverksåtkomst, filsystem-I/O) som motsvarande genererade kod.

WPF stöder .NET Security Framework Code Access Security (CAS). Det innebär att WPF innehåll som körs i Internet-zonen har begränsade körningsbehörigheter. "Lös XAML" (sidor med inkompatibla XAML som tolkas vid inläsning av ett XAML-visningsprogram) och XAML-webbläsarprogram (XBAP) körs vanligtvis i den här Internetzonen och använder samma behörighetsuppsättning. XAML som läses in i ett fullständigt betrott program har dock samma åtkomst till systemresurserna som värdprogrammet. Mer information finns i WPF Partial Trust Security.

Konsekvenserna av dessa instruktioner är att programdesignen måste fatta förtroendebeslut om den XAML som du bestämmer dig för XamlReader att läsa in. Om du läser in XAML som inte är betrodd kan du överväga att implementera din egen sandbox-teknik för hur du läser in det resulterande objektdiagrammet.

XamlReader kan också anropas med partiell förtroendekod. I det här fallet tillämpas Internetsäkerhetszonen för kodåtkomstsäkerhet. Om något i den inlästa XAML:en är ogiltig under Internetsäkerhetszonen genereras ett XAML-parsningsfel. Under XBAP och andra fall som är partiellt förtroende på plattformsnivå, där XamlReader är en del av körningen, får du samma undantagsbeteende som med explicita partiella förtroendeanrop.

WPF XAML, XAML-läsare/skrivare och XAML-språkversioner

XAML2009 innehåller språkfunktioner som x:Reference och x:FactoryMethod. Du kan använda signaturer för Load eller Parse för att läsa in XAML som använder dessa funktioner. De språkfunktionerna stöds dock inte för XAML som behöver kompileras (till exempel XAML för Page build-åtgärd i ett WPF-program eller någon XAML som omfattar kompileringsaktiviteten för markering i byggåtgärderna).

WPF typer och WPF teknik i allmänna supportkoncept som förlitar sig på åtkomst till WPF interna. Hur WPF implementerar beroendeegenskaper förlitar sig till exempel på interna tekniker för effektiv sökning av typmedlem. Åtkomst till dessa interna objekt aktiveras av XAML-läs- och skriv-API:er som anges i XamlWriter och XamlReader från namnområdet System.Windows.Markup och PresentationFramework-sammansättningen. XAML-läsare och XAML-skrivare på lägre nivå från System.Xaml-sammansättningen (klasser baserade på System.Xaml.XamlReader, System.Xaml.XamlWriter) har dock inte åtkomst till WPF interna. Det finns inget beroende från System.Xaml till någon WPF specifik sammansättning. Utan åtkomst till den interna WPF kan System.Xaml-läsare och skrivare inte läsa in eller spara alla WPF typer korrekt eller typer baserat på WPF typer. I synnerhet förstår inte System.Xaml-läsare och skrivare begrepp som WPF beroendeegenskap som säkerhetskopierar egenskapsarkivet, eller alla detaljer om hur WPF använder format, resursordlistor och mallar. Därför har du ett val att göra:

• Om du läser in WPF typer och/eller om du använder XAML i BAML-format på något sätt använder du PresentationFramework XAML-läsare och XAML-skrivare.

• Om du inte förlitar dig på några WPF typer eller BAML-formen av XAML och inte använder någon annan specifik tekniks XAML-läsare eller XAML-skrivarimplementering av skäl som är specifika för det ramverket använder du System.Xaml XAML-läsare och XAML-skrivare.

System.Xaml-stödimplementering i .NET 4

XamlReader är den anropbara API-ytan för WPF XAML-parser på ramverksnivå. Samma underliggande XAML-parser utför även körnings-XAML-inläsning och parsning för WPF program som är inriktade på .NET Framework 3.0 och .NET Framework 3.5.

Om du riktar in dig på .NET Framework 4 är det externa API:et detsamma, men delar av implementeringen bygger på den allmänna XAML-implementeringen i .NET Framework 4 i System.Xaml-sammansättningen, vilket förbättrar många av de tekniska och rapporteringsmässiga aspekterna av parsning av XAML. Att rikta in sig på .NET Framework 4 innebär nödvändigtvis att system.Xaml ingår som referens, och information om implementering, till exempel de undantag som rapporteras, kan komma från System.Xaml-definierade typer.

Se även

• XamlWriter