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 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.

Durée d'exécution, et 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é, en temps d'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 Self-Contained

La sortie sérialisée de Save est indépendante : 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 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érençées

Les références courantes aux objets créées par différents 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. Cela peut potentiellement figer toute valeur liée par la liaison de données ou obtenue à partir d'une ressource pour être celle utilisée en dernier par la représentation en temps d'exécution, avec une capacité limitée ou indirecte à la distinguer 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 substantielles, il existe encore plusieurs scénarios appropriés pour l’utilisation 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, tout comme la mise en forme des éléments et leur inclusion, est conservé dans la sortie. Cela peut être utile pour les mécanismes qui simulent 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.