Partager via

Fonctionnement des concepts et structures du flux de nœud XAML

  • Article

Les lecteurs et writers XAML implémentés au sein des services XAML du .NET Framework sont basés sur le concept d'un flux de nœud XAML. Le flux de nœud XAML est une conceptualisation d'un ensemble de nœuds XAML. Dans cette conceptualisation, un processeur XAML traverse la structure des relations de nœuds dans le code XAML un par un. À tout moment, il n'existe qu'un enregistrement actif ou une position active dans un flux de nœud XAML ouvert et de nombreux aspects de l'API stockent uniquement les informations disponibles à cette position. Le nœud actif d'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œud XAML, les lecteurs XAML peuvent communiquer avec les writers XAML et activer un programme pour afficher, modifier ou interagir avec le contenu d'un flux de nœud XAML pendant une opération de chemin de chargement ou de chemin d'enregistrement qui implique XAML. La conception de l'API du lecteur et du writer XAML, et le concept de flux de nœud XAML sont similaires aux précédents concepts et conceptions de lecteur/writer associé, tels que XML Document Object Model (DOM) et XmlReader / XmlWriter. Cette rubrique traite des concepts de flux de nœud XAML et décrit comment vous pouvez écrire des routines qui interagissent avec des représentations XAML au niveau du nœud XAML.

Cette rubrique comprend les sections suivantes.

  • Chargement de XAML dans un lecteur XAML
  • Boucle de nœud de lecture de base
  • Utilisation du nœud actif
  • Parcours des nœuds d'objet et accès à ces derniers
  • Convertisseurs de valeurs et flux de nœud XAML
  • Membres définis par les langages XAML et XML dans le flux de nœud XAML
  • Ordre des nœuds
  • Rubriques connexes

Chargement de XAML dans un lecteur XAML

La classe XamlReader de base ne déclare pas de technique particulière pour le chargement du 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 fonctionnalités et contraintes générales de sa source d'entrée pour XAML. Exemple : un XamlObjectReader lit un graphique d'objets en partant de la source d'entrée d'un objet unique qui représente la racine ou la base. Le XamlObjectReader génère ensuite un flux de nœud XAML à partir du graphique d'objets.

La principale sous-classe XamlReader définie par les services XAML .NET Framework est XamlXmlReader. XamlXmlReader charge le XAML initial en chargeant un fichier texte directement par le biais d'un flux ou d'un chemin d'accès au fichier, ou indirectement par l'intermédiaire d'une classe de lecteur associée telle que TextReader. Le XamlReader peut être considéré comme contenant l'intégralité de la source d'entrée XAML une fois le chargement terminé. Toutefois, l'API de base XamlReader est conçue afin que le lecteur interagisse avec un nœud unique du XAML. Lors du premier chargement, le premier nœud unique que vous rencontrez est la racine du XAML et son objet de début.

Le concept de flux de nœud XAML

Si vous avez plus l'habitude d'une approche DOM, avec métaphore de l'arborescence ou à base de requêtes en ce qui concerne l'accès aux technologies XML, vous trouverez ci-dessous une méthode de conceptualisation d'un flux de nœud XAML pratique. Imaginez que le XAML chargé soit un élément DOM ou une arborescence où tous les nœuds sont développés intégralement, puis présentés de façon linéaire. À mesure que vous avancez dans les nœuds, vous « entrez » ou « sortez » de niveaux qui seraient pertinents pour un élément DOM, mais le flux de nœud XAML n'en conserve pas explicitement la trace étant donné que ces concepts de niveaux ne sont pas pertinents dans un flux de nœud. Le flux de nœud a une position « active », mais, à moins que vous n'ayez enregistré d'autres parties du flux de données vous-même en tant que références, seule la position active du nœud est affichée, les autres aspects sont invisibles.

