Clonage/fabrique d’objets : sans mécanismes supplémentaires, un type référence ne peut généralement pas être inclus dans plusieurs positions dans une arborescence d’objets WPF. (Exemples de mécanismes supplémentaires qui offrent la prise en charge du partage ou de la réutilisation dans WPF incluent des objets basés sur Freezable , ou la prise en charge d’objets couramment partageables tels que Brush ceux référencés en tant qu’élément à partir d’un ResourceDictionary .) Une façon de cloner un objet qui se trouve déjà dans l’arborescence d’objets consiste à sérialiser l’objet à l’aide XamlWriter.Save de . Vous utilisez ensuite la chaîne sérialisée comme entrée pour un appel à Load , avec un flux ou XmlReader comme intermédiaire.

Construction d’objets basés sur des informations juste-à-temps : il existe souvent d’autres façons d’avoir une liaison tardive ou une entrée fournie par l’utilisateur modifier l’état des objets existants. Par exemple, vous pouvez utiliser la même valeur pour définir plusieurs propriétés ou utiliser la liaison de données. Toutefois, si vous avez un scénario où même le type d’objet à créer n’est déterminable qu’au moment de l’exécution ou avec l’interaction utilisateur, la création d’un tel objet en créant une chaîne pour Load l’entrée est souvent une technique utile.

Utilisation de techniques de ressources existantes : le Stream type est souvent utilisé dans d’autres frameworks ou technologies pour transférer des données ou des objets entre les limites de l’application ou pour des situations similaires. Vous pouvez ensuite utiliser les Stream techniques pour stocker ou obtenir des données au format XAML que vous utilisez pour créer un objet dans le cadre de votre application.

Documents fixes : Votre application peut charger des documents XPS locaux ou téléchargés pour l’inclusion dans une arborescence d’objets d’application WPF et une interface utilisateur.

Notes

Cette documentation décrit parfois un graphique d’objet, par opposition à une arborescence d’objets. Une relation parent-enfant stricte n’existe pas toujours dans les relations d’objet d’exécution d’une application WPF au moment de l’exécution. Par conséquent, un graphique d’objet est une terminologie plus largement applicable. Toutefois, étant donné que WPF inclut également deux API de conceptualisation d’arbre différentes ( LogicalTreeHelper , VisualTreeHelper ), la métaphore d’arbre s’applique toujours de manière adéquate à la plupart des cas réels dans WPF. Toutefois, du point de vue du langage XAML, le graphique d’objets est souvent le meilleur moyen de réfléchir à la façon dont les objets sont créés en XAML, car le langage XAML lui-même ne spécifie pas nécessairement les méthodologies de classe d’assistance qui apportent plus de relations dans une structure d’arborescence.

Sécurité de l’accès au code, XAML libre et XamlReader

Le XAML est un langage de balisage qui représente directement l’instanciation d’objets et leur exécution. Ainsi, les éléments créés en XAML ont la même capacité d’interagir avec les ressources système (accès réseau, e/s de système de fichiers, par exemple) que le code généré équivalent.

WPF prend en charge la sécurité d’accès du code du .NET Security Framework (CAS). Cela signifie que le contenu WPF exécuté dans la zone Internet a réduit les autorisations d’exécution. « XAML libre » (les pages de code XAML noncompilé interprétés au moment du chargement par une visionneuse XAML) et l’application de navigateur XAML (XBAP) sont généralement exécutées dans cette zone Internet et utilisent le même jeu d’autorisations. Toutefois, le XAML chargé dans une application d’un niveau de confiance totale dispose du même accès aux ressources système que l’application d’hébergement. Pour plus d’informations, consultez Sécurité de confiance partielle de WPF .

Les implications de ces instructions sont XamlReader que votre conception d’application doit prendre des décisions d’approbation concernant le code XAML que vous décidez de charger. Si vous chargez du code XAML qui n’est pas approuvé, envisagez d’implémenter votre propre technique de bac à sable (sandbox) pour la façon dont vous chargez le graphique d’objets résultant.

XamlReader peut également être appelé par du code d’approbation partielle. Dans ce cas, la zone de sécurité Internet est appliquée pour la sécurité de l’accès au code. Si quelque chose dans le code XAML chargé n’est pas valide sous la zone de sécurité Internet, une exception d’analyse XAML est levée. Sous XBAP et d’autres cas d’approbation partielle au niveau de la plateforme, où XamlReader fait partie de l’exécution, vous obtenez le même comportement d’exception qu’avec les appels d’approbation partielle explicites.

XAML WPF, lecteurs/enregistreurs XAML et contrôle de version du langage XAML

XAML2009 inclut des fonctionnalités de langage telles que x:Reference et x:FactoryMethod . Vous pouvez utiliser des signatures ou charger du Load Parse code XAML qui utilise ces fonctionnalités. Toutefois, ces fonctionnalités de langage ne sont pas prises en charge pour le code XAML qui doit être compilé (par exemple, XAML pour l’action de génération de page dans une application WPF, ou tout code XAML qui implique la tâche de compilation de balisage dans les actions de génération).

Types WPF et technologie WPF dans les concepts de prise en charge généraux qui reposent sur l’accès aux éléments internes WPF. Par exemple, la façon dont WPF implémente les propriétés de dépendance s’appuie sur des techniques internes pour une recherche efficace de membre de type. L’accès à ces éléments internes est activé par les API de lecture et d’écriture XAML fournies dans XamlWriter XamlReader et à partir de l’espace de noms et de l’assembly System.Windows.Markup PresentationFramework. Toutefois, les lecteurs XAML de niveau inférieur et les enregistreurs XAML de l’assembly System.Xaml (classes basées sur System.Xaml.XamlReader , System.Xaml.XamlWriter ) n’ont pas accès aux éléments internes WPF. Il n’existe aucune dépendance entre System.Xaml et n’importe quel assembly spécifique à WPF. Sans accès aux éléments internes WPF, les lecteurs et les enregistreurs System.Xaml ne peuvent pas charger ou enregistrer correctement tous les types WPF ou les types basés sur les types WPF. En particulier, les lecteurs et les enregistreurs System.Xaml ne comprennent pas les concepts tels que le magasin de propriétés de sauvegarde des propriétés de dépendance WPF, ou toutes les spécificités de la façon dont WPF utilise des styles, des dictionnaires de ressources et des modèles. Par conséquent, vous avez le choix entre :

Si vous chargez des types WPF et/ou si vous utilisez du code XAML dans un formulaire BAML de quelque manière que ce soit, utilisez les lecteurs XAML PresentationFramework et les enregistreurs XAML.

Si vous ne vous fiez à aucun type WPF ou à la forme BAML de XAML et que vous n’utilisez pas le lecteur XAML ou l’implémentation de l’enregistreur XAML d’une autre technologie spécifique pour des raisons spécifiques à cette infrastructure, utilisez les lecteurs XAML System.Xaml et les enregistreurs XAML.

Implémentation du stockage System.Xaml dans .NET 4

XamlReader est la surface d’API pouvant être appelée pour l’analyseur XAML au niveau de l’infrastructure WPF. Le même analyseur XAML sous-jacent effectue également le chargement et l’analyse XAML au moment de l’exécution pour les applications WPF qui ciblent .NET Framework 3.0 et .NET Framework 3.5.

Si vous ciblez .NET Framework 4, l’API externe est la même, mais certaines parties de l’implémentation sont basées sur l’implémentation XAML générale .NET Framework 4 dans l’assembly System.Xaml, ce qui améliore la plupart des aspects techniques et de création de rapports de l’analyse XAML. Le ciblage .NET Framework 4 implique nécessairement d’inclure System.Xaml comme référence et des détails d’implémentation tels que les exceptions signalées peuvent provenir de types définis par System.Xaml.