Classe XAMLServices et lecture ou écriture XAML de base

  • Article

XamlServices est une classe fournie par .NET qui peut être utilisée pour traiter des scénarios XAML qui ne nécessitent pas d’accès spécifique au flux de nœuds XAML ou aux informations système de type XAML obtenues à partir de ces nœuds. XamlServices L’API peut être résumée comme suit : Load ou Parse pour prendre en charge un chemin de chargement XAML, Save pour prendre en charge un chemin d’enregistrement XAML et Transform fournir une technique qui joint un chemin de chargement et enregistre le chemin d’accès. Transform peut être utilisé pour passer d'un schéma XAML à un autre. Cette rubrique résume chacune de ces classifications d'API et décrit les différences qui existent entre des surcharges de méthode particulières.

Load

Différentes surcharges de Load implémentent la logique complète d'un chemin de chargement. Le chemin de chargement utilise du code XAML sous une certaine forme et exporte un flux de nœud XAML. La plupart de ces chemins de chargement utilise du code XAML sous la forme d'un fichier texte XML encodé. Toutefois, vous pouvez aussi charger un flux général ou une source XAML préchargée qui est déjà contenue dans une implémentation de XamlReader différente.

La surcharge la plus simple pour la plupart des scénarios est Load(String). Cette surcharge possède un paramètre fileName qui correspond simplement au nom d'un fichier texte contenant le code XAML à charger. Elle convient particulièrement aux scénarios d'application comme pour les applications de confiance totale qui ont précédemment sérialisé l'état ou les données sur l'ordinateur local. Elle est également utile pour les infrastructures dans lesquelles vous définissez le modèle d'application et souhaitez charger l'un des fichiers standard qui définit le comportement de l'application, en démarrant l'interface utilisateur ou d'autres fonctions définies par l'infrastructure qui utilisent XAML.

Load(Stream) dispose de scénarios similaires. Cette surcharge peut s'avérer utile si l'utilisateur choisit les fichiers à charger, car un Stream est une sortie fréquente d'autres API System.IO qui peuvent accéder à un système de fichiers. Vous pouvez également accéder aux sources XAML par le biais de téléchargements asynchrones ou d'autres techniques de réseau qui fournissent également un flux. (Le chargement à partir d’un flux ou d’une source sélectionnée par l’utilisateur peut avoir des conséquences sur la sécurité. Pour plus d’informations, consultez Considérations relatives à la sécurité XAML.)

Load(TextReader) et Load(XmlReader) sont des surcharges qui s’appuient sur les lecteurs de formats des versions précédentes de .NET. Pour utiliser ces surcharges, vous devez avoir déjà créé une instance de lecteur et utilisé son Create API pour charger le code XAML dans le formulaire approprié (texte ou XML). Si vous avez déjà déplacé des pointeurs d'enregistrement dans les autres lecteurs ou exécuté d'autres opérations les concernant, cela ne pose aucun problème. La logique du chemin de chargement de Load traite toujours l'entrée XAML entière à partir de la racine. Les scénarios suivants peuvent justifier l’utilisation de ces surcharges :

  • les aires de conception dans lesquelles vous fournissez des fonctions d'édition XAML simples à partir d'un éditeur de texte XML existant ;

  • les variantes des scénarios System.IO de base dans lesquels vous utilisez les lecteurs dédiés pour ouvrir des fichiers ou des flux. Votre logique procède à un contrôle ou un traitement rudimentaire du contenu avant de tenter de le charger en tant que code XAML.

Vous pouvez charger un fichier ou un flux, ou charger un XmlReader, TextReaderou XamlReader qui encapsule votre entrée XAML en chargeant avec les API du lecteur.

En interne, chacune des surcharges précédentes correspond finalement à Load(XmlReader), avec le XmlReader passé qui est utilisé pour créer un XamlXmlReader.

La signature Load permettant des scénarios plus avancés est Load(XamlReader). Vous pouvez utiliser cette signature pour l'un des cas suivants :

  • Vous avez défini votre propre implémentation d’un XamlReader.

  • Vous devez spécifier des paramètres pour XamlReader qui diffèrent des paramètres par défaut.

Exemples de paramètres non par défaut :

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

Le lecteur par défaut de XamlServices est XamlXmlReader. Si vous fournissez vos propres XamlXmlReader paramètres, les propriétés suivantes permettent de définir une valeur autre que la valeur par défaut XamlXmlReaderSettings:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Analyser