Le concept de flux de nœud XAML présente un avantage essentiel : si vous traversez le flux de nœud entier, vous savez que vous avez traité l'intégralité de la représentation XAML ; vous n'avez pas besoin de vous préoccuper de requêtes, d'opérations DOM ou d'autres approches non linéaires du traitement d'informations qui auraient pu rater une partie de la représentation XAML complète. C'est pour cette raison que la représentation de flux de nœud XAML est idéale pour relier des lecteurs et writers XAML entre eux ; vous bénéficiez d'un système vous permettant d'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, le classement des nœuds dans le flux de nœud XAML est délibérément optimisé ou remanié par les lecteurs XAML en fonction de la façon dont l'ordre peut apparaître dans le texte source, le binaire ou le graphique d'objet. Ce comportement a pour but la mise en place d'une architecture de traitement XAML au sein de laquelle les writers XAML ne sont jamais en position de devoir « retourner » dans le flux de nœud. Dans l'idéal, toutes les opérations d'écriture XAML doivent pouvoir agir sur la base d'un contexte de schéma auquel s'ajoute la position active du flux de nœud.

Boucle de nœud de lecture de base

Une boucle de nœud de lecture de base pour l'examen d'un flux de nœud XAML se compose des concepts suivants. Pour les besoins des boucles de nœud comme décrit dans cette rubrique, partez du principe que vous lisez un fichier XAML texte explicite à 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.

  • Vérifiez que vous ne vous trouvez pas au bout du flux de nœud XAML (vérifiez IsEof ou utilisez la valeur de retour Read()). Si c'est le cas, aucun nœud actif n'existe et vous devez quitter.

  • Déterminez le type de nœud que le flux de nœud XAML expose actuellement en appelant NodeType.

  • Si vous disposez d'un writer d'objet XAML déjà connecté, vous appelez généralement WriteNode à ce stade.

  • En fonction du XamlNodeType signalé comme étant le nœud ou l'enregistrement actif, appelez l'un des éléments suivants pour obtenir des informations concernant le contenu du nœud :

    • Pour un NodeType de StartMember ou EndMember, appelez Member pour obtenir des informations XamlMember sur un membre. Remarque : le membre peut être une directive XamlDirective et n'est donc pas nécessairement un membre défini classique de l'objet précédent. Exemple : x:Name appliqué à un objet apparaît sous la forme d'un membre XAML où IsDirective a la valeur true et le Name du membre est Name, les autres propriétés indiquant que cette directive se trouve dans l'espace de noms XAML du langage XAML.

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

    • Pour un 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 (vous devez toutefois connaître le comportement de conversion de type détaillé dans une autre section de cette rubrique).

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

  • Appelez Read pour avancer le lecteur XAML jusqu'au nœud suivant du flux de nœud XAML et répétez les étapes une nouvelle fois.

Le flux de nœud XAML fourni par les lecteurs XAML des services XAML .NET Framework fournit systématiquement un parcours complet de tous les nœuds possibles. Les techniques de contrôle de flux courantes pour une boucle de nœud XAML incluent la définition d'un corps dans while (reader.Read()) et l'activation de NodeType à chaque point de nœud de la boucle de nœud.

Si le flux de nœud se trouve à la fin du fichier, le nœud actif est null.

La boucle la plus simple utilisant un lecteur et un writer 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 façon transparente le lecteur et le writer XAML exactement comme si vous aviez utilisé XamlServices.Parse. Toutefois, cette structure de base est développée ensuite pour s'appliquer à votre scénario de lecture ou d'écriture. Voici quelques scénarios possibles :

  • Activez NodeType. Exécutez différentes actions en fonction du type de nœud qui est lu.

  • Dans tous les cas, n'appelez pas WriteNode. Appelez uniquement WriteNode pour certaines propriétés NodeType.

  • Conformément à la logique d'un type de nœud particulier, analysez les caractéristiques de ce nœud et agissez sur celles-ci. Par exemple, vous pouvez écrire uniquement les objets issus d'un espace de noms XAML particulier, puis supprimer ou différer tous les objets ne provenant pas de cet espace de noms XAML. Vous pouvez aussi supprimer ou retraiter d'une autre manière toutes les directives XAML que votre système XAML ne prend pas en charge dans le cadre du traitement des membres.

  • Définissez un XamlObjectWriter personnalisé qui substitue les méthodes Write* en effectuant éventuellement un mappage de type qui ignore le contexte de schéma XAML.

  • Construisez l'élément XamlXmlReader de façon à utiliser un contexte de schéma XAML autre que celui par défaut ; ainsi, les différences personnalisées dans le comportement XAML sont utilisées à la fois par le lecteur et le writer.

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

