Share via

XAMLServices-Klasse und grundlegende XAML-Lese- und -Schreibvorgänge

  • Artikel

XamlServices ist eine von .NET bereitgestellt Klasse, die verwendet werden kann, um XAML-Szenarien zu adressieren, die keinen bestimmten Zugriff auf den XAML-Knotenstream oder die Informationen zum XAML-Typsystem erfordern, die aus diesen Knoten abgerufen werden. Die XamlServices-API kann wie folgt zusammengefasst werden: Load oder Parse zur Unterstützung eines XAML-Ladepfads, Save zur Unterstützung eines XAML-Speicherpfads und Transform zum Bereitstellen einer Technik, die einen Ladepfad und einen Speicherpfad verbindet. Transform kann verwendet werden, um von einem XAML-Schema zu einem anderen zu wechseln. In diesem Thema sind diese API-Klassifizierungen zusammengefasst, und die Unterschiede zwischen bestimmten Methodenüberladungen werden beschrieben.

Laden

Verschiedene Überladungen von Load implementieren die vollständige Logik für einen Ladepfad. Der Ladepfad verwendet XAML und gibt einen XAML-Knotenstream aus. Die meisten dieser Ladepfade verwenden XAML in Form einer codierten XML-Textdatei. Sie können jedoch auch einen allgemeinen Stream laden oder eine vorab geladene XAML-Quelle, die bereits in einer anderen XamlReader -Implementierung enthalten ist.

Die einfachste Überladung für die meisten Szenarien ist Load(String). Diese Überladung verfügt über einen fileName -Parameter, bei dem es sich einfach um den Namen einer Textdatei handelt, die die zu ladende XAML enthält. Dies eignet sich für Anwendungsszenarien wie Anwendungen mit voller Vertrauenswürdigkeit, die zuvor den Zustand oder Daten in den lokalen Computer serialisiert haben. Dies ist auch für Frameworks nützlich, bei denen Sie das Anwendungsmodell definieren und eine der Standarddateien laden möchten, die Anwendungsverhalten, die beim Start angezeigte Benutzeroberfläche oder andere vom Framework definierte Funktionen definieren.

Load(Stream) hat ähnliche Szenarien. Diese Überladung kann nützlich sein, wenn Sie zu ladende Dateien vom Benutzer auswählen lassen, da ein Stream eine häufige Ausgabe von anderen System.IO -APIs ist, die auf ein Dateisystem zugreifen können. Oder Sie könnten über asynchrone Downloads oder andere Netzwerktechniken, die ebenfalls einen Stream bereitstellen, auf XAML-Quellen zugreifen. (Das Laden aus einem Stream oder einer benutzerseitig ausgewählten Quelle kann Auswirkungen auf die Sicherheit haben. Weitere Informationen finden Sie unter XAML-Sicherheitsüberlegungen.)

Load(TextReader) und Load(XmlReader) sind Überladungen, die Reader für Formate aus früheren Versionen von .NET erfordern. Zum Verwenden dieser Überladungen sollten Sie bereits eine Readerinstanz erstellt und deren Create-API verwendet haben, um die XAML in der relevanten Form (Text oder XML) zu laden. Wenn Sie bereits Datensatzzeiger in die anderen Reader verschoben oder andere Vorgänge damit ausgeführt haben, spielt dies keine Rolle. Die Ladepfadlogik aus Load verarbeitet immer die gesamte XAML-Eingabe vom Stamm abwärts. Die folgenden Szenarien können die Verwendung dieser Überladungen rechtfertigen:

  • Entwurfsoberflächen, auf denen einfache XAML-Bearbeitungsfunktionen eines vorhandenen XML-spezifischen Text-Editors bereitgestellt werden.

  • Varianten der System.IO -Kernszenarien, in denen zum Öffnen von Dateien oder Streams dedizierte Reader verwendet werden. Die Logik überprüft oder verarbeitet den Inhalt rudimentär, bevor er als XAML geladen wird.

Sie können eine Datei, einen Stream oder ein XmlReader-, TextReader- oder XamlReader-Element laden, von der bzw. dem die XAML-Eingabe durch das Laden mit den Reader-APIs umschlossen wird.

Intern ist jede der oben genannten Überladungen letztlich Load(XmlReader), und der übergebene XmlReader wird verwendet, um einen neuen XamlXmlReaderzu erstellen.

Die Load -Signatur für erweiterte Szenarien ist Load(XamlReader). Sie können diese Signatur für einen der folgenden Fälle verwenden:

  • Sie haben eine eigene Implementierung von XamlReader definiert.

  • Sie müssen Einstellungen für XamlReader angeben, die von den Standardeinstellungen abweichen.

Beispiele für nicht standardmäßige Einstellungen:

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

Der Standardreader für XamlServices ist XamlXmlReader. Wenn Sie ein eigenes XamlXmlReader-Element mit Einstellungen zur Verfügung stellen, werden mit folgenden Eigenschaften nicht standardmäßige XamlXmlReaderSettings-Elemente festgelegt:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Analysieren

