Freigeben über

XAMLServices-Klasse und grundlegendes LESEN oder Schreiben von XAML

  • Artikel

XamlServices ist eine Von .NET bereitgestellte Klasse, die verwendet werden kann, um XAML-Szenarien zu behandeln, die keinen bestimmten Zugriff auf den XAML-Knotendatenstrom oder auf XAML-Typsysteminformationen erfordern, die von diesen Knoten abgerufen werden. 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, um eine Technik bereitzustellen, die einen Ladepfad verknüpft und den Speicherpfad speichert. Transform können verwendet werden, um von einem XAML-Schema zu einem anderen zu wechseln. In diesem Thema werden alle diese API-Klassifizierungen zusammengefasst und die Unterschiede zwischen bestimmten Methodenüberladungen beschrieben.

Last

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

Die einfachste Überladung für die meisten Szenarien ist Load(String). Diese Überladung weist einen fileName Parameter auf, der einfach der Name einer Textdatei ist, die den zu ladenden XAML-Code enthält. Dies eignet sich für Anwendungsszenarien wie voll vertrauenswürdige Anwendungen, die zuvor den serialisierten Zustand oder Die Daten auf dem lokalen Computer serialisiert haben. Dies ist auch nützlich für Frameworks, in denen Sie das Anwendungsmodell definieren und eine der Standarddateien laden möchten, die das Anwendungsverhalten, das Starten der Benutzeroberfläche oder andere frameworkdefinierte Funktionen definieren, die XAML verwenden.

Load(Stream) weist ähnliche Szenarien auf. Diese Überladung kann nützlich sein, wenn Der Benutzer Dateien lädt, da eine Stream eine häufige Ausgabe anderer System.IO APIs ist, die auf ein Dateisystem zugreifen können. Oder Sie können über asynchrone Downloads oder andere Netzwerktechniken, die auch einen Stream bereitstellen, auf XAML-Quellen zugreifen. (Das Laden aus einem Datenstrom oder einer vom Benutzer ausgewählten Quelle hat möglicherweise Sicherheitsauswirkungen. Weitere Informationen finden Sie unter XAML-Sicherheitsüberlegungen.)

Load(TextReader) und Load(XmlReader) sind Überladungen, die von Lesern von Formaten aus früheren Versionen von .NET abhängig sind. Um diese Überladungen zu verwenden, sollten Sie bereits eine Leseinstanz erstellt und dessen Create-API verwendet haben, um den XAML-Code in der relevanten Form (Text oder XML) zu laden. Wenn Sie Datensatzzeiger bereits in den anderen Lesern verschoben oder andere Vorgänge mit ihnen ausgeführt haben, ist dies nicht wichtig. Die Ladepfadlogik aus Load verarbeitet immer die gesamte XAML-Eingabe aus dem Stamm nach unten. Die folgenden Szenarien können die Verwendung dieser Überladungen garantieren:

  • Entwerfen von Oberflächen, in denen Sie einfache XAML-Bearbeitungsfunktionen aus einem vorhandenen XML-spezifischen Text-Editor bereitstellen.

  • Varianten der wichtigsten System.IO Szenarien, in denen Sie die dedizierten Leser verwenden, um Dateien oder Datenströme zu öffnen. Ihre Logik führt eine rudimentäre Überprüfung oder Verarbeitung des Inhalts durch, bevor sie versucht, als XAML zu laden.

Sie können entweder eine Datei oder einen Stream laden, oder Sie können eine XmlReader, TextReaderoder XamlReader laden, die Ihre XAML-Eingabe umschließt, indem Sie die APIs des Readers laden.

Intern wird jede der vorherigen Überladungen letztendlich Load(XmlReader), und die übergebene XmlReader wird verwendet, um eine neue XamlXmlReaderzu erstellen.

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

  • Sie haben Ihre eigene Implementierung einer XamlReaderdefiniert.

  • 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 Standardleser für XamlServices ist XamlXmlReader. Wenn Sie Eigene XamlXmlReader mit Einstellungen bereitstellen, sind die folgenden Eigenschaften zum Festlegen von nicht standardmäßigen XamlXmlReaderSettings:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Analysieren