Il existe potentiellement d'autres manières d'utiliser une représentation XAML que celle d'une boucle de nœud XAML. Par exemple, il peut exister un lecteur XAML qui peut lire un nœud indexé ou, en particulier, qui accède aux nœuds directement par x:Name, x:Uid ou encore par le biais d'autres identificateurs. Les services XAML .NET Framework ne fournissent pas d'implémentation complète, mais offrent un modèle suggéré via des services et des types de prises en charge. Pour plus d'informations, consultez IXamlIndexingReader et XamlNodeList.

ConseilConseil

Microsoft produit également une version finale hors plage connue sous le nom d'ensemble d'outils Microsoft XAML.Cette version finale hors plage n'a pas encore été commercialisée.Toutefois, si vous êtes disposé à travailler avec des composants précommerciaux, l'ensemble d'outils Microsoft XAML fournit des ressources intéressantes pour l'outillage XAML et l'analyse statique du code XAML.L'ensemble d'outils Microsoft XAML comprend une API DOM XAML, la prise en charge de l'analyse FxCop et un contexte de schéma XAML pour Silverlight.Pour plus d'informations, consultez Microsoft XAML Toolkit.

Utilisation du nœud actif

La plupart des scénarios utilisant une boucle de nœud XAML ne se contentent pas de lire les nœuds. La plupart de ces scénarios traitent les nœuds actifs et transfèrent les nœuds un par un vers une implémentation de XamlWriter.

Pour le scénario courant de chemin de chargement, XamlXmlReader génère un flux de nœud XAML et les nœuds XAML peuvent être traités par votre logique et le contexte de schéma XAML ; les nœuds sont alors passés à XamlObjectWriter. Ensuite, intégrez le graphique d'objets obtenu dans votre application ou votre infrastructure.

Pour le scénario de chemin d'enregistrement courant, XamlObjectReader lit le graphique d'objets, chaque nœud XAML est traité et XamlXmlWriter exporte le résultat sérialisé en tant que fichier texte XAML. Le point crucial est ici que les deux chemins/scénarios impliquent l'utilisation d'un nœud XAML à la fois et que les nœuds XAML sont disponibles pour le traitement, selon une méthode standardisée définie par le système de type XAML et l'API générale des services XAML .NET Framework.

Frames et portée

Une boucle de nœud XAML traverse un flux de nœud XAML de façon linéaire. Le flux de nœud traverse des objets, des membres qui contiennent d'autres objets, etc. Il est souvent utile d'assurer le suivi de la portée dans le flux de nœud XAML en implémentant un concept de frame/pile. C'est particulièrement vrai si vous ajustez activement le flux de nœud lorsque vous vous y trouvez. La prise en charge du frame/de la pile que vous implémentez dans le cadre de votre logique de boucle de nœud dénombre des portées StartObject (ou GetObject) et EndObject à mesure que vous descendez dans une structure de nœud XAML, si la structure est considérée comme provenant d'un point de vue DOM.

Parcours des nœuds d'objet et accès à ces derniers

Le premier nœud d'un flux de nœud, lorsqu'il est ouvert par un lecteur XAML, est le nœud d'objet de début de l'objet racine. Par définition, cet objet est toujours un nœud d'objet unique et n'a pas d'homologues. Dans tout exemple de code XAML réel, l'objet racine sera défini de manière à disposer d'une ou de plusieurs propriétés qui contiennent d'autres objets et ces propriétés auront des nœuds membres. Les nœuds membres comportent eux-mêmes un ou plusieurs nœuds d'objet, ou peuvent également se terminer par un nœud de valeur. L'objet racine définit en général les portées de nom XAML, qui sont syntaxiquement assignées en tant qu'attributs dans les balises de texte XAML, mais sont mappés vers un type de nœud Namescope dans la représentation du flux de nœud XAML.

