XAML-Dienste

In diesem Thema werden die Funktionen eines Technologiesatzes beschrieben, der als .NET-XAML-Dienste bezeichnet wird. Die meisten der beschriebenen Dienste und APIs befinden sich in der Assembly System.Xaml. Zu den Diensten gehören Leser und Autoren, Schemaklassen und Schemaunterstützung, Fabriken, Attributieren von Klassen, systeminterne XAML-Sprachunterstützung und andere XAML-Sprachfeatures.

Informationen zu dieser Dokumentation

Konzeptionelle Dokumentation für .NET XAML Services geht davon aus, dass Sie bereits erfahrungen mit der XAML-Sprache haben und wie sie auf ein bestimmtes Framework angewendet werden können, z. B. Windows Presentation Foundation (WPF) oder Windows Workflow Foundation, oder einen bestimmten Technologiefeaturebereich, z. B. die Buildanpassungsfeatures in Microsoft.Build.Framework.XamlTypes. In dieser Dokumentation wird nicht versucht, die Grundlagen von XAML als Markupsprache, XAML-Syntaxterminologie oder andere Einführungsmaterialien zu erläutern. Stattdessen konzentriert sich diese Dokumentation speziell auf die Verwendung von .NET XAML-Diensten, die in der System.Xaml-Assemblybibliothek aktiviert sind. Die meisten dieser APIs gelten für Szenarien der XAML-Sprachintegration und Erweiterbarkeit. Dies kann eins der folgenden Szenarien sein:

• Erweitern der Funktionen der XAML-Basisleser oder XAML-Autoren (direkte Verarbeitung des XAML-Knotenstreams; Ableiten eines eigenen XAML-Readers oder XAML-Writers).

• Definieren von benutzerdefinierten XAML-verwendbaren Typen ohne spezifische Frameworkabhängigkeiten und Attributieren der Typen, um ihre XAML-Typsystemmerkmale für .NET XAML-Dienste zu übermitteln.

• Hosten von XAML-Lesern oder XAML-Autoren als Komponente einer Anwendung, z. B. visueller Designer oder interaktiver Editor für XAML-Markupquellen.

• Schreiben von XAML-Wertkonvertern (Markuperweiterungen; Typkonverter für benutzerdefinierte Typen).

• Definieren eines benutzerdefinierten XAML-Schemakontexts (unter Verwendung alternativer Assemblyladetechniken für das Sichern von Typquellen; Verwenden bekannter Typen-Nachschlagetechniken anstelle von immer reflektierenden Assemblys; Verwenden von geladenen Assemblykonzepten, die nicht die Common Language Runtime (CLR)-AppDomain und das zugehörige Sicherheitsmodell verwenden).

• Erweitern des Basis-XAML-Typsystems.

• Verwenden der Lookup- oder Invoker-Techniken, um das XAML-Typsystem und die Auswertung von Typsicherungen zu beeinflussen.

Wenn Sie ein einführungsmaterial für XAML als Sprache suchen, können Sie XAML-Übersicht (WPF .NET)ausprobieren. In diesem Thema wird XAML für eine Zielgruppe erläutert, die sowohl für Windows Presentation Foundation (WPF) als auch für die Verwendung von XAML-Markup- und XAML-Sprachfeatures neu ist. Ein weiteres nützliches Dokument ist das Einführungsmaterial in der XAML-Sprachspezifikation.

.NET XAML-Dienste und System.Xaml in der .NET-Architektur

.NET-XAML-Dienste und die System.Xaml Assembly definieren einen Großteil der erforderlichen Elemente für die Unterstützung von XAML-Sprachfeatures. Dazu gehören Basisklassen für XAML-Leser und XAML-Autoren. Das wichtigste Feature, das .NET XAML Services hinzugefügt wurde, das in keiner der frameworkspezifischen XAML-Implementierungen vorhanden war, ist eine Typsystemdarstellung für XAML. Die Typsystemdarstellung stellt XAML auf objektorientierte Weise dar, die sich auf XAML-Funktionen zentriert, ohne abhängigkeiten von bestimmten Funktionen von Frameworks zu verwenden.

