Classe XAMLServices et lecture ou écriture XAML de base
XamlServices est une classe fournie par les services XAML .NET Framework qui peut être utilisée dans le cadre des scénarios XAML ne nécessitant pas d'accès spécifique au flux de nœud XAML ou aux informations de système de type XAML obtenues à partir de ces nœuds. L'API de XamlServices peut se résumer 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 pour fournir une technique qui associe un chemin de chargement et un chemin d'enregistrement. 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 existant entre des surcharges de méthode particulières.
Cette rubrique comprend les sections suivantes.
- Chargement
- Parse
- Enregistrer
- Transform
- Rubriques connexes
Chargement
Différentes surcharges de Load implémentent la logique complète d'un chemin de chargement. Le chemin de chargement importe du XAML dans une certaine forme et exporte un flux de nœud XAML. La plupart de ces chemins de chargement importent du 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 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 à l'ordinateur local. Elle est également utile pour les infrastructures dans lesquelles vous définissez le modèle de l'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 de 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 d'un flux de données ou d'une source choisie par l'utilisateur peut avoir des conséquences sur la sécurité. (Pour plus d'informations, consultez Considérations sur la sécurité XAML).
Load(TextReader) et Load(XmlReader) sont des surcharges qui reposent sur des lecteurs de formats des versions antérieures du .NET Framework. Pour utiliser ces surcharges, vous auriez déjà dû créer une instance de lecteur et utiliser son API Create pour charger le code XAML au format 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 associés à ces surcharges peuvent inclure les éléments suivants :
Aires de conception dans lesquelles vous fournissez des fonctions d'édition XAML simples à partir d'un éditeur de texte XML existant.
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 bien encore un XmlReader, un TextReader ou un XamlReader qui inclut dans un wrapper votre entrée XAML en procédant au chargement avec les API de ce 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 de XamlReader.
Vous devez spécifier des paramètres pour XamlReader qui diffèrent des paramètres par défaut.
Voici des exemples de paramètres autres que ceux par défaut : AllowProtectedMembersOnRoot, BaseUri, IgnoreUidsOnPropertyElements, LocalAssembly et ValuesMustBeString. Le lecteur par défaut de XamlServices est XamlXmlReader. Si vous fournissez votre propre XamlXmlReader, avec des paramètres, les éléments suivants sont des propriétés permettant de définir des XamlXmlReaderSettings, CloseInput, SkipXmlCompatibilityProcessing, XmlLang et XmlSpacePreserve autres que ceux par défaut.
Parse
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 ne le sont les scénarios d'infrastructure. Pour plus d'informations, consultez Parse. Parse n'est en réalité qu'un appel Load(XmlReader) inclus dans un wrapper qui implique un StringReader en interne.
Enregistrer
Différentes surcharges de Save implémentent le chemin d'enregistrement. Les méthodes Save importent toutes un graphique d'objets et exportent un flux, un fichier ou une instance XmlWriter/TextWriter.
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 associé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/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, des modifications de XAML 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 ensemble d'objets complexes dans une forme de balisage réside dans l'obtention d'un équilibre satisfaisant 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 de Save utilisent un contexte de schéma XAML disponible et les caractéristiques CLR par défaut de XamlType, XamlMember et d'autres concepts d'intrinsèque 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 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.
Transform
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 XAML obtenu. Cela fonctionne bien pour les opérations de transformation relativement 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 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 Fonctionnement des concepts et structures du flux de nœud XAML.