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 XAML (Extensible Application Markup Language). Toutefois, il existe des limitations notables dans exactement ce qui est sérialisé. Ces limitations et certaines considérations générales sont documentées dans cette rubrique.

Temps d'exécution, non la représentation Design-Time

La philosophie de base de 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 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 pour 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 sérialisation Save dans le cadre d’une aire de conception XAML étendue.

La sérialisation est Self-Contained

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

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

Les références courantes aux objets effectués par différents formats d’extension de balisage, tels que StaticResource ou Binding, seront déréférées par le processus de sérialisation. Celles-ci ont déjà été déréférencées au moment où des objets en mémoire ont été créés par le runtime de l’application, et la logique Save ne retourne pas au XAML d’origine pour restaurer ces références dans la sortie sérialisée. Cela fige potentiellement toute valeur liée aux données ou ressource obtenue pour être la valeur utilisée en dernier lors de l'exécution, avec une capacité limitée ou indirecte de distinguer une telle valeur de toute autre valeur définie 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 dans la même page sont considérées sérialisées dans le point où elles ont été 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 aucune installation pour 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 pour l’utilisation de XAMLWriter.Save

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

• Vecteur ou sortie graphique : la sortie de la zone rendue peut être utilisée pour reproduire le même vecteur ou graphique lors du rechargement.

• Documents de texte enrichi et de flux : le texte, la mise en forme des éléments et le contenu des éléments sont préservés dans le rendu. Cela peut être utile pour les mécanismes qui se rapprochent d’une fonction du 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.