Partager via

Espaces de noms XAML et mappage d’espaces de noms

  • Article

Cette rubrique explique les mappages d’espace de noms XML/XAML (xmlns) comme indiqué dans l’élément racine de la plupart des fichiers XAML. Il décrit également comment produire des mappages similaires pour les types et assemblys personnalisés.

Relation entre les espaces de noms XAML et les bibliothèques de types

À la fois dans son usage général et pour son application à la programmation d’applications Windows Runtime, XAML est utilisé pour déclarer des objets, des propriétés de ces objets et des relations de propriété d’objet exprimées sous forme de hiérarchies. Les objets que vous déclarez en XAML sont soutenus par des bibliothèques de types ou d’autres représentations définies par d’autres techniques et langages de programmation. Ces bibliothèques peuvent être les suivantes :

  • Ensemble intégré d’objets pour Windows Runtime. Il s’agit d’un ensemble fixe d’objets et l’accès à ces objets à partir de XAML utilise une logique interne de mappage de type et d’activation.
  • Bibliothèques distribuées fournies par Microsoft ou par des tiers.
  • Bibliothèques qui représentent la définition d’un contrôle tiers que votre application intègre et redistribue votre package.
  • Votre propre bibliothèque, qui fait partie de votre projet et qui contient certaines ou toutes vos définitions de code utilisateur.

Les informations de type de stockage sont associées à des définitions d’espace de noms XAML particulières. Les frameworks XAML tels que Windows Runtime peuvent agréger plusieurs assemblys et plusieurs espaces de noms de code à mapper à un espace de noms XAML unique. Cela permet le concept d’un vocabulaire XAML qui couvre une infrastructure de programmation ou une technologie plus volumineuse. Un vocabulaire XAML peut être très complet, par exemple, la plupart des applications XAML documentées pour Windows Runtime dans cette référence constituent un seul vocabulaire XAML. Un vocabulaire XAML est également extensible : vous l’étendez en ajoutant des types aux définitions de code de stockage, en veillant à inclure les types dans les espaces de noms de code déjà utilisés comme sources d’espace de noms mappées pour le vocabulaire XAML.

Un processeur XAML peut rechercher des types et des membres à partir des assemblys de stockage associés à cet espace de noms XAML lorsqu’il crée une représentation d’objet au moment de l’exécution. C’est pourquoi XAML est utile pour formaliser et échanger des définitions de comportement de construction d’objets, et pourquoi XAML est utilisé comme technique de définition d’interface utilisateur pour une application UWP.

Espaces de noms XAML dans l’utilisation classique du balisage XAML

Un fichier XAML déclare presque toujours un espace de noms XAML par défaut dans son élément racine. L’espace de noms XAML par défaut définit les éléments que vous pouvez déclarer sans les qualifier par un préfixe. Par exemple, si vous déclarez un élément <Balloon />, un analyseur XAML s’attend à ce qu’un élément Balloon existe et soit valide dans l’espace de noms XAML par défaut. En revanche, si Balloon n’est pas dans l’espace de noms XAML par défaut défini, vous devez au lieu de cela qualifier ce nom d’élément avec un préfixe, par exemple <party:Balloon />. Le préfixe indique que l’élément existe dans un espace de noms XAML différent de l’espace de noms par défaut et que vous devez mapper un espace de noms XAML à la partie de préfixe avant de pouvoir utiliser cet élément. Les espaces de noms XAML s’appliquent à l’élément spécifique sur lequel ils sont déclarés, ainsi qu’à tout élément contenu par cet élément dans la structure XAML. Pour cette raison, les espaces de noms XAML sont presque toujours déclarés sur les éléments racines d’un fichier XAML pour tirer parti de cet héritage.

Déclarations d’espace de noms XAML du langage XAML et par défaut

Dans l’élément racine de la plupart des fichiers XAML, il existe deux déclarations xmlns . La première déclaration mappe un espace de noms XAML comme valeur par défaut : xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Il s’agit du même identificateur d’espace de noms XAML utilisé dans plusieurs technologies Microsoft prédécesseurs qui utilisent également XAML comme format de balisage de définition d’interface utilisateur. L’utilisation du même identificateur est délibérée et est utile lorsque vous migrez l’interface utilisateur précédemment définie vers une application Windows Runtime à l’aide de C++, C# ou Visual Basic.