Examinez l'exemple de code XAML suivant (il s'agit de code XAML arbitraire, non stocké par les types qui existent dans le .NET Framework). Supposons que, dans ce modèle objet, FavorCollection corresponde au List<T> de Favor, Balloon et NoiseMaker puissent être assignés à Favor, la propriété Balloon.Color soit stockée par un objet Color qui définit les couleurs en tant que noms de couleurs connus et Color prenne en charge un convertisseur de type pour la syntaxe des attributs.

marques XAML

Flux de nœud XAML résultant

<Party

Nœud Namespace correspondant à Party.

xmlns="PartyXamlNamespace">

Nœud StartObject correspondant à Party.

  <Party.Favors>

Nœud StartMember correspondant à Party.Favors.

Nœud StartObject correspondant à la propriété FavorCollection implicite

Nœud StartMember correspondant à la propriété d'élément FavorCollection implicite.

    <Balloon

Nœud StartObject correspondant à Balloon.

      Color="Red"

Nœud StartMember correspondant à Color.

  Nœud Value correspondant à la chaîne de valeur d'attribut "Red"

EndMember correspondant à Color

      HasHelium="True"

Nœud StartMember correspondant à HasHelium.

  Nœud Value correspondant à la chaîne de valeur d'attribut "True"

EndMember correspondant à HasHelium

    >

EndObject correspondant à Balloon

    <NoiseMaker>Loudest</NoiseMaker>

Nœud StartObject correspondant à NoiseMaker.

Nœud   StartMember correspondant à _Initialization.

    Nœud Value correspondant à la chaîne de valeur d'initialisation "Loudest"

Nœud   EndMember correspondant à _Initialization.

EndObject correspondant à NoiseMaker

Nœud EndMember correspondant à la propriété d'élément FavorCollection implicite.

Nœud EndObject correspondant à la propriété FavorCollection implicite

  </Party.Favors>

EndMember correspondant à Favors

</Party>

EndObject correspondant à Party

Dans le flux de nœud XAML, vous observerez le comportement suivant :

  • Si un nœud Namespace existe, il est ajouté au flux de données juste avant l'élément StartObject ayant déclaré l'espace de noms XAML avec xmlns. Réexaminez le tableau précédent comportant le code XAML et l'exemple de flux de nœud. Notez que les nœuds StartObject et Namespace semblent être transposés par rapport à leur position de déclaration dans les marques de texte. Ce mécanisme est représentatif du comportement par lequel les nœuds d'espace de noms apparaissent toujours avant le nœud auquel ils s'appliquent dans le flux de nœud. Cette conception repose sur le fait que les informations d'espace de noms sont essentielles pour les writers d'objets et doivent être connues avant toute tentative de mappage de type ou de traitement de l'objet. En plaçant les informations d'espaces de noms XAML avant la portée d'application correspondante dans le flux de données, il est plus facile de toujours traiter le flux de nœud dans l'ordre présenté.

  • Il résulte de la considération ci-dessus que vous lisez en premier un ou plusieurs nœuds Namespace, et non pas le StartObject de la racine, dans la plupart des cas de balisage réels lorsque vous parcourez des nœuds à partir du début.

  • Un nœud StartObject peut être suivi par un StartMember, un nœud Value ou un EndObject immédiat. Il n'est jamais suivi immédiatement par un autre StartObject.

  • Un nœud StartMember peut être suivi par un StartObject, un nœud Value ou un EndMember immédiat. Il peut être suivi par un élément GetObject, pour les membres dont la valeur est censée provenir d'une valeur existante de l'objet parent plutôt que d'un élément StartObject qui instancierait une nouvelle valeur. Il peut également être suivi par un nœud Namespace, qui s'applique à un élément 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'existe aucun "EndValue". Il peut être suivi uniquement par un EndMember.

    • Le texte d'initialisation XAML de l'objet, tel qu'une construction peut en utiliser, ne génère pas de structure Objet-Valeur. À la place, un nœud membre dédié est créé pour un membre nommé _Initialization. Ce nœud membre contient la chaîne de valeur d'initialisation. S'il existe, le membre _Initialization est toujours le premier StartMember. _Initialization peut être qualifié dans certaines représentations des services XAML avec la portée de nom XAML du langage XAML de façon à clarifier le fait que _Initialization n'est pas une propriété définie dans les types de stockage.

    • Une combinaison Membre-Valeur représente un paramètre d'attribut de la valeur. Un convertisseur de valeurs pourra éventuellement être impliqué dans le traitement de cette valeur ; celle-ci est une chaîne simple. Toutefois, cette condition n'est pas évaluée tant qu'un writer d'objet XAML ne traite pas ce flux de nœud. Le writer d'objet XAML possède le contexte de schéma XAML et le mappage de système de type requis, ainsi que les autres prises en charge nécessaires pour les conversions de valeurs.

  • Un nœud EndMember peut être suivi par un nœud StartMember d'un membre suivant ou par un nœud EndObject du propriétaire du membre.

  • Un nœud EndObject peut être suivi par un nœud EndMember. Il peut également être suivi par un nœud StartObject dans le cas où les objets sont des homologues dans les éléments d'une collection. Elle peut également être suivie par un nœud Namespace, qui s'applique à un élément StartObject à venir.

    • Dans le cas unique de la fermeture du flux de nœud entier, le nœud EndObject de la racine n'est suivi par aucun élément ; le lecteur atteint la fin du fichier et Read retourne la valeur false.