Das XAML-Typsystem ist nicht durch das Markupformular oder laufzeitspezifische Daten des XAML-Ursprungs beschränkt; es ist auch nicht durch ein bestimmtes Sicherungstypsystem beschränkt. Das XAML-Typsystem enthält Objektdarstellungen für Typen, Member, XAML-Schemakontexte, KONZEPTE auf XML-Ebene und andere systeminterne XAML-Sprachkonzepte. Die Verwendung oder Erweiterung des XAML-Typsystems ermöglicht es, von Klassen wie XAML-Lesern und XAML-Autoren abzuleiten und die Funktionalität von XAML-Darstellungen auf bestimmte Features zu erweitern, die von einem Framework, einer Technologie oder einer Anwendung aktiviert werden, die XAML verwendet oder ausgibt. Das Konzept eines XAML-Schemakontexts ermöglicht praktische Objektdiagramm-Schreibvorgänge aus der Kombination einer XAML-Objektschreiberimplementierung, dem Sicherungstypsystem einer Technologie, die über Assemblyinformationen im Kontext und die XAML-Knotenquelle kommuniziert wird. Weitere Informationen zum XAML-Schemakonzept. siehe Standard-XAML-Schemakontext und WPF-XAML-Schemakontext.

XAML-Knotenstreams, XAML-Leser und XAML-Autoren

Um die Rolle zu verstehen, die .NET XAML Services in der Beziehung zwischen der XAML-Sprache und bestimmten Technologien spielt, die XAML als Sprache verwenden, ist es hilfreich, das Konzept eines XAML-Knotenstreams zu verstehen und wie dieses Konzept die API und Terminologie gestaltet. Der XAML-Knotenstream ist ein konzeptioneller Zwischenschritt zwischen einer XAML-Sprachdarstellung und dem Objektdiagramm, das der XAML-Code darstellt oder definiert.

• Ein XAML-Reader ist eine Entität, die XAML in irgendeiner Form verarbeitet und einen XAML-Knotendatenstrom erzeugt. In der API wird ein XAML-Reader durch die Basisklasse XamlReaderdargestellt.

• Ein XAML-Writer ist eine Entität, die einen XAML-Knotenstream verarbeitet und etwas anderes erzeugt. In der API wird ein XAML-Writer durch die Basisklasse XamlWriterdargestellt.

  Die beiden am häufigsten verwendeten Szenarien mit XAML laden XAML, um ein Objektdiagramm zu instanziieren und ein Objektdiagramm aus einer Anwendung oder einem Tool zu speichern und eine XAML-Darstellung zu erzeugen (in der Regel in Markupform, die als Textdatei gespeichert wird). Das Laden von XAML und das Erstellen eines Objektdiagramms wird in dieser Dokumentation häufig als Ladepfad bezeichnet. Das Speichern oder Serialisieren eines vorhandenen Objektdiagramms in XAML wird häufig in dieser Dokumentation als Speicherpfad bezeichnet.

  Der häufigste Typ des Ladepfads kann wie folgt beschrieben werden:

• Beginnen Sie mit einer XAML-Darstellung, im UTF-codierten XML-Format und als Textdatei gespeichert.

• Laden Sie diesen XAML-Code in XamlXmlReader. XamlXmlReader ist eine XamlReader Unterklasse.

• Das Ergebnis ist ein XAML-Knotenstream. Sie können mithilfe XamlXmlReader / XamlReader-API auf einzelne Knoten des XAML-Knotendatenstroms zugreifen. Der typischste Vorgang besteht darin, den XAML-Knotendatenstrom zu durchlaufen, wobei jeder Knoten mithilfe einer Metapher "aktueller Datensatz" verarbeitet wird.

• Übergeben Sie die resultierenden Knoten aus dem XAML-Knotendatenstrom an eine XamlObjectWriter-API. XamlObjectWriter ist eine XamlWriter Unterklasse.

• Die XamlObjectWriter schreibt ein Objektdiagramm( jeweils ein Objekt) gemäß dem Fortschritt durch den XAML-Quellknotendatenstrom. Das Schreiben von Objekten erfolgt mithilfe eines XAML-Schemakontexts und einer Implementierung, die auf assemblys und Typen eines Sicherungstypsystems und Frameworks zugreifen kann.

• Rufen Sie Result am Ende des XAML-Knotendatenstroms auf, um das Stammobjekt des Objektdiagramms abzurufen.

  Der am häufigsten verwendete Speicherpfadtyp kann wie folgt beschrieben werden:

• Beginnen Sie mit dem Objektdiagramm einer gesamten Anwendungslaufzeit, dem Ui-Inhalt und dem Status einer Laufzeit oder einem kleineren Segment der Objektdarstellung einer gesamten Anwendung zur Laufzeit.

• Laden Sie die Objekte aus einem logischen Startobjekt, z. B. einem Anwendungsstamm oder Einem Dokumentstamm, in XamlObjectReader. XamlObjectReader ist eine XamlReader Unterklasse.

• Das Ergebnis ist ein XAML-Knotenstream. Sie können mit XamlObjectReader und XamlReader-API auf einzelne Knoten des XAML-Knotendatenstroms zugreifen. Der typischste Vorgang besteht darin, den XAML-Knotendatenstrom zu durchlaufen, wobei jeder Knoten mithilfe einer Metapher "aktueller Datensatz" verarbeitet wird.

• Übergeben Sie die resultierenden Knoten aus dem XAML-Knotendatenstrom an eine XamlXmlWriter-API. XamlXmlWriter ist eine XamlWriter Unterklasse.

• Die XamlXmlWriter schreibt XAML in einer XML UTF-Codierung. Sie können dies als Textdatei, als Datenstrom oder in anderen Formularen speichern.

• Rufen Sie Flush auf, um die endgültige Ausgabe abzurufen.

Weitere Informationen zu XAML-Knotenstreamkonzepten finden Sie unter Grundlegendes zu XAML-Knotenstromstrukturen und -Konzepten.

Die XamlServices-Klasse

Es ist nicht immer erforderlich, einen XAML-Knotendatenstrom zu behandeln. Wenn Sie einen einfachen Ladepfad oder einen einfachen Speicherpfad benötigen, können Sie APIs in der XamlServices Klasse verwenden.

• Verschiedene Signaturen von Load implementieren einen Ladepfad. Sie können entweder eine Datei oder einen Stream laden oder eine XmlReader, TextReader oder XamlReader laden, die Ihre XAML-Eingabe umschließen, indem Sie die APIs dieses Readers laden.

• Verschiedene Signaturen von Save speichern ein Objektdiagramm und erzeugen eine Ausgabe als Datenstrom, Datei oder XmlWriter/TextWriter Instanz.

• Transform konvertiert XAML, 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.

Weitere Informationen zur Verwendung von XamlServicesfinden Sie unter XAMLServices Class and Basic XAML Reading or Writing.

XAML-Typsystem

Das XAML-Typsystem stellt die APIs bereit, die für die Arbeit mit einem bestimmten einzelnen Knoten eines XAML-Knotenstreams erforderlich sind.

XamlType ist die Darstellung eines Objekts – was Sie zwischen einem Startobjektknoten und einem Endobjektknoten verarbeiten.

XamlMember ist die Darstellung eines Elements eines Objekts – was Sie zwischen einem Startelementknoten und einem Endmememmknoten verarbeiten.

APIs wie GetAllMembers und GetMember und DeclaringType melden die Beziehungen zwischen einem XamlType und XamlMember.

Das Standardverhalten des XAML-Typsystems, das von .NET XAML Services implementiert wird, basiert auf der Common Language Runtime (CLR) und der statischen Analyse von CLR-Typen in Assemblys mithilfe von Spiegelung. Daher kann für einen bestimmten CLR-Typ die Standardimplementierung des XAML-Typsystems das XAML-Schema dieses Typs und seiner Member verfügbar machen und im Hinblick auf das XAML-Typsystem melden. Im Standardmäßigen XAML-Typsystem wird das Konzept der Zuordnung von Typen zur CLR-Vererbung zugeordnet, und die Konzepte von Instanzen, Werttypen usw. werden auch den unterstützenden Verhaltensweisen und Features der CLR zugeordnet.

Referenz für XAML-Sprachfeatures

Zur Unterstützung von XAML stellt .NET XAML Services spezifische Implementierung von XAML-Sprachkonzepten bereit, die für den XAML-Sprachnamespace definiert sind. Diese werden als bestimmte Referenzseiten dokumentiert. Die Sprachfeatures werden aus der Perspektive dokumentiert, wie sich diese Sprachfeatures verhalten, wenn sie von einem XAML-Reader oder XAML-Writer verarbeitet werden, der von .NET XAML Services definiert wird. Weitere Informationen finden Sie unter XAML-Namespacefeatures (x:).