Limitations de sérialisation de XamlWriter.Save

L’API Save peut être utilisée pour sérialiser le contenu d’une application WPF (Windows Presentation Foundation) en tant que fichier XAML (Extensible Application Markup Language). Toutefois, il existe quelques limitations importantes dans ce qui peut être sérialisé. Ces restrictions et certaines considérations d’ordre général sont abordées dans cette rubrique.

Représentation au moment de l’exécution, et non du design

La philosophie de base de ce qui est sérialisé par un appel est Save 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 de la conception du fichier XAML d’origine peuvent déjà être optimisées ou perdues au moment où le code XAML est chargé en tant qu’objets en mémoire et ne sont pas conservés lorsque vous appelez Save à sérialiser. Le résultat sérialisé est une représentation efficace de l’arborescence logique construite de l’application, mais pas nécessairement du code XAML d’origine qui l’a produit. Ces problèmes rendent extrêmement difficile l’utilisation de la Save sérialisation dans le cadre d’une aire de conception XAML étendue.

La sérialisation est autonome

La sortie sérialisée est Save autonome ; tout ce qui est sérialisé est contenu dans une seule page XAML, avec un élément racine unique et aucune référence externe autre que les URI. Par exemple, si votre page référence des ressources d’application, celles-ci apparaissent comme un composant de la page en cours de sérialisation.

Les références d’extension sont déréférencées

Les références d’objets communes effectuées dans divers formats d’extension de balisage, tels que StaticResource ou Binding, seront déréférencées par le processus de sérialisation. Celles-ci ont déjà été déréférentes au moment où des objets en mémoire ont été créés par le runtime d’application, et la Save logique ne réexamine pas le code XAML d’origine pour restaurer ces références à la sortie sérialisée. Ceci peut forcer l’utilisation d’une valeur liée aux données ou obtenue par des ressources comme dernière valeur utilisée par la représentation au moment de l’exécution, avec seulement une possibilité limitée ou indirecte de distinguer cette valeur des autres valeurs définies localement. Les images sont également sérialisées en tant que références d’objets aux images telles qu’elles existent dans le projet, plutôt que comme références sources d’origine, en perdant le nom de fichier ou l’URI référencés à l’origine. Même les ressources déclarées au sein de la même page sont sérialisées à l’endroit où elles étaient référencées, au lieu d’être conservées en tant que clé d’une collection de ressources.

La gestion des événements n’est pas conservée

Lorsque les gestionnaires d’événements ajoutés via XAML sont sérialisés, ils ne sont pas conservés. XAML sans code-behind (et sans le mécanisme x :Code associé) n’a aucun moyen de sérialiser la logique procédurale du runtime. Étant donné que la sérialisation est autonome et limitée à l’arborescence logique, il n’existe aucun mécanisme permettant de stocker les gestionnaires d’événements. Par conséquent, les attributs du gestionnaire d’événements, à la fois l’attribut lui-même et la valeur de chaîne qui nomme le gestionnaire, sont supprimés du code XAML de sortie.

Scénarios réalistes d’utilisation de XAMLWriter.Save

Bien que les limitations répertoriées ici soient assez substantielles, il existe encore plusieurs scénarios appropriés pour l’utilisation Save pour la sérialisation.

• Sortie de vecteurs ou de graphiques : la sortie de la zone de rendu peut être utilisée pour reproduire les mêmes vecteurs ou graphiques lors du rechargement.

• Documents dynamiques et au format RTF : le texte, ainsi que toutes les mises en forme et imbrications des éléments qu’ils contiennent sont conservés dans la sortie. Ceci peut être utile pour les mécanismes qui se rapprochent de la fonctionnalité de Presse-papiers.

• Conservation des données d’objet métier : si vous avez stocké des données dans des éléments personnalisés, tels que des données XML, tant que vos objets métier suivent des règles XAML de base telles que la fourniture de constructeurs personnalisés et la conversion pour les valeurs de propriété par référence, ces objets métier peuvent être perpétués par sérialisation.