Serialisierungseinschränkungen für XamlWriter.Save
Aktualisiert: November 2007
APISave kann verwendet werden, um den Inhalt einer Windows Presentation Foundation (WPF)-Anwendung als eine Extensible Application Markup Language (XAML)-Datei zu serialisieren. Im Hinblick darauf, was genau serialisiert wird, gibt es jedoch einige wichtige Einschränkungen. Diese Einschränkungen und einige allgemeine Überlegungen werden in diesem Thema behandelt.
Dieses Thema enthält folgende Abschnitte.
- Laufzeit- statt Entwurfszeitdarstellung
- Die Serialisierung ist in sich geschlossen
- Erweiterungsverweise werden dereferenziert
- Ereignisbehandlung wird nicht beibehalten
- Realistische Szenarien für die Verwendung von XAMLWriter.Save
Laufzeit- statt Entwurfszeitdarstellung
Die grundlegende Strategie dafür, was durch einen Aufruf an Save serialisiert wird, ist, dass das Resultat eine Darstellung des serialisierten Objekts zur Laufzeit sein wird. Viele Entwurfszeiteigenschaften der ursprünglichen XAML-Datei sind zu dem Zeitpunkt, zu dem XAML als Objekt im Arbeitsspeicher geladen wird, bereits optimiert oder verloren gegangen und werden nicht beibehalten, wenn Sie Save zum Serialisieren aufrufen. Das serialisierte Resultat ist eine effektive Darstellung der konstruierten logischen Struktur der Anwendung, aber nicht unbedingt der ursprünglichen XAML, aus der es erzeugt wurde. Aufgrund dieser Probleme ist es extrem schwierig, die Save-Serialisierung als Teil einer umfassenden XAML-Entwurfsoberfläche zu verwenden.
Die Serialisierung ist in sich geschlossen
Die serialisierte Ausgabe von Save ist in sich geschlossen. Alles, was serialisiert wird, ist in einer einzigen XAML-Seite enthalten, es gibt ein einziges Stammelement und keine externen Verweise außer URIs. Wenn Ihre Seite beispielsweise auf Ressourcen aus Anwendungsressourcen verweist, werden diese so angezeigt, als wären sie eine Komponente der Seite, die serialisiert wird.
Erweiterungsverweise werden dereferenziert
Allgemeine Verweise auf Objekte in verschiedenen Markuperweiterungsformaten wie StaticResource oder Binding werden durch den Serialisierungsprozess dereferenziert. Diese wurden bereits zu der Zeit dereferenziert, zu der Objekte im Arbeitsspeicher von der Laufzeitanwendung erstellt wurden, und die Save-Logik kehrt nicht zur ursprünglichen XAML zurück, um solche Verweise in der serialisierten Ausgabe wiederherzustellen. Dies sperrt möglicherweise alle datengebundenen oder aus Ressourcen abgerufenen Werte auf die zuletzt von der Darstellung zur Laufzeit verwendeten Werte, wobei es nur eingeschränkt oder indirekt möglich ist, einen solchen Wert von anderen lokal festgelegten Werten zu unterscheiden. Bilder werden auch als Objektverweise auf Bilder serialisiert, da sie im Projekt statt in den ursprünglichen Quellverweisen enthalten sind, wobei der Dateiname oder URI verloren geht, auf den ursprünglich verwiesen wurde. Selbst Ressourcen, die auf derselben Seite deklariert werden, werden in den Punkt serialisiert, von dem aus auf sie verwiesen wurde, statt als Schlüssel einer Ressourcenauflistung erhalten zu bleiben.
Ereignisbehandlung wird nicht beibehalten
Wenn durch XAML hinzugefügte Ereignishandler serialisiert werden, werden sie nicht beibehalten. XAML ohne Code-Behind (und auch ohne den zugehörigen x:Code-Mechanismus) kann prozedurale Logik zur Laufzeit nicht serialisieren. Da Serialisierung in sich geschlossen und auf die logische Struktur beschränkt ist, gibt es keine Möglichkeit zur Speicherung der Eventhandler. Folglich werden Eventhandlerattribute, sowohl das Attribut selbst als auch der Zeichenfolgenwert, der den Handler benennt, aus der XAML-Ausgabe entfernt.
Realistische Szenarien für die Verwendung von XAMLWriter.Save
Obwohl die hier aufgeführten Einschränkungen beträchtlich sind, gibt es doch mehrere Szenarien, in denen Save für die Serialisierung geeignet ist.
Vektorausgabe oder grafische Ausgabe: Die Ausgabe des gerenderten Bereichs kann verwendet werden, um beim erneuten Laden den gleichen Vektor oder die gleichen Grafiken zu reproduzieren.
Rich-Text- und Flussdokumente: Text und jegliche darin enthaltene Elementformatierung sowie Elementkapselung wird in der Ausgabe beibehalten. Dies kann für Mechanismen nützlich sein, die einer Zwischenablagefunktionalität ähneln.
Erhalten von Daten für Geschäftsobjekte: Wenn Sie Daten in benutzerdefinierten Elementen speichern, beispielsweise XML-Daten, können diese Geschäftsobjekte durch Serialisierung beibehalten werden. Dies setzt voraus, dass bei den Geschäftsobjekten grundlegende XAML-Regeln befolgt werden, beispielsweise das Bereitstellen von benutzerdefinierten Konstruktoren und das Konvertieren für durch Verweis übergebene Eigenschaftenwerte.