Convertisseurs de valeurs et flux de nœud XAML

Un convertisseur de valeurs est un terme général désignant une extension de balisage, un convertisseur de type (y compris les sérialiseurs de valeurs) ou une autre classe dédiée qui est signalée comme un convertisseur de valeurs via le système de type XAML. Dans le flux de nœud XAML, l'utilisation d'un convertisseur de type et l'utilisation d'une extension de balisage sont représentées de façon très différente.

Convertisseurs de types dans le flux de nœud XAML

Un ensemble d'attributs qui entraîne l'utilisation d'une convertisseur de type est signalé dans le flux de nœud XAML en tant que valeur d'un membre. Le flux de nœud XAML ne tente pas de produire un objet d'instance de convertisseur de type et de lui passer la valeur. L'utilisation d'une implémentation de convertisseur de type requiert l'appel du contexte de schéma XAML en vue d'un mappage de type. Même l'identification de la classe de convertisseur de type qui doit être utilisée pour traiter la valeur requiert indirectement le contexte de schéma XAML. Lors de l'utilisation du contexte de schéma XAML par défaut, cette information est disponible dans le 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 writer XAML, vous pouvez les obtenir à partir des informations XamlMember du membre qui est défini. Sinon, l'entrée de convertisseur de type doit être conservée dans le flux de nœud XAML en tant que valeur ordinaire jusqu'à la fin des opérations nécessitant le système de mappage de type et le contexte de schéma XAML (création d'objet par un writer d'objet XAML, par exemple).

Par exemple, considérez la structure de définition de classe suivante et l'utilisation XAML correspondante :

    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 la chaîne de texte "8x8"

EndMember correspond à BoardSize.

EndObject correspond à GameBoard.

Remarquez que ce flux de nœud ne comporte aucune instance de convertisseur de type. Vous pouvez toutefois obtenir les informations de convertisseur de type en appelant XamlMember.TypeConverter sur le XamlMember de BoardSize. Dans la mesure où votre contexte de schéma XAML est valide, vous pouvez également appeler les méthodes du convertisseur en obtenant une instance à partir de ConverterInstance.

Extensions de balisage dans le flux de nœud XAML

L'utilisation d'une extension de balisage est signalée dans le flux de nœud XAML comme un nœud d'objet d'un membre, où l'objet représente une instance d'extension de balisage. Une utilisation d'extension de marques est donc présentée de façon plus explicite dans la représentation du flux de nœud qu'une utilisation de convertisseur de type, et elle véhicule davantage d'informations. Les informations XamlMember n'ont pas pu vous renseigner sur l'extension de balisage car l'utilisation est situationnelle et varie selon chaque cas de balisage possible ; elles ne sont pas dédiées ni implicites pour chaque type ou membre comme dans le cas des convertisseurs de types.

