Structures et concepts de flux de nœuds XAML

Les lecteurs XAML et les enregistreurs XAML implémentés dans les services XAML .NET sont basés sur le concept de conception d’un flux de nœud XAML. Le flux de nœuds XAML est une conceptualisation d’un ensemble de nœuds XAML. Dans cette conceptualisation, un processeur XAML décrit la structure des relations de nœud dans le code XAML un par un. À tout moment, seul un enregistrement actif ou une position actuelle existe dans un flux de nœuds XAML ouvert, et de nombreux aspects du rapport d’API ne fournissent que les informations disponibles à partir de cette position. Le nœud actuel dans un flux de nœud XAML peut être décrit comme étant un objet, un membre ou une valeur. En traitant XAML comme un flux de nœuds XAML, les lecteurs XAML peuvent communiquer avec des enregistreurs XAML et permettre à un programme d’afficher, d’interagir ou de modifier le contenu d’un flux de nœud XAML pendant un chemin de chargement ou une opération de chemin d’enregistrement impliquant XAML. La conception de l’API de lecteur et d’enregistreur XAML et le concept de flux de nœud XAML sont similaires aux conceptions et concepts de lecteur et d’enregistreur précédents, tels que le modèle DOM (Document Object Model) XML et les classes XmlReader et XmlWriter. Cette rubrique décrit les concepts de flux de nœuds XAML et décrit comment écrire des routines qui interagissent avec des représentations XAML au niveau du nœud XAML.

Chargement de XAML dans un lecteur XAML

La classe de base XamlReader ne déclare pas de technique particulière pour charger le code XAML initial dans un lecteur XAML. Au lieu de cela, une classe dérivée déclare et implémente la technique de chargement, y compris les caractéristiques générales et les contraintes de sa source d’entrée pour XAML. Par exemple, une XamlObjectReader lit un graphique d’objet, en commençant par la source d’entrée d’un seul objet qui représente la racine ou la base. Le XamlObjectReader produit ensuite un flux de nœud XAML à partir du graphique d’objets.

La sous-classe XamlReader les services XAML .NET les plus importants est XamlXmlReader. XamlXmlReader charge le code XAML initial, soit en chargeant un fichier texte directement via un flux ou un chemin d’accès de fichier, soit indirectement par le biais d’une classe de lecteur associée, telle que TextReader. La XamlReader peut être considérée comme contenant l’intégralité de la source d’entrée XAML après son chargement. Toutefois, l’API de base XamlReader est conçue pour permettre au lecteur d’interagir avec un seul nœud du code XAML. Lors du premier chargement, le premier nœud unique que vous rencontrez est la racine du code XAML et son objet de démarrage.

Concept de flux de nœuds XAML

Si vous connaissez plus bien un DOM, une métaphore d’arborescence ou une approche basée sur des requêtes pour accéder aux technologies XML, un moyen utile de conceptualiser un flux de nœud XAML est le suivant. Imaginez que le code XAML chargé est un DOM ou une arborescence où chaque nœud possible est développé de manière linéaire, puis présenté de manière linéaire. À mesure que vous avancez dans les nœuds, vous parcourez peut-être « in » ou « out » des niveaux qui seraient pertinents pour un DOM, mais le flux de nœud XAML ne suit pas explicitement, car ces concepts de niveau ne sont pas pertinents pour un flux de nœuds. Le flux de nœuds a une position « actuelle », mais sauf si vous avez stocké d’autres parties du flux vous-même en tant que références, chaque aspect du flux de nœud autre que la position actuelle du nœud est hors vue.

