Limitations de sérialisation de XamlWriter.Save
L'API Save peut être utilisée pour sérialiser le contenu d'une application Windows Presentation Foundation (WPF) en tant que fichier Extensible Application Markup Language (XAML). Cependant, il existe quelques limitations notables concernant ce qui est exactement sérialisé. Ces limitations, ainsi que des considérations générales, sont documentées dans cette rubrique.
Cette rubrique comprend les sections suivantes.
- Représentation au moment de l'exécution, non au moment du design
- La sérialisation est autonome
- Les références d'extension sont déréférencées
- La gestion d'événements n'est pas conservée
- Scénarios réalistes d'utilisation de XAMLWriter.Save
Représentation au moment de l'exécution, non au moment du design
La philosophie de base concernant ce qui est sérialisé par un appel à Save est que le résultat sera une représentation de l'objet sérialisé, au moment de l'exécution. De nombreuses propriétés au moment du design qui sont dans le fichier XAML d'origine peuvent être déjà optimisées ou perdues au moment où XAML est chargé sous forme d'objets en mémoire, et ne sont pas conservées lorsque vous appelez Save pour effectuer la sérialisation. Le résultat sérialisé est une représentation effective de l'arborescence logique construite de l'application, mais pas nécessairement du XAML d'origine qui l'a produite. Ces questions rendent extrêmement difficile l'utilisation de la sérialisation Save dans le cadre d'une aire de conception XAML importante.
La sérialisation est autonome
La sortie sérialisée de Save est autonome, tout ce qui est sérialisé est contenu à l'intérieur d'une seule page XAML, avec un seul élément racine, et sans références externes autres que des URIs. Par exemple, si votre page référençait des ressources en provenance de ressources d'une application, elles apparaîtront comme si elles étaient un composant de la page sérialisée.
Les références d'extension sont déréférencées
Des références communes à des objets réalisés dans divers formats d'extension de balisage, tels que StaticResource ou Binding, seront déréférencées par le processus de sérialisation. Elles étaient déjà déréférencées au moment où les objets en mémoire étaient créés par l'exécution de l'application, et la logique de Save ne revisite pas le XAML d'origine pour restaurer de telles références dans la sortie sérialisée. Ceci fige potentiellement toute valeur liée aux données ou obtenue depuis une ressource à la dernière valeur utilisée par la représentation au moment de l'exécution, avec uniquement une capacité limitée ou indirecte de distinguer une telle valeur d'une autre quelconque valeur définie localement. Les images sont aussi sérialisées comme des références d'objet vers des images telles qu'elles existent dans le projet, plutôt que comme des références sources d'origine, perdant tout fichier ou URI qui était référencé à l'origine. Même les ressources déclarées au sein de la même page sont sérialisées au point où elles étaient référencées, et non conservées en tant que clé de collection de ressources.
La gestion d'événements n'est pas conservée
Lorsque des gestionnaires d'événements ajoutés via XAML sont sérialisés, ils ne sont pas conservés. XAML sans code-behind (et également sans le mécanisme x:Code associé) n'a aucun moyen de sérialiser la logique procédurale au moment de l'exécution. La sérialisation étant autonome et limitée à l'arborescence logique, il n'existe pas de fonction pour le stockage des gestionnaires d'événements. En conséquence, les attributs du gestionnaire d'événements, l'attribut lui-même ainsi que la valeur de chaîne qui nomme le gestionnaire, sont supprimés de la sortie XAML.
Scénarios réalistes d'utilisation de XAMLWriter.Save
Si les limitations énumérées ici sont importantes, il reste toutefois plusieurs scénarios appropriés pour l'utilisation de Save à des fins de sérialisation.
Sortie vecteur ou graphique : la sortie de la zone rendue peut être utilisée pour reproduire les mêmes vecteurs ou graphiques au moment du rechargement.
Texte au format RTF et documents dynamiques : le texte, ainsi que tous les éléments de formatage et la relation contenant-contenu de l'élément situé à l'intérieur, sont conservés dans la sortie. Ceci peut être utile pour les mécanismes se rapprochant de la fonctionnalité de presse-papiers.
Conservation des données des objets métier : si vous avez stocké des données dans des éléments personnalisés, telles que des données XML, tant que vos objets métier suivent les règles de base de XAML comme la fourniture de constructeurs personnalisés et la conversion pour les valeurs de propriétés par référence, ces objets métier peuvent être perpétués au moyen de la sérialisation.