Les extensions de balisage sont représentées dans le flux de nœud sous forme de nœuds d'objet même si elles ont été utilisées sous forme d'attributs dans les marques de texte XAML (ce qui est souvent le cas). Les utilisations des extensions de balisage faisant appel à une forme d'élément objet explicite sont traitées de la même façon.

Le nœud d'objet de l'extension de balisage peut comporter des membres de cette extension. La représentation du flux de nœud XAML préserve l'utilisation de cette extension de balisage, qu'il s'agisse d'une utilisation de paramètre positionnel ou d'une utilisation avec des paramètres nommés explicites.

Pour une utilisation de paramètre positionnel, le flux de nœud XAML contient une propriété _PositionalParameters définie par le langage XAML qui enregistre cette utilisation. Cette propriété est un List<T> générique, doté d'une contrainte Object. La contrainte est un objet, et non pas une chaîne, car une utilisation de paramètre positionnel peut en théorie inclure des utilisations d'extension de balisage qui y sont imbriquées. Pour accéder aux paramètres positionnels à partir de l'utilisation, vous pouvez effectuer une itération au sein de la liste et utiliser les indexeurs pour les valeurs de liste individuelles.

Pour une utilisation de paramètre nommé, chaque paramètre nommé est représenté comme un nœud membre portant ce nom dans le flux de nœud. Les valeurs de membres ne sont pas nécessairement des chaînes car une utilisation d'extension de balisage peut être imbriquée.

La méthode ProvideValue de l'extension de balisage n'est pas encore appelée. Toutefois, elle sera appelée si vous connectez un lecteur et un writer XAML de façon à ce que WriteEndObject soit appelé sur le nœud de l'extension de balisage dès que vous l'examinez dans le flux de nœud. Par conséquent, vous avez généralement besoin du contexte de schéma XAML que vous utiliseriez pour former le graphique d'objet dans le chemin de chargement. Sinon, la méthode ProvideValue de toute extension de balisage peut lever des exceptions à ce stade car elle ne dispose pas des services attendus.

Membres définis par les langages XAML et XML dans le flux de nœud XAML

Certains membres sont introduits dans un flux de nœud XAML en raison d'interprétations et de conventions propres à un lecteur XAML, plutôt que par le biais d'une construction ou d'une recherche de XamlMember explicite. Souvent, ces membres sont des directives XAML. Dans certains cas, c'est l'acte de lire le code XAML qui présente la directive dans le flux de nœud XAML. En d'autres termes, le texte XAML d'entrée d'origine n'a pas spécifié la directive membre de façon explicite, mais le lecteur XAML insère la directive de façon à répondre à un critère de convention XAML structurelle et à signaler les informations dans le flux de nœud XAML avant que celles-ci soient perdues.