Le concept de flux de nœud XAML présente l’avantage notable que si vous parcourez l’ensemble du flux de nœuds, vous êtes assuré que vous avez traité l’intégralité de la représentation XAML ; vous n’avez pas besoin de vous soucier qu’une requête, une opération DOM ou une autre approche non linéaire du traitement des informations a manqué une partie de la représentation XAML complète. Pour cette raison, la représentation de flux de nœud XAML est idéale pour connecter des lecteurs XAML et des enregistreurs XAML et pour fournir un système dans lequel vous pouvez insérer votre propre processus qui agit entre les phases de lecture et d’écriture d’une opération de traitement XAML. Dans de nombreux cas, l’ordre des nœuds dans le flux de nœuds XAML est délibérément optimisé ou réorganisé par les lecteurs XAML par rapport à la façon dont l’ordre peut apparaître dans le texte source, le binaire ou le graphique d’objet. Ce comportement est destiné à appliquer une architecture de traitement XAML dans laquelle les enregistreurs XAML ne sont jamais dans une position où ils doivent revenir en arrière dans le flux de nœud. Dans l’idéal, toutes les opérations d’écriture XAML doivent être en mesure d’agir en fonction du contexte de schéma et de la position actuelle du flux de nœuds.

Boucle de nœud de lecture de base

Une boucle de nœud de lecture de base pour examiner un flux de nœud XAML se compose des concepts suivants. Dans le cadre des boucles de nœud décrites dans cette rubrique, supposons que vous lisez un fichier XAML lisible par un texte à l’aide de XamlXmlReader. Les liens de cette section font référence à l’API de boucle de nœud XAML particulière implémentée par XamlXmlReader.

• Assurez-vous que vous n’êtes pas à la fin du flux de nœud XAML (vérifiez IsEof, ou utilisez la valeur de retour Read). Si vous êtes à la fin du flux, il n’y a pas de nœud actuel et vous devez quitter.

• Vérifiez le type de nœud que le flux de nœuds XAML expose actuellement en appelant NodeType.

• Si vous disposez d’un enregistreur d’objets XAML associé qui est connecté directement, vous appelez généralement WriteNode à ce stade.

• En fonction des XamlNodeType signalées en tant que nœud actuel ou enregistrement actif, appelez l’une des options suivantes pour obtenir des informations sur le contenu du nœud :

  • Pour une NodeType de StartMember ou de EndMember, appelez Member pour obtenir des informations XamlMember sur un membre. Le membre peut être un XamlDirectiveet ne peut donc pas nécessairement être un membre classique défini par type de l’objet précédent. Par exemple, x:Name appliquée à un objet apparaît en tant que membre XAML où IsDirective a la valeur true et que le Name du membre est Name, avec d’autres propriétés indiquant que cette directive se trouve sous l’espace de noms XAML du langage XAML.

  • Pour une NodeType de StartObject ou de EndObject, appelez Type pour obtenir des informations XamlType sur un objet.

  • Pour une NodeType de Value, appelez Value. Un nœud est une valeur uniquement s’il s’agit de l’expression la plus simple d’une valeur pour un membre ou du texte d’initialisation d’un objet (toutefois, vous devez être conscient du comportement de conversion de type tel qu’il est documenté dans une section à venir de cette rubrique).

  • Pour une NodeType de NamespaceDeclaration, appelez Namespace pour obtenir des informations d’espace de noms pour un nœud d’espace de noms.

• Appelez Read pour avancer le lecteur XAML vers le nœud suivant dans le flux de nœuds XAML, puis répétez les étapes.

Le flux de nœuds XAML fourni par les lecteurs XAML des services XAML .NET fournit toujours une traversée complète et approfondie de tous les nœuds possibles. Les techniques de contrôle de flux standard pour une boucle de nœud XAML incluent la définition d’un corps dans while (reader.Read())et le basculement d'NodeType à chaque point de nœud de la boucle de nœud.

Si le flux de nœuds se trouve à la fin du fichier, le nœud actuel a la valeur Null.

La boucle la plus simple qui utilise un lecteur et un enregistreur ressemble à l’exemple suivant.

XamlXmlReader xxr = new XamlXmlReader(new StringReader(xamlStringToLoad));
//where xamlStringToLoad is a string of well formed XAML
XamlObjectWriter xow = new XamlObjectWriter(xxr.SchemaContext);
while (xxr.Read()) {
  xow.WriteNode(xxr);
}

Cet exemple de base d’une boucle de nœud XAML de chemin de chargement connecte de manière transparente le lecteur XAML et l’enregistreur XAML, ne faisant rien de différent que si vous aviez utilisé XamlServices.Parse. Mais cette structure de base est ensuite développée pour s’appliquer à votre scénario de lecture ou d’écriture. Voici quelques scénarios possibles :

