Partager via

Contexte de schéma XAML par défaut et contexte de schéma XAML WPF

  • Article

Un contexte de schéma XAML est une entité conceptuelle qui qualifie la façon dont une production XAML qui utilise un vocabulaire XAML particulier interagit avec le comportement d’écriture d’objet, notamment la résolution du mappage de type, le chargement des assemblys, la façon dont certains paramètres de lecteur et d’enregistreur sont interprétés. Cette rubrique décrit les fonctionnalités des services XAML .NET et le contexte de schéma XAML par défaut associé, qui est basé sur le système de type CLR. Cette rubrique décrit également le contexte de schéma XAML utilisé pour WPF.

Contexte de schéma XAML par défaut

Les services XAML .NET implémentent et utilisent un contexte de schéma XAML par défaut. Le comportement du contexte de schéma XAML par défaut n’est pas toujours entièrement visible dans l’API de la classe XamlSchemaContext. Toutefois, dans de nombreux cas, le comportement que le contexte de schéma XAML par défaut influence est observable par le biais de l’API commune du système de type XAML, comme les membres de XamlMember ou de XamlType, ou via des API exposées sur les lecteurs XAML et les enregistreurs XAML qui utilisent le contexte de schéma XAML par défaut.

Vous pouvez créer un XamlSchemaContext qui encapsule le comportement par défaut en appelant le constructeur XamlSchemaContext. Cela crée explicitement le contexte de schéma XAML par défaut. Le même contexte de schéma XAML par défaut est créé implicitement, si vous initialisez un lecteur XAML ou un enregistreur XAML à l’aide d’API qui ne prennent pas explicitement un paramètre d’entrée XamlSchemaContext.

Le contexte de schéma XAML par défaut s’appuie sur la réflexion CLR pour son comportement de mappage de type. Cela inclut l’examen de la définition du TypeCLR et des PropertyInfo ou MethodInfoconnexes. En outre, l’attribution CLR sur les types ou les membres est utilisée pour renseigner les spécificités pour les informations de type XAML ou de membre XAML qui utilisent le type de stockage CLR. Le contexte de schéma XAML par défaut ne nécessite pas de techniques d’extension de système de type telles que le modèle Invoker, car les informations nécessaires sont disponibles à partir du système de type CLR.

Pour la logique de chargement d’assembly, le contexte de schéma XAML par défaut s’appuie principalement sur toutes les valeurs d’assembly fournies dans les mappages d’espaces de noms XAML. En outre, LocalAssembly pouvez indiquer à un assembly de charger, pour des scénarios tels que le chargement de types internes.

Contexte de schéma XAML WPF

Le contexte de schéma XAML WPF est décrit dans cette rubrique, car l’implémentation WPF fournit une illustration intéressante des types de fonctionnalités qui peuvent être introduites en implémentant un contexte de schéma XAML non par défaut. En outre, le concept de contexte de schéma XAML n’est pas abordé beaucoup dans la documentation WPF qui traite du code XAML WPF ; le comportement activé par le contexte de schéma XAML peut être entièrement compréhensible s’il est intégré à une discussion sur le fonctionnement du contexte de schéma XAML par défaut. Le contexte de schéma XAML WPF implémente le comportement suivant.

remplacements de recherche : WPF a quelques modèles de contenu pour XAML où il existe des propriétés de contenu XAML qui fonctionnent sans être ContentPropertyAttribute attributs. LookupContentProperty remplacements pour WPF implémentent ce comportement.

Report pour les expressions WPF : WPF propose plusieurs classes d’expression qui reportent une valeur jusqu’à ce qu’un contexte d’exécution soit disponible. En outre, l’extension de modèle est un comportement d’exécution qui s’appuie sur des techniques de report.

Optimisations de recherche de système de type : WPF a un vocabulaire XAML complet et un modèle objet, y compris les définitions de membres de classe de base qui héritent de centaines de classes définies par WPF. En outre, WPF lui-même est réparti sur plusieurs assemblys. WPF optimise sa recherche de type à l’aide de tables de recherche et d’autres techniques. Cela fournit des améliorations des performances par rapport au contexte de schéma XAML par défaut et à sa recherche de type CLR. Dans les cas où les types n’existent pas dans une table de recherche, le comportement utilise des techniques de contexte de schéma XAML similaires au contexte de schéma XAML par défaut.

extension XamlType et XamlMember : WPF étend les concepts de propriété avec les propriétés de dépendance et les concepts d’événement avec des événements routés. Pour donner à ces concepts une meilleure visibilité des opérations de traitement XAML, WPF étend XamlType et XamlMember, et ajoute des propriétés internes qui signalent la propriété de dépendance et les caractéristiques des événements routés.

Accès au contexte de schéma XAML WPF

Si vous utilisez des techniques XAML basées sur les System.Windows.Markup.XamlReader WPF ou System.Windows.Markup.XamlWriter, le contexte de schéma XAML WPF est déjà utilisé sur ces implémentations de lecteur XAML et d’enregistreur XAML.