La liste suivante répertorie tous les cas où un lecteur XAML doit présenter un nœud membre de directive XAML, et la façon dont ce nœud membre est identifié dans les implémentations des services XAML .NET Framework.

  • Texte d'initialisation pour un nœud d'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 pour ce nœud une entité statique à partir de Initialization.

  • Paramètres positionnels d'une extension de balisage : le nom de ce nœud membre est _PositionalParameters et il est défini dans l'espace de noms XAML du langage XAML. Elle contient toujours une liste d'objets générique ; chacun de ces objets est un paramètre positionnel pré-séparé via un fractionnement sur le caractère délimiteur ,, comme indiqué dans le XAML d'entrée. Vous pouvez obtenir une entité statique pour les paramètres positionnels de PositionalParameters.

  • Contenu inconnu : le nom de ce nœud membre est _UnknownContent. Il s'agit à proprement parler d'une directive XamlDirective qui est définie dans l'espace de noms XAML du langage XAML. Cette directive est utilisée comme sentinelle dans le cas où un élément objet XAML inclut du contenu du code XAML source, mais où aucune propriété de contenu ne peut être déterminée dans le contexte de schéma XAML disponible. Vous pouvez détecter ce cas dans un flux de nœud XAML en recherchant les membres nommés _UnknownContent. Si aucune autre action n'est effectuée dans un flux de nœud XAML de chemin de chargement, le XamlObjectWriter par défaut lèvera une exception lors de la tentative d'exécution de WriteEndObject dès qu'il rencontre le membre _UnknownContent sur un objet. Le XamlXmlWriter par défaut ne lève pas d'exception et traite le membre comme étant implicite. Vous pouvez obtenir une entité statique pour _UnknownContent à partir de UnknownContent.

  • Propriété de collection d'une collection : Bien que le type de stockage CLR d'une classe de collection utilisée pour XAML possède généralement une propriété nommée dédiée qui conserve les éléments de collection, cette propriété n'est pas connue par un système de type XAML avant la résolution de type de stockage. Au lieu de cela, le flux de nœud XAML présente un espace réservé Items en tant que membre du type XAML de collection. Dans l'implémentation des services XAML .NET Framework, le nom de cette directive ou de ce membre dans le flux de nœud est _Items. Vous pouvez obtenir une constante pour cette directive de Items

    Remarque : un flux de nœud XAML peut contenir une propriété d'éléments comportant des éléments qui s'avèrent non analysables selon la résolution de type de stockage et le contexte de schéma XAML. Par exemple :

  • **Membres XML :**Les membres XML xml:base etxml:langxml:space sont signalés comme directives XAML nomméesbase,lang et space dans les implémentations des services XAML .NET Framework. L'espace de noms de ces membres est l'espace de noms XML http://www.w3.org/XML/1998/namespace. Les constantes de chacun de ces membres 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œud XAML, par rapport à l'ordre d'apparition des nœuds lorsqu'ils sont visualisés sur les marques ou traités en tant que XML. Ceci a pour but de classer les nœuds de façon à ce qu'un élément XamlObjectWriter puisse traiter le flux de nœud vers l'avant uniquement. Dans les services XAML .NET Framework, le lecteur XAML se charge de l'organisation des nœuds à la place du writer XAML, dans le cadre d'une optimisation des performances pour les consommateurs du writer d'objet XAML du flux de nœud.

Certaines directives sont conçues spécifiquement pour fournir davantage d'informations pour la création d'un objet à partir d'un élément objet. Ces directives sont les suivantes : Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. Les lecteurs XAML DES SERVICES XAML .NET Framework tentent de définir ces directives en tant que premiers membres dans le flux de nœud suivant l'élément StartObject d'un objet, pour des raisons qui sont expliquées dans la section suivante.

Comportement de XamlObjectWriter et ordre des nœuds

Un élément StartObject sur un XamlObjectWriter ne constitue pas nécessairement un signal au writer d'objet XAML pour que celui-ci construise immédiatement l'instance d'objet. Le langage XAML comprend plusieurs fonctionnalités de langages qui permettent d'initialiser un objet avec une entrée supplémentaire ; il n'est donc plus nécessaire d'appeler un constructeur par défaut pour générer l'objet initial avant de définir les propriétés. Ces fonctionnalités comprennent : XamlDeferLoadAttribute ; texte d'initialisation ; x:TypeArguments ; paramètres positionnels d'une extension de marques ; méthodes de fabrique et nœuds x:Arguments associés (XAML 2009). Chacun de ces cas retarde la construction d'objet réelle ; en outre, étant donné que le flux de nœud est réorganisé, le writer d'objet XAML peut compter sur un comportement de construction réelle de l'instance chaque fois qu'il rencontre un membre de début qui n'est pas spécifiquement une directive de construction pour ce type d'objet.

GetObject

GetObject représente un nœud XAML dans lequel, au lieu de construire un nouvel objet, un writer d'objet XAML doit obtenir la valeur de la propriété contenant l'objet. L'on trouve fréquemment des nœuds GetObject dans un flux de nœud XAML pour 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éé(e) et initialisé(e) par la logique d'initialisation d'un type propriétaire ; la collection ou le dictionnaire est généralement vide.

Voir aussi

Référence

XamlObjectReader

Concepts

Services XAML

Autres ressources

Espaces de noms XAML pour les services XAML .NET Framework