• Activez NodeType. Effectuez différentes actions en fonction du type de nœud en cours de lecture.

• N’appelez pas WriteNode dans tous les cas. Appelez uniquement WriteNode dans certains cas NodeType.

• Dans la logique d’un type de nœud particulier, analysez les spécificités de ce nœud et agissez dessus. Par exemple, vous pouvez uniquement écrire des objets provenant d’un espace de noms XAML particulier, puis supprimer ou différer les objets qui ne proviennent pas de cet espace de noms XAML. Vous pouvez également supprimer ou retraiter les directives XAML que votre système XAML ne prend pas en charge dans le cadre du traitement de vos membres.

• Définissez un XamlObjectWriter personnalisé qui remplace les méthodes Write*, ce qui peut entraîner un mappage de type qui contourne le contexte de schéma XAML.

• Construisez l'XamlXmlReader pour utiliser un contexte de schéma XAML non défini, afin que les différences personnalisées de comportement XAML soient utilisées à la fois par le lecteur et l’enregistreur.

Accès xaml au-delà du concept de boucle de nœud

Il existe potentiellement d’autres façons d’utiliser une représentation XAML autre qu’une boucle de nœud XAML. Par exemple, il peut exister un lecteur XAML qui peut lire un nœud indexé, ou en particulier accéder aux nœuds directement par x:Name, par x:Uidou via d’autres identificateurs. Les services XAML .NET ne fournissent pas d’implémentation complète, mais fournissent un modèle suggéré par le biais de services et de types de support. Pour plus d’informations, consultez IXamlIndexingReader et XamlNodeList.

Utilisation du nœud actuel

La plupart des scénarios qui utilisent une boucle de nœud XAML ne lisent pas seulement les nœuds. La plupart des scénarios traitent les nœuds actuels et passent chaque nœud un par un à la fois à une implémentation de XamlWriter.

Dans le scénario de chemin de chargement classique, un XamlXmlReader produit un flux de nœuds XAML ; les nœuds XAML sont traités en fonction de votre logique et du contexte de schéma XAML ; et les nœuds sont passés à un XamlObjectWriter. Vous intégrez ensuite le graphique d’objet résultant dans votre application ou infrastructure.

Dans un scénario de chemin d’enregistrement classique, un XamlObjectReader lit le graphique d’objet, les nœuds XAML individuels sont traités et un XamlXmlWriter génère le résultat sérialisé sous forme de fichier texte XAML. La clé est que les chemins d’accès et les scénarios impliquent l’utilisation exacte d’un nœud XAML à la fois et que les nœuds XAML sont disponibles pour un traitement de manière standardisée définie par le système de type XAML et the.NET API des services XAML.

Cadres et étendue

Une boucle de nœud XAML traverse un flux de nœud XAML de manière linéaire. Le flux de nœud passe en objets, en membres qui contiennent d’autres objets, et ainsi de suite. Il est souvent utile de suivre l’étendue dans le flux de nœuds XAML en implémentant un concept de trame et de pile. Cela est particulièrement vrai si vous ajustez activement le flux de nœud pendant que vous y êtes. La prise en charge de la trame et de la pile que vous implémentez dans le cadre de votre logique de boucle de nœud peut compter StartObject (ou GetObject) et EndObject étendues lorsque vous descendez dans une structure de nœud XAML si la structure est considérée du point de vue DOM.

Parcourir et entrer des nœuds d’objet

Le premier nœud d’un flux de nœuds lorsqu’il est ouvert par un lecteur XAML est le nœud objet de démarrage de l’objet racine. Par définition, cet objet est toujours un nœud d’objet unique et n’a pas d’homologues. Dans n’importe quel exemple XAML réel, l’objet racine est défini pour avoir une ou plusieurs propriétés qui contiennent davantage d’objets, et ces propriétés ont des nœuds membres. Les nœuds membres ont ensuite un ou plusieurs nœuds d’objet, ou peuvent également se terminer dans un nœud valeur à la place. L’objet racine définit généralement des portées de noms XAML, qui sont attribuées de manière syntactique en tant qu’attributs dans le balisage de texte XAML, mais mappent à un type de nœud Namescope dans la représentation de flux de nœud XAML.