Si vous utilisez d’autres implémentations de lecteur XAML ou d’enregistreur XAML qui ne s’initialisent pas avec le contexte de schéma XAML WPF, vous pouvez peut-être obtenir un contexte de schéma XAML WPF opérationnel à partir de XamlReader.GetWpfSchemaContext. Vous pouvez ensuite utiliser cette valeur comme initialisation pour d’autres API qui utilisent un XamlSchemaContext. Par exemple, vous pouvez appeler XamlXmlReader pour l’initialisation et passer le contexte de schéma XAML WPF. Vous pouvez également utiliser le contexte de schéma XAML WPF pour les opérations système de type XAML. Cela peut inclure l’initialisation de construction d’un XamlType ou d’un XamlMember, ou l’appel de XamlSchemaContext.GetXamlType.

Notez que si vous accédez à certains aspects du code XAML WPF à partir d’un point de vue de flux de nœuds XAML pur, certaines des fonctionnalités du framework WPF n’ont peut-être pas encore agi. Par exemple, les modèles WPF pour les contrôles ne sont pas encore appliqués. Par conséquent, si vous accédez à une propriété qui, au moment de l’exécution, peut être remplie avec une arborescence visuelle complète, vous pouvez voir uniquement une valeur de propriété qui fait référence à un modèle. Le contexte de service fourni pour les extensions de balisage WPF peut également ne pas être précis s’il est fourni à partir d’une situation non runtime et peut entraîner des exceptions lors de la tentative d’écriture d’un graphique d’objet.

Chargement xaml et assembly

Le chargement d’assembly pour les services XAML et .NET XAML s’intègre au concept CLR défini par AppDomain. Un contexte de schéma XAML interprète comment charger des assemblys ou rechercher des types au moment de l’exécution ou au moment de la conception, en fonction de l’utilisation de AppDomain et d’autres facteurs. La logique est légèrement différente selon que le code XAML est libre pour un lecteur XAML, est compilé en XAML dans une DLL par XamlBuildTask, ou est BAML généré par le PresentationBuildTaskde WPF.

Le contexte de schéma XAML pour WPF s’intègre au modèle d’application WPF, qui utilise à son tour AppDomain ainsi que d’autres facteurs qui sont des détails d’implémentation WPF.

Entrée de lecteur XAML (XAML libre)

  1. Le contexte de schéma XAML effectue une itération dans le AppDomain de l’application, en recherchant un assembly déjà chargé qui correspond à tous les aspects du nom, en commençant par l’assembly le plus récemment chargé. Si une correspondance est trouvée, cet assembly est utilisé pour la résolution.

  2. Sinon, l’une des techniques suivantes basées sur l’API clR Assembly est utilisée pour charger un assembly :

XamlBuildTask

XamlBuildTask est utilisé pour Windows Communication Foundation (WCF) et Windows Workflow Foundation.

Notez que les références d’assembly via XamlBuildTask sont toujours complètes.

  1. Appelez Assembly.Load(String) sur le nom qualifié.

  2. Si l’étape précédente échoue, utilisez le nom court (et le jeton de clé publique le cas échéant) pour appeler Assembly.Load(String).

BAML (PresentationBuildTask)

Il existe deux aspects du chargement d’assembly pour BAML : le chargement de l’assembly initial qui contient le fichier BAML en tant que composant et le chargement des assemblys de stockage de type pour tous les types référencés par la production BAML.

Chargement d’assembly pour le balisage initial :

La référence à l’assembly à partir de laquelle charger le balisage est toujours non qualifiée.

  1. Le contexte de schéma XAML WPF effectue une itération dans le AppDomain de l’application WPF, recherchant un assembly déjà chargé qui correspond à tous les aspects du nom, à partir de l’assembly le plus récemment chargé. Si une correspondance est trouvée, cet assembly est utilisé pour la résolution.

  2. Si l’étape précédente échoue, utilisez le nom court (et le jeton de clé publique le cas échéant) pour appeler Assembly.Load(String).

Références d’assembly par types BAML :

Les références d’assembly pour les types utilisés dans la production BAML sont toujours complètes, en tant que sortie de la tâche de génération.

  1. Le contexte de schéma XAML WPF effectue une itération dans le AppDomain de l’application WPF, recherchant un assembly déjà chargé qui correspond à tous les aspects du nom, à partir de l’assembly le plus récemment chargé. Si une correspondance est trouvée, cet assembly est utilisé pour la résolution.

  2. Sinon, l’une des techniques suivantes est utilisée pour charger un assembly :

    • Appelez Assembly.Load(String) sur le nom qualifié.

    • Si un nom court + combinaison de jetons de clé publique correspond à l’assembly à partir duquel le BAML a été chargé, utilisez cet assembly.

    • Utilisez un nom court + jeton de clé publique pour appeler Assembly.Load(String).

Voir aussi