Parse ist wie Load, da es sich um eine Ladepfad-API handelt, die einen XAML-Knotenstream aus XAML-Eingaben erstellt. In diesem Fall wird die XAML-Eingabe jedoch direkt als Zeichenfolge bereitgestellt, die den gesamten zu ladenden XAML-Code enthält. Parse ist ein einfacher Ansatz, der für Anwendungsszenarien besser geeignet ist als Frameworkszenarien. Weitere Informationen finden Sie unter Parse. Parse ist nur ein umschlossener Load(XmlReader) Aufruf, der intern eine StringReader umfasst.

Retten

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

Das Eingabeobjekt wird erwartet, dass es sich um das Stammobjekt einer Objektdarstellung handelt. Dies kann der einzelne Stamm eines Geschäftsobjekts, der Stamm einer Objektstruktur für eine Seite in einem Benutzeroberflächenszenario, die Arbeitsbearbeitungsoberfläche aus einem Designtool oder andere Stammobjektkonzepte sein, die für Szenarien geeignet sind.

In vielen Szenarien bezieht sich die objektstruktur, die Sie speichern, auf einen ursprünglichen Vorgang, der XAML entweder mit Load oder mit einer anderen API geladen hat, die von einem Framework/Anwendungsmodell implementiert wurde. Es können Unterschiede in der Objektstruktur erfasst werden, die auf Zustandsänderungen zurückzuführen sind, Änderungen, bei denen ihre Anwendung Laufzeiteinstellungen von einem Benutzer erfasst hat, XAML geändert hat, da ihre Anwendung eine XAML-Entwurfsoberfläche usw. ist. Mit oder ohne Änderungen wird das Konzept des ersten Ladens von XAML aus dem Markup und anschließendes Erneutes Speichern und Vergleichen der beiden XAML-Markupformulare manchmal als Roundtripdarstellung des XAML bezeichnet.

Die Herausforderung beim Speichern und Serialisieren eines komplexen Objekts, das in einem Markupformular festgelegt wird, besteht darin, eine Balance zwischen vollständiger Darstellung ohne Informationsverlust und Ausführlichkeit zu erzielen, die den XAML-Code weniger menschlich lesbar macht. Darüber hinaus haben unterschiedliche Kunden für XAML möglicherweise unterschiedliche Definitionen oder Erwartungen für die Festlegung dieses Gleichgewichts. Die Save-APIs stellen eine Definition dieses Saldos dar. Die Save-APIs verwenden den verfügbaren XAML-Schemakontext und die standardmäßigen CLR-basierten Merkmale von XamlType, XamlMemberund anderen systeminternen XAML- und XAML-Typsystemkonzepten, um zu bestimmen, wo bestimmte XAML-Knotenstreamkonstrukte optimiert werden können, wenn sie wieder in Markup gespeichert werden. Beispielsweise können XamlServices Speicherpfade CLR-basiertes XAML-Standardschemakontext verwenden, um XamlType für Objekte aufzulösen, eine XamlType.ContentPropertyzu bestimmen und dann Eigenschaftselementtags auslassen, wenn sie die Eigenschaft in den XAML-Inhalt des Objekts schreiben.

Umwandeln

Transform XAML konvertiert oder transformiert, indem ein Ladepfad und ein Speicherpfad als einzelner Vorgang verknüpft werden. Ein anderer Schemakontext oder ein anderes Sicherungstypsystem kann für XamlReader und XamlWriterverwendet werden, was beeinflusst, wie der resultierende XAML-Code transformiert wird. Dies eignet sich gut für umfassende Transformationsvorgänge.

Für Vorgänge, die auf der Untersuchung der einzelnen Knoten in einem XAML-Knotendatenstrom basieren, verwenden Sie in der Regel nicht Transform. Stattdessen müssen Sie ihre eigene Speicherpfad-Pfad-Vorgangsreihe definieren und Ihre eigene Logik ins Querwerfen einfügen. Verwenden Sie in einem der Pfade ein XAML-Reader-/XAML-Writer-Paar um Ihre eigene Knotenschleife. Laden Sie z. B. den anfänglichen XAML-Code mit XamlXmlReader, und treten Sie mit aufeinander folgenden Read Aufrufen in die Knoten ein. Wenn Sie auf der XAML-Knotendatenstromebene arbeiten, können Sie jetzt einzelne Knoten (Typen, Member, andere Knoten) anpassen, um eine Transformation anzuwenden, oder den Knoten as-islassen. Anschließend senden Sie den Knoten weiter an die relevante Write-API eines XamlObjectWriter und schreiben das Objekt aus. Weitere Informationen finden Sie unter Grundlegendes zu XAML-Knotenstromstrukturen und -Konzepten.

Siehe auch