Prenons l’exemple XAML suivant (il s’agit d’un code XAML arbitraire, non soutenu par des types existants dans .NET). Supposons que dans ce modèle objet, FavorCollection est List<T> de Favor, Balloon et NoiseMaker sont assignables à Favor, la propriété Balloon.Color est sauvegardée par un objet Color similaire à la façon dont WPF définit les couleurs comme noms de couleurs connus et Color prend en charge un convertisseur de type pour la syntaxe d’attribut.

Dans le flux de nœuds XAML, vous pouvez vous appuyer sur le comportement suivant :

• Si un nœud Namespace existe, il est ajouté au flux immédiatement avant le StartObject qui a déclaré l’espace de noms XAML avec xmlns. Examinez le tableau précédent avec le code XAML et l’exemple de flux de nœud à nouveau. Notez comment les nœuds StartObject et Namespace semblent être transposes par rapport à leurs positions de déclaration dans le balisage de texte. Cela représente le comportement dans lequel les nœuds d’espace de noms apparaissent toujours devant le nœud auquel ils s’appliquent dans le flux de nœuds. L’objectif de cette conception est que les informations d’espace de noms sont vitales pour les enregistreurs d’objets et doivent être connues avant que l’enregistreur d’objets tente d’effectuer un mappage de type ou de traiter l’objet. Le fait de placer les informations d’espace de noms XAML à l’avance de son étendue d’application dans le flux facilite le traitement du flux de nœuds dans son ordre présenté.

• En raison de la considération ci-dessus, il s’agit d’un ou plusieurs nœuds Namespace que vous lisez en premier dans la plupart des cas de balisage réels lors de la traversée des nœuds à partir du début, et non les StartObject de la racine.

• Un nœud StartObject peut être suivi de StartMember, de Valueou d’une EndObjectimmédiate. Il n’est jamais suivi immédiatement par un autre StartObject.

• Un StartMember peut être suivi d’un StartObject, d’un Valueou d’une EndMemberimmédiate. Il peut être suivi de GetObject, pour les membres où la valeur est censée provenir d’une valeur existante de l’objet parent plutôt que d’un StartObject qui instancie une nouvelle valeur. Il peut également être suivi d’un nœud Namespace, qui s’applique à une StartObjectà venir. Il n’est jamais suivi immédiatement par un autre StartMember.

• Un nœud Value représente la valeur elle-même ; il n’y a pas de « EndValue ». Elle ne peut être suivie que d’un EndMember.

  • Le texte d’initialisation XAML de l’objet, tel qu’il peut être utilisé par la construction, n’entraîne pas de structure Object-Value. Au lieu de cela, un nœud membre dédié pour un membre nommé _Initialization est créé. et ce nœud membre contient la chaîne de valeur d’initialisation. S’il existe, _Initialization est toujours la première StartMember. _Initialization peut être qualifié dans certaines représentations des services XAML avec le namescope XAML du langage XAML, pour clarifier que _Initialization n’est pas une propriété définie dans les types de stockage.

  • Une combinaison Member-Value représente un paramètre d’attribut de la valeur. Un convertisseur de valeur peut éventuellement être impliqué dans le traitement de cette valeur, et la valeur est une chaîne simple. Toutefois, cela n’est pas évalué tant qu’un enregistreur d’objets XAML ne traite pas ce flux de nœuds. L’enregistreur d’objets XAML possède le contexte de schéma XAML nécessaire, le mappage de système de type et d’autres prise en charge nécessaires pour les conversions de valeurs.

• Un nœud EndMember peut être suivi d’un nœud StartMember pour un membre ultérieur ou d’un nœud EndObject pour le propriétaire du membre.

• Un nœud EndObject peut être suivi d’un nœud EndMember. Il peut également être suivi d’un nœud StartObject pour les cas où les objets sont des homologues dans les éléments d’une collection. Ou il peut être suivi d’un nœud Namespace, qui s’applique à une StartObjectà venir .

  • Pour le cas unique de fermeture du flux de nœud entier, la EndObject de la racine n’est suivie d’aucun élément ; le lecteur est désormais de bout en bout et Read retourne false.