Parse entspricht Load , da es sich um eine Ladepfad-API handelt, die einen XAML-Knotenstream aus der XAML-Eingabe erstellt. In diesem Fall wird die XAML-Eingabe jedoch direkt als Zeichenfolge bereitgestellt, die das gesamte zu ladende XAML enthält. Parse ist ein einfacher Ansatz, der sich besser für Anwendungsszenarien eignet als für Frameworkszenarien. Weitere Informationen finden Sie unter Parse. Parse ist genau genommen nur ein umschlossener Load(XmlReader)-Aufruf, der intern ein StringReader-Element einschließt.

Speichern

Verschiedene Überladungen von Save implementieren den Speicherpfad. Alle Save -Methoden verwenden ein Objektdiagramm als Eingabe und erstellen die Ausgabe als Stream, Datei oder XmlWriter/TextWriter -Instanz.

Es wird davon ausgegangen, dass das Eingabeobjekt das Stammobjekt einer Objektdarstellung ist. Dies könnte der einzelne Stamm eines Geschäftsobjekts sein, der Stamm einer Objektstruktur für eine Seite in einem Benutzeroberflächenszenario, die Bearbeitungsoberfläche in einem Entwurfstool oder andere Stammobjektkonzepte, die für Szenarien geeignet sind.

In vielen Szenarien bezieht sich die Objektstruktur, die Sie speichern, auf einen ursprünglichen Vorgang, der XAML mit Load oder mit einer anderen, von einem Framework/Anwendungsmodell implementierten API geladen hat. Unter Umständen werden Unterschiede in der Objektstruktur erfasst. Diese hängen mit Zustandsänderungen, mit Änderungen, bei denen die Anwendung Laufzeiteinstellungen von einem Benutzer erfasst hat, geänderter XAML zusammen, da die Anwendung eine XAML-Entwurfsoberfläche usw. Mit oder ohne Änderungen wird das Konzept zum Laden von XAML aus dem Markup und dem anschließenden erneuten Speichern und Vergleichen der zwei XAML-Markupformen manchmal als Roundtripdarstellung der XAML bezeichnet.

Die Herausforderung beim Speichern und Serialisieren eines komplexen Objekts in Markupform besteht darin, ein Gleichgewicht zwischen vollständiger Darstellung ohne Informationsverlust und übermäßiger Ausführlichkeit zu erreichen, durch die die Lesbarkeit des XAML beeinträchtigt wird. Darüber hinaus könnten andere Kunden für XAML über andere Definitionen oder Erwartungen im Hinblick darauf verfügen, wie dieses Gleichgewicht festgelegt werden sollte. Die Save -APIs stellen eine Definition dieses Gleichgewichts dar. Die Save -APIs verwenden den verfügbaren XAML-Schemakontext und die CLR-basierten Standardeigenschaften von XamlType, XamlMembersowie andere XAML-systeminterne und XAML-Typsystemkonzepte, um zu bestimmen, wo bestimmte XAML-Knotenstreamkonstrukte beim erneuten Speichern im Markup optimiert werden können. Beispiel: XamlServices -Speicherpfade können den CLR-basierten XAML-Standardschemakontext verwenden, um XamlType für Objekte aufzulösen, eine XamlType.ContentPropertybestimmen und anschließend Eigenschaftselementtags weglassen, wenn sie die Eigenschaft in den XAML-Inhalt des Objekts schreiben.

Transformieren

Transform konvertiert oder transformiert XAML, indem sie einen Ladepfad und einen Speicherpfad als einzelnen Vorgang verknüpft. Ein anderer Schemakontext oder ein anderes Unterstützungstypsystem kann für XamlReader und XamlWriterverwendet werden. Dies wirkt sich darauf aus, wie das resultierende XAML transformiert wird. Es funktioniert gut für umfassende Transformationsvorgänge.

Für Vorgänge, bei denen jeder Knoten in einem XAML-Knotenstream untersucht wird, wird Transformin der Regel nicht verwendet. Stattdessen müssen Sie eigene Ladepfad-/Speicherpfadvorgänge definieren und eigene Logik verwenden. Verwenden Sie in einem der Pfade ein XAML Reader/XAML-Writer-Paar um Ihre eigene Knotenschleife. Laden Sie z. B. die ursprüngliche XAML mit XamlXmlReader , und springen Sie mit aufeinander folgenden Read -Aufrufen in die Knoten. Durch das Vorgehen auf XAML-Knotenstreamebene können Sie jetzt einzelne Knoten (Typen, Member, andere Knoten) anpassen, um eine Transformation anzuwenden, oder die Knoten unverändert beibehalten. Anschließend senden Sie den Knoten an die relevante Write -API eines XamlObjectWriter und schreiben das Objekt aus. Weitere Informationen finden Sie unter Understanding XAML Node Stream Structures and Concepts.

Weitere Informationen