Parse s'apparente à Load en ce sens que c'est une API de chemin de chargement qui crée un flux de nœud XAML à partir de l'entrée XAML. Toutefois, dans ce cas, l'entrée XAML est fournie directement sous la forme d'une chaîne qui contient tout le code XAML à charger. Parse est une approche légère plus appropriée pour les scénarios d'application que les scénarios d'infrastructure. Pour plus d’informations, consultez Parse. Parse est simplement un appel encapsulé Load(XmlReader) qui implique un StringReader appel interne.

Enregistrer

Différentes surcharges de Save implémentent le chemin d'enregistrement. Les méthodes Save ont toutes un graphique d'objets comme entrée et génère un flux, un fichier ou une instance XmlWriter/TextWriter comme sortie.

L'objet en entrée est supposé être l'objet racine d'une représentation d'objet. Il peut s'agir de la racine unique d'un objet métier, de la racine d'une arborescence d'objets pour la page d'un scénario d'interface utilisateur, de la surface de modification active d'un outil de conception ou encore d'autres concepts d'objet racine appropriés pour les scénarios.

Dans de nombreux scénarios, l’arborescence d’objets que vous enregistrez est liée à une opération d’origine qui a chargé XAML avec Load ou avec une autre API implémentée par un modèle d’infrastructure/d’application. Il peut y avoir des différences capturées dans l'arborescence d'objets dues à des modifications d'état, des modifications dans lesquelles votre application a capturé des paramètres d'exécution auprès d'un utilisateur, du code XAML modifié car votre application est une aire de conception XAML, etc. Avec ou sans modification, le concept consistant à d'abord charger le code XAML à partir du balisage, puis à le réenregistrer et à comparer les deux formes de balisage XAML est parfois appelé représentation « aller-retour » du code XAML.

Le défi lié à l'enregistrement et à la sérialisation d'un objet complexe qui est défini dans une forme de balisage réside dans l'obtention d'un équilibre entre une représentation complète sans perte d'informations et un excès de commentaires rendant le code XAML moins explicite. De plus, différents clients pour XAML peuvent avoir des définitions ou des attentes différentes concernant la définition de l'équilibre. Les API Save représentent une définition de cet équilibre. Les API Save utilisent un contexte de schéma XAML disponible et les caractéristiques CLR par défaut de XamlType, de XamlMemberet d'autres concepts d'intrinsèque XAML et de système de type XAML pour déterminer si certaines constructions de flux de nœud XAML peuvent être optimisées lorsqu'elles sont réenregistrées dans le balisage. Par exemple, les chemins d'enregistrement XamlServices peuvent utiliser un contexte de schéma XAML par défaut basé sur CLR pour résoudre XamlType pour des objets, déterminer une propriété XamlType.ContentProperty, puis omettre des balises d'éléments de propriété lors de l'écriture de la propriété dans le contenu XAML de cet objet.

Transformation

Transform convertit ou transforme le code XAML en associant un chemin de chargement et un chemin d'enregistrement dans le cadre d'une seule opération. Un contexte de schéma ou un système de types de stockage différent peut être utilisé pour XamlReader et XamlWriter, ce qui est l'élément qui influence le mode de transformation du code XAML obtenu. Cela fonctionne bien pour les opérations de transformation générales.

Pour les opérations qui reposent sur l'examen de chaque nœud dans un flux de nœud XAML, vous n'utiliseriez généralement pas Transform. Au lieu de cela, vous devez définir votre propre série d'opérations chemin de chargement-chemin d'enregistrement et lancer votre propre logique. Dans l'un des chemins, utilisez une paire lecteur XAML/writer XAML autour de votre propre boucle de nœud. Par exemple, chargez le code XAML initial à l'aide de XamlXmlReader et entrez dans les nœuds avec des appels à Read successifs. En opérant au niveau du flux de nœud XAML, vous pouvez maintenant ajuster des nœuds individuels (types, membres ou autres nœuds) pour appliquer une transformation ou laisser le nœud en l'état. Envoyez ensuite le nœud à l'API Write pertinente d'un XamlObjectWriter et écrivez l'objet. Pour plus d'informations, consultez Understanding XAML Node Stream Structures and Concepts.

Voir aussi