Convertisseurs de valeurs et flux de nœuds XAML

Un convertisseur de valeur est un terme général pour une extension de balisage, un convertisseur de type (y compris les sérialiseurs de valeur) ou une autre classe dédiée signalée comme convertisseur de valeur via le système de type XAML. Dans le flux de nœuds XAML, une utilisation du convertisseur de type et une utilisation d’extension de balisage ont des représentations très différentes.

Convertisseurs de types dans le flux de nœuds XAML

Un jeu d’attributs qui aboutit à une utilisation d’un convertisseur de type est signalé dans le flux de nœud XAML comme valeur d’un membre. Le flux de nœud XAML n’essaie pas de produire un objet d’instance de convertisseur de type et de lui transmettre la valeur. L’utilisation de l’implémentation de conversion d’un convertisseur de type nécessite d’appeler le contexte de schéma XAML et de l’utiliser pour le mappage de type. Même en déterminant la classe de convertisseur de type à utiliser pour traiter la valeur, le contexte de schéma XAML doit être indirectement utilisé. Lorsque vous utilisez le contexte de schéma XAML par défaut, ces informations sont disponibles à partir du système de type XAML. Si vous avez besoin des informations de classe de convertisseur de type au niveau du flux de nœud XAML avant la connexion à un enregistreur XAML, vous pouvez l’obtenir à partir des informations XamlMember du membre en cours de définition. Dans le cas contraire, l’entrée du convertisseur de type doit être conservée dans le flux de nœud XAML sous la forme d’une valeur simple jusqu’à ce que le reste des opérations nécessitant le système de mappage de type et le contexte de schéma XAML soient effectués, par exemple la création d’objets par un enregistreur d’objets XAML.

Par exemple, considérez le plan de définition de classe et l’utilisation XAML suivants :

public class BoardSizeConverter : TypeConverter {
  //converts from string to an int[2] by splitting on an "x" char
}
public class GameBoard {
  [TypeConverter(typeof(BoardSizeConverter))]
  public int[] BoardSize; //2x2 array, initialization not shown
}

<GameBoard BoardSize="8x8"/>

Une représentation textuelle du flux de nœud XAML pour cette utilisation peut être exprimée comme suit :

StartObject avec XamlType représentant GameBoard

StartMember avec XamlMember représentant BoardSize

nœud Value, avec chaîne de texte «8x8»

EndMember correspond à BoardSize

EndObject correspond à GameBoard

Notez qu’il n’existe aucune instance de convertisseur de type dans ce flux de nœuds. Mais vous pouvez obtenir des informations de convertisseur de type en appelant XamlMember.TypeConverter sur le XamlMember pour BoardSize. Si vous avez un contexte de schéma XAML valide, vous pouvez également appeler les méthodes de convertisseur en obtenant une instance à partir de ConverterInstance.

Extensions de balisage dans le flux de nœuds XAML

Une utilisation de l’extension de balisage est signalée dans le flux de nœud XAML en tant que nœud d’objet au sein d’un membre, où l’objet représente une instance d’extension de balisage. Par conséquent, une utilisation de l’extension de balisage est présentée plus explicitement dans la représentation du flux de nœud qu’une utilisation d’un convertisseur de type et contient plus d’informations. XamlMember informations n’ont pas pu vous dire quoi que ce soit sur l’extension de balisage, car l’utilisation est situationnelle et varie dans chaque cas de balisage possible ; il n’est pas dédié et implicite par type ou membre, comme c’est le cas avec les convertisseurs de type.

La représentation de flux de nœud des extensions de balisage en tant que nœuds d’objet est le cas même si l’utilisation de l’extension de balisage a été effectuée sous forme d’attribut dans le balisage de texte XAML (ce qui est souvent le cas). Les utilisations d’extension de balisage qui utilisaient un formulaire d’élément d’objet explicite sont traitées de la même façon.