La deuxième déclaration mappe un espace de noms XAML distinct pour les éléments du langage XAML, le mappant (généralement) au préfixe « x : » : xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Cette valeur xmlns et le préfixe « x : » auquel il est mappé sont également identiques aux définitions utilisées dans plusieurs technologies Microsoft prédécesseurs qui utilisent XAML.

La relation entre ces déclarations est que XAML est une définition de langage et que Windows Runtime est une implémentation qui utilise XAML comme langage et définit un vocabulaire spécifique où ses types sont référencés en XAML.

Le langage XAML spécifie certains éléments de langage, et chacun d’eux doit être accessible via des implémentations de processeur XAML travaillant sur l’espace de noms XAML. La convention de mappage « x : » pour l’espace de noms XAML du langage XAML est suivie de modèles de projet, d’exemples de code et de la documentation relative aux fonctionnalités de langage. L’espace de noms du langage XAML définit plusieurs fonctionnalités couramment utilisées, même pour les applications Windows Runtime de base à l’aide de C++, C# ou Visual Basic. Par exemple, pour joindre un code-behind à un fichier XAML via une classe partielle, vous devez nommer cette classe comme attribut x :Class dans l’élément racine du fichier XAML approprié. Ou tout élément tel qu’il est défini dans une page XAML en tant que ressource clé dans des références de ressources ResourceDictionary et XAML doit avoir l’attribut x :Key défini sur l’élément objet en question.

Espaces de noms de code mappés à l’espace de noms XAML par défaut

Voici une liste d’espaces de noms de code actuellement mappés à l’espace de noms XAML par défaut.

  • Windows.UI
  • Windows.UI.Xaml
  • Windows.UI.Xaml.Automation
  • Windows.UI.Xaml.Automation.Peers
  • Windows.UI.Xaml.Automation.Provider
  • Windows.UI.Xaml.Automation.Text
  • Windows.UI.Xaml.Controls
  • Windows.UI.Xaml.Controls.Primitives
  • Windows.UI.Xaml.Data
  • Windows.UI.Xaml.Documents
  • Windows.UI.Xaml.Input
  • Windows.UI.Xaml.Interop
  • Windows.UI.Xaml.Markup
  • Windows.UI.Xaml.Media
  • Windows.UI.Xaml.Media.Animation
  • Windows.UI.Xaml.Media.Imaging
  • Windows.UI.Xaml.Media.Media3D
  • Windows.UI.Xaml.Navigation
  • Windows.UI.Xaml.Resources
  • Windows.UI.Xaml.Shapes
  • Windows.UI.Xaml.Threading
  • Windows.UI.Text

Autres espaces de noms XAML

Outre l’espace de noms par défaut et l’espace de noms XAML du langage XAML « x : », vous pouvez également voir d’autres espaces de noms XAML mappés dans le CODE XAML initial pour les applications générées par Microsoft Visual Studio.

d : (http://schemas.microsoft.com/expression/blend/2008)

L’espace de noms XAML « d : » est destiné à la prise en charge du concepteur, en particulier la prise en charge du concepteur dans les surfaces de conception XAML de Microsoft Visual Studio. L’espace de noms XAML « d : » permet aux attributs de concepteur ou au moment du design sur les éléments XAML. Ces attributs de concepteur affectent uniquement les aspects de conception de la façon dont XAML se comporte. Les attributs du concepteur sont ignorés lorsque le même code XAML est chargé par l’analyseur XAML Windows Runtime lors de l’exécution d’une application. En règle générale, les attributs du concepteur sont valides sur n’importe quel élément XAML, mais dans la pratique, il n’existe que certains scénarios où l’application d’un attribut de concepteur vous-même est appropriée. En particulier, de nombreux attributs du concepteur sont destinés à offrir une meilleure expérience d’interaction avec les contextes de données et les sources de données pendant que vous développez du code ET XAML qui utilisent la liaison de données.

  • d :DesignHeight et d :DesignWidth attributs : ces attributs sont parfois appliqués à la racine d’un fichier XAML que Visual Studio ou une autre surface de concepteur XAML crée pour vous. Par exemple, ces attributs sont définis sur la racine UserControl du code XAML créé si vous ajoutez un nouvel UserControl à votre projet d’application. Ces attributs facilitent la conception de la composition du contenu XAML, afin que vous ayez une certaine anticipation des contraintes de disposition qui peuvent exister une fois que le contenu XAML est utilisé pour une instance de contrôle ou une autre partie d’une page d’interface utilisateur plus grande.

Notez que si vous migrez XAML à partir de Microsoft Silverlight, vous pouvez avoir ces attributs sur les éléments racines qui représentent une page d’interface utilisateur entière. Vous pouvez supprimer les attributs dans ce cas. D’autres fonctionnalités des concepteurs XAML tels que le simulateur sont probablement plus utiles pour concevoir des mises en page qui gèrent la mise à l’échelle et les états d’affichage bien qu’une mise en page de taille fixe à l’aide de d :DesignHeight et d :DesignWidth.

  • d :DataContext attribute : vous pouvez définir cet attribut sur une racine de page ou un contrôle pour remplacer tout DataContext explicite ou hérité que l’objet a dans le cas contraire.
  • attribut d :DesignSource : spécifie une source de données au moment du design pour une CollectionViewSource, en remplaçant la source.
  • d :DesignInstance et d :DesignData markup extensions : ces extensions de balisage sont utilisées pour fournir les ressources de données au moment du design pour d :DataContext ou d :DesignSource. Nous n’allons pas documenter entièrement comment utiliser des ressources de données au moment du design ici. Pour plus d’informations, consultez Attributs au moment du design. Pour obtenir des exemples d’utilisation, consultez Exemples de données sur l’aire de conception et pour le prototypage.

mc : (http://schemas.openxmlformats.org/markup-compatibility/2006)

« mc : » indique et prend en charge un mode de compatibilité de balisage pour la lecture xaml. En règle générale, le préfixe « d : » est associé à l’attribut mc :Ignorable. Cette technique permet aux analyseurs XAML au moment de l’exécution d’ignorer les attributs de conception dans « d : ».

local : et commun :

« local : » est un préfixe qui est souvent mappé pour vous dans les pages XAML d’un projet d’application UWP modèle. Il est mappé pour faire référence à l’espace de noms créé pour contenir l’attribut et le code x :Class pour tous les fichiers XAML, y compris app.xaml. Tant que vous définissez les classes personnalisées que vous souhaitez utiliser en XAML dans ce même espace de noms, vous pouvez utiliser le préfixe local : pour faire référence à vos types personnalisés en XAML. Un préfixe associé provenant d’un projet d’application UWP modèle est courant :. Ce préfixe fait référence à un espace de noms « Commun » imbriqué qui contient des classes utilitaires telles que des convertisseurs et des commandes, et vous pouvez trouver les définitions dans le dossier Common dans la vue Explorateur de solutions.

vsm :

Ne pas utiliser. « vsm : » est un préfixe qui est parfois vu dans les anciens modèles XAML importés à partir d’autres technologies Microsoft. L’espace de noms a initialement résolu un problème d’outils d’espace de noms hérité. Vous devez supprimer les définitions d’espace de noms XAML pour « vsm : » dans n’importe quel code XAML que vous utilisez pour Windows Runtime, et modifier les utilisations de préfixe pour VisualState, VisualStateGroup et les objets associés afin d’utiliser l’espace de noms XAML par défaut à la place. Pour plus d’informations sur la migration XAML, consultez Migration de Silverlight ou WPF XAML/code vers une application Windows Runtime.

Mappage de types personnalisés aux espaces de noms et préfixes XAML

Vous pouvez mapper un espace de noms XAML afin de pouvoir utiliser XAML pour accéder à vos propres types personnalisés. En d’autres termes, vous mappez un espace de noms de code tel qu’il existe dans une représentation de code qui définit le type personnalisé et en l’affectant à un espace de noms XAML avec un préfixe pour l’utilisation. Les types personnalisés pour XAML peuvent être définis dans un langage Microsoft .NET (C# ou Microsoft Visual Basic) ou en C++. Le mappage est effectué en définissant un préfixe xmlns . Par exemple, xmlns:myTypes définit un nouvel espace de noms XAML accessible en préfixant toutes les utilisations avec le jeton myTypes:.

Une définition xmlns inclut une valeur ainsi que le nommage de préfixe. La valeur est une chaîne qui se trouve entre guillemets, à la suite d’un signe égal. Une convention XML commune consiste à associer l’espace de noms XML à un URI (Uniform Resource Identifier), afin qu’il existe une convention pour l’unicité et l’identification. Vous voyez également cette convention pour l’espace de noms XAML par défaut et l’espace de noms XAML du langage XAML, ainsi que pour certains espaces de noms XAML moins utilisés utilisés par le xaml Windows Runtime. Mais pour un espace de noms XAML qui mappe des types personnalisés, au lieu de spécifier un URI, vous commencez la définition de préfixe avec le jeton « using : ». Après le jeton « using : », vous nommez ensuite l’espace de noms de code.

Par exemple, pour mapper un préfixe « custom1 » qui vous permet de référencer un espace de noms « CustomClasses » et d’utiliser des classes de cet espace de noms ou de cet assembly en tant qu’éléments d’objet en XAML, votre page XAML doit inclure le mappage suivant sur l’élément racine : xmlns:custom1="using:CustomClasses"

Les classes partielles de la même étendue de page n’ont pas besoin d’être mappées. Par exemple, vous n’avez pas besoin de préfixes pour référencer les gestionnaires d’événements que vous avez définis pour gérer les événements à partir de la définition de l’interface utilisateur XAML de votre page. En outre, la plupart des pages XAML de démarrage de Visual Studio générés pour une application Windows Runtime à l’aide de C++, C# ou Visual Basic mappent déjà un préfixe « local : », qui fait référence à l’espace de noms par défaut spécifié par le projet et à l’espace de noms utilisé par les définitions de classes partielles.

Règle du langage CLR

Si vous écrivez votre code de stockage dans un langage .NET (C# ou Microsoft Visual Basic), vous utilisez peut-être des conventions qui utilisent un point (« . ») dans le cadre des noms d’espaces de noms pour créer une hiérarchie conceptuelle d’espaces de noms de code. Si votre définition d’espace de noms contient un point, le point doit faire partie de la valeur que vous spécifiez après le jeton « using : ».

Si votre fichier code-behind ou fichier de définition de code est un fichier C++, il existe certaines conventions qui suivent toujours le formulaire de langage CLR (Common Language Runtime), afin qu’il n’y ait aucune différence dans la syntaxe XAML. Si vous déclarez des espaces de noms imbriqués en C++, le séparateur entre les chaînes d’espace de noms imbriquées successives doit être « ». Au lieu de « : » lorsque vous spécifiez la valeur qui suit le jeton « using : ».

N’utilisez pas de types imbriqués (par exemple, imbriquer une énumération au sein d’une classe) lorsque vous définissez votre code à utiliser avec XAML. Les types imbriqués ne peuvent pas être évalués. Il n’existe aucun moyen pour l’analyseur XAML de distinguer qu’un point fait partie du nom de type imbriqué plutôt qu’une partie du nom de l’espace de noms.

Types et assemblys personnalisés

Le nom de l’assembly qui définit les types de stockage d’un espace de noms XAML n’est pas spécifié dans le mappage. La logique pour laquelle les assemblys sont disponibles est contrôlée au niveau de la définition de l’application et fait partie des principes de sécurité et de déploiement d’applications de base. Déclarez tout assembly que vous souhaitez inclure en tant que source de définition de code pour XAML en tant qu’assembly dépendant dans les paramètres du projet. Pour plus d’informations, consultez Création de composants Windows Runtime en C# et Visual Basic.

Si vous référencez des types personnalisés à partir de la définition d’application ou des définitions de page de l’application principale, ces types sont disponibles sans configuration d’assembly dépendante supplémentaire, mais vous devez toujours mapper l’espace de noms de code qui contient ces types. Une convention commune consiste à mapper le préfixe « local » pour l’espace de noms de code par défaut d’une page XAML donnée. Cette convention est souvent incluse dans le démarrage de modèles de projet pour les projets XAML.

Propriétés jointes

Si vous référencez des propriétés jointes, la partie de type propriétaire du nom de la propriété jointe doit être dans l’espace de noms XAML par défaut ou être préfixée. Il est rare de préfixer des attributs séparément de leurs éléments, mais il s’agit d’un cas où il est parfois nécessaire, en particulier pour une propriété jointe personnalisée. Pour plus d’informations, consultez Propriétés jointes personnalisées.