Dans un nœud objet d’extension de balisage, il peut y avoir des membres de cette extension de balisage. La représentation de flux de nœud XAML conserve l’utilisation de cette extension de balisage, qu’il s’agisse d’une utilisation de paramètres positionnels ou d’une utilisation avec des paramètres nommés explicites.

Pour une utilisation des paramètres positionnels, le flux de nœuds XAML contient une propriété définie par le langage XAML _PositionalParameters qui enregistre l’utilisation. Cette propriété est une List<T> générique avec Object contrainte. La contrainte est un objet et non une chaîne, car une utilisation de paramètre positionnelle peut contenir des utilisations d’extension de balisage imbriquées dans celle-ci. Pour accéder aux paramètres positionnels à partir de l’utilisation, vous pouvez effectuer une itération dans la liste et utiliser les indexeurs pour des valeurs de liste individuelles.

Pour une utilisation des paramètres nommés, chaque paramètre nommé est représenté en tant que nœud membre de ce nom dans le flux de nœuds. Les valeurs de membre ne sont pas nécessairement des chaînes, car il peut y avoir une utilisation de l’extension de balisage imbriquée.

ProvideValue de l’extension de balisage n’est pas encore appelée. Toutefois, elle est appelée si vous connectez un lecteur XAML et un enregistreur XAML afin que WriteEndObject soit appelé sur le nœud d’extension de balisage lorsque vous l’examinez dans le flux de nœuds. Pour cette raison, vous avez généralement besoin du même contexte de schéma XAML disponible que celui utilisé pour former le graphique d’objet sur le chemin de chargement. Sinon, ProvideValue à partir de n’importe quelle extension de balisage peut lever des exceptions ici, car il n’a pas de services attendus disponibles.

XAML et xml Language-Defined membres dans le flux de nœuds XAML

Certains membres sont introduits dans un flux de nœuds XAML en raison d’interprétations et de conventions d’un lecteur XAML, au lieu d’un XamlMember explicite de recherche ou de construction. Souvent, ces membres sont des directives XAML. Dans certains cas, il s’agit de lire le code XAML qui introduit la directive dans le flux de nœud XAML. En d’autres termes, le texte XAML d’entrée d’origine n’a pas explicitement spécifié la directive membre, mais le lecteur XAML insère la directive afin de satisfaire une convention XAML structurelle et des informations de rapport dans le flux de nœud XAML avant que ces informations ne soit perdues.

La liste suivante remarque tous les cas où un lecteur XAML est censé introduire un nœud de membre XAML de directive et comment ce nœud membre est identifié dans les implémentations des services XAML .NET.

• texte d’initialisation d’un nœud objet : Le nom de ce nœud membre est _Initialization, il représente une directive XAML et il est défini dans l’espace de noms XAML du langage XAML. Vous pouvez obtenir une entité statique pour celle-ci à partir de Initialization.

• paramètres positionnels pour une extension de balisage : Le nom de ce nœud membre est _PositionalParameterset il est défini dans l’espace de noms XAML du langage XAML. Il contient toujours une liste générique d’objets, chacun d’entre eux étant un paramètre positionnel pré-séparé par le fractionnement sur le caractère délimiteur , tel qu’il est fourni dans le code XAML d’entrée. Vous pouvez obtenir une entité statique pour la directive des paramètres positionnels à partir de PositionalParameters.

• Contenu inconnu : Le nom de ce nœud membre est _UnknownContent. Strictement parlant, il s’agit d’un XamlDirective, et il est défini dans l’espace de noms XAML du langage XAML. Cette directive est utilisée comme sentinelle pour les cas où un élément d’objet XAML contient du contenu dans le code XAML source, mais aucune propriété de contenu ne peut être déterminée sous le contexte de schéma XAML actuellement disponible. Vous pouvez détecter ce cas dans un flux de nœuds XAML en vérifiant les membres nommés _UnknownContent. Si aucune autre action n’est effectuée dans un flux de nœud XAML de chemin d’accès de charge, la XamlObjectWriter par défaut lève sur une tentative d'WriteEndObject lorsqu’elle rencontre le membre _UnknownContent sur n’importe quel objet. La XamlXmlWriter par défaut ne lève pas et traite le membre comme implicite. Vous pouvez obtenir une entité statique pour _UnknownContent à partir de UnknownContent.

• propriété Collection d’une collection : Bien que le type CLR de stockage d’une classe de collection utilisée pour XAML ait généralement une propriété nommée dédiée qui contient les éléments de collection, cette propriété n’est pas connue d’un système de type XAML avant la résolution de type de stockage. Au lieu de cela, le flux de nœud XAML introduit un espace réservé Items en tant que membre du type XAML de collection. Dans l’implémentation des services XAML .NET, le nom de cette directive ou de ce membre dans le flux de nœuds est _Items. Une constante pour cette directive peut être obtenue à partir de Items.

  Notez qu’un flux de nœud XAML peut contenir une propriété Items avec des éléments qui s’avèrent ne pas être analysés en fonction de la résolution de type de stockage et du contexte de schéma XAML. Par exemple

• membres définis par XML : les membres définis par XML xml:base, xml:lang et xml:space sont signalés en tant que directives XAML nommées base, langet space dans les implémentations des services XAML .NET. L’espace de noms pour ceux-ci est l’espace de noms XML http://www.w3.org/XML/1998/namespace. Les constantes de chacun de ces éléments peuvent être obtenues à partir de XamlLanguage.

Ordre des nœuds

Dans certains cas, XamlXmlReader modifie l’ordre des nœuds XAML dans le flux de nœuds XAML, par rapport à l’ordre dans lequel les nœuds apparaissent s’ils sont affichés dans le balisage ou s’ils sont traités en tant que XML. Cette opération est effectuée afin de classer les nœuds de sorte qu’un XamlObjectWriter puisse traiter le flux de nœud de manière vers l’avant uniquement. Dans les services XAML .NET, le lecteur XAML réorganise les nœuds au lieu de laisser cette tâche à l’enregistreur XAML, en tant qu’optimisation des performances pour les consommateurs d’enregistreurs d’objets XAML du flux de nœuds.

Certaines directives sont destinées spécifiquement à fournir plus d’informations pour la création d’un objet à partir d’un élément d’objet. Ces directives sont les suivantes : Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. Les lecteurs XAML des services XAML .NET tentent de placer ces directives en tant que premiers membres du flux de nœud en suivant les StartObjectd’un objet, pour des raisons expliquées dans la section suivante.

Comportement xamlObjectWriter et ordre des nœuds

StartObject à un XamlObjectWriter n’est pas nécessairement un signal à l’enregistreur d’objets XAML pour construire immédiatement l’instance d’objet. XAML inclut plusieurs fonctionnalités de langage qui permettent d’initialiser un objet avec une entrée supplémentaire et de ne pas s’appuyer entièrement sur l’appel d’un constructeur sans paramètre pour produire l’objet initial, puis définir uniquement les propriétés. Ces fonctionnalités incluent : XamlDeferLoadAttribute; texte d’initialisation ; x :TypeArguments; paramètres positionnels d’une extension de balisage ; méthodes de fabrique et x :Arguments nœuds (XAML 2009). Chacun de ces cas retarde la construction de l’objet réel et, étant donné que le flux de nœuds est réorganisé, l’enregistreur d’objets XAML peut s’appuyer sur un comportement de construction de l’instance chaque fois qu’un membre de démarrage est rencontré qui n’est pas spécifiquement une directive de construction pour ce type d’objet.

GetObject

GetObject représente un nœud XAML où au lieu de construire un nouvel objet, un enregistreur d’objets XAML doit obtenir plutôt la valeur de la propriété conteneur de l’objet. Un cas classique où un nœud GetObject est rencontré dans un flux de nœud XAML est destiné à un objet de collection ou à un objet dictionnaire, lorsque la propriété conteneur est délibérément en lecture seule dans le modèle objet du type de stockage. Dans ce scénario, la collection ou le dictionnaire est souvent créé et initialisé (généralement vide) par la logique d’initialisation d’un type propriétaire.

Voir aussi

• XamlObjectReader
• des services XAML
• espaces de noms XAML