Chapitre 1 : Modèle d’application « Longhorn »
Chapitre 1 : Modèle d’application « Longhorn »
Brent Rectrice
Wise Owl Consulting
Octobre 2003
Contenu
Fonctionnalités du modèle d’application « Longhorn »
Classe Application
Classe NavigationApplication
Extensible Application Markup Language (XAML)
Résumé
Pourquoi avons-nous besoin d’un nouveau modèle d’application ? L’une des principales raisons est de combler l’écart entre le développement d’une application pour Microsoft® Windows® et le développement d’une application pour le web.
Aujourd’hui, lorsque vous écrivez une application Windows, vous pouvez tirer parti des fonctionnalités Windows. Votre application peut fournir une interface utilisateur riche et réactive. Vous pouvez installer l’application sur l’ordinateur client, ce qui permet à l’application de s’exécuter hors connexion, sans connexion réseau. Les applications Windows peuvent tirer parti des fonctionnalités matérielles de l’ordinateur client.
Toutefois, les applications Windows traditionnelles présentent également un certain nombre d’inconvénients. En règle générale, vous devez installer une application Windows. Cela rend l’application et toutes les mises à jour difficiles à déployer. Les applications Windows ne s’exécutent pas dans le navigateur. Par conséquent, les paradigmes familiers de l’interface utilisateur web tels que les applications orientées page, la navigation directement d’une page à une autre, l’historique des pages et d’autres ne sont pas disponibles pour votre application, sauf si vous les créez à partir de zéro. Les applications Windows ne prennent pas également en charge le texte très bien, en particulier lorsque vous essayez de mélanger du texte et des graphiques sur la même page. La création d’une application Windows qui circule automatiquement du texte autour des graphiques et qui répond aux modifications initiées par l’utilisateur dans la taille de la fenêtre et les préférences utilisateur pour les polices et la lisibilité est une grande quantité de travail.
Les applications web ont également leurs propres forces distinctes. Lorsque vous accédez à une page web, le navigateur télécharge uniquement cette page et les composants requis par la page. Lorsque vous accédez à une nouvelle page, le navigateur télécharge ensuite les exigences de la nouvelle page. En d’autres termes, le navigateur télécharge progressivement l’application en fonction des besoins.
Le déploiement d’une application web est trivial. Quel déploiement ? Vous placez les composants d’application nécessaires sur un serveur et le navigateur les télécharge si nécessaire. Il n’y a pas de déploiement en soi.
La création de l’interface utilisateur pour une application web est également très facile. Vous déclarez vos intentions à l’aide du balisage. Par exemple, supposons que je souhaite une table dans une position spécifique. Je veux qu’une image suive le tableau. Je veux que du texte circule autour de l’image. Le mélange de texte, de graphismes et de médias (audio et vidéo) dans une application web est simple.
Bien sûr, les applications web ont également leurs mauvais points. Vous ne pouvez pas installer une application web sur le système de bureau ; par conséquent, l’application ne peut pas s’exécuter hors connexion. Vous devez toujours avoir une connexion au serveur. Certaines opérations d’application nécessitent des allers-retours vers le serveur, ce qui réduit les performances. Une sélection d’applications web de contrôles est assez primitive par rapport aux contrôles Windows disponibles. Une application web a donc généralement une faible interactivité. Il est également difficile de développer une interface utilisateur attrayante pour une application web, car vous devez exprimer n’importe quelle disposition non triviale à l’aide de tables.
Actuellement, les développeurs qui conçoivent de nouvelles applications doivent prendre une décision initiale, énorme et irréversible : l’application doit-elle être une application de style Web ou une application Microsoft Win32® classique ? Des modèles de programmation complètement distincts (et compétences !) sont nécessaires en fonction du modèle d’application que vous choisissez.
« Longhorn » vous permet de développer des applications à l’aide du meilleur des deux mondes. Le modèle d’application « Longhorn » prend les meilleures fonctionnalités des applications web et les meilleures fonctionnalités des applications Windows et les combine dans un modèle de programmation unifié unique basé sur du code managé.
Une deuxième raison majeure pour le développement d’un nouveau modèle d’application est de fournir un modèle de programmation unique qui peut créer la grande variété d’applications en cours d’utilisation. Examinez l’un de vos sites web préférés, tels que CNN ou MSNBC. Le site web est-il une application traditionnelle ? Est-ce un document ? Est-ce une présentation multimédia ? Dans de nombreux cas, la réponse est oui aux trois questions.
Lorsqu’un site web inclut des éléments d’interface utilisateur tels que des zones de liste, des contrôles de modification et des cases d’option, il ressemble à une application présentant une interface utilisateur. Toutefois, lorsqu’il affiche des images et du texte qui circulent autour des images, le site Web est similaire à un document. Lorsqu’il présente du contenu Flash, des graphismes, de l’audio, de la vidéo et de l’animation, le site Web semble être une présentation multimédia.
Bien sûr, ces sites Web riches sont difficiles à développer. Vous devez corriger ensemble une description basée sur le balisage HTML de la page, avec des contrôles Microsoft ActiveX® pour une interface utilisateur enrichie, avec des animations Flash incorporées et éventuellement à l’aide du format pdf (Portable Document Format) pour la prise en charge des documents. Toutes ces technologies utilisent une architecture différente, fournissent différentes caractéristiques de performances et nécessitent différents modèles de programmation et outils.
Cela signifie généralement que vous devez embaucher plusieurs développeurs avec différents ensembles de compétences pour développer chaque partie de l’application. Les développeurs doivent ensuite fusionner les différents modèles en une seule application fonctionnelle. Le développement de l’application est assez difficile. Le débogage est souvent un cauchemar.
« Longhorn » fournit une architecture unifiée qui prend en charge ces trois niveaux : documents, applications et supports. Voulez-vous créer votre interface utilisateur de manière déclarative à l’aide du balisage ? Vas-y. Avez-vous besoin d’utiliser des contrôles Windows enrichis ? Alors faites-le ! Voulez-vous écrire des gestionnaires d’événements dans un langage managé fortement typé ? Vous pouvez aussi le faire. Voulez-vous combiner du texte, des graphiques et des vidéos dans un document avec une disposition et une présentation intelligentes en fonction des préférences de l’utilisateur et optimisées pour un affichage et une lecture optimales sur le système client ? Devine quoi? Tu l’as aussi.
Le modèle d’application « Longhorn » permet d’écrire une application à l’aide d’un modèle de programmation unique qui prend en charge les fonctionnalités d’interface utilisateur de style application, la présentation de style document du texte et des graphiques, ainsi que l’intégration de différents supports. En outre, vous pouvez créer l’interface utilisateur à l’aide de balisage comme une application web. Vous obtenez également la facilité de déploiement (ou de manque de déploiement) d’une application web. Toutefois, vous disposez toujours des performances et de la possibilité d’installer l’application pour une utilisation hors connexion comme une application Windows. Votre application peut s’exécuter en tant qu’application autonome ou hébergée dans un navigateur Web en recompilant simplement une base de code source. Dans les deux cas, votre application peut être basée sur des formulaires, comme de nombreuses applications Windows traditionnelles ou basées sur des pages, comme les applications web.
Fonctionnalités du modèle d’application « Longhorn »
Le modèle d’application « Longhorn » définit ce qu’est une application :
- Ses points d’entrée
- Son flux de contrôle : comment naviguer d’une page à une autre
- Son état et ses ressources partagés
- Événements à l’échelle de l’application
- Son isolation à partir d’autres applications
Le modèle d’application « Longhorn » définit comment déployer et gérer une application :
- Déploiement en tant que fichiers uniques ou multiples
- Mise à jour, restauration et administration
Le modèle d’application « Longhorn » définit l’expérience de l’utilisateur avec l’application :
- Installation sans impact
- Autonome (style Windows) ou intégré dans le navigateur
- S’exécute en ligne ou hors connexion
- Modèle de navigation
Applications web « Longhorn »
Le modèle d’application « Longhorn » vous permet d’écrire une application riche de la même façon que les applications web d’aujourd’hui. Cela fournit un chemin de migration simple pour les développeurs web, car le code qu’ils écrivent est similaire au code pour les pages web HTML dynamiques (DHTML). Ils peuvent (frissonner) placer le balisage et le script dans le même fichier. Ils peuvent déployer les fichiers de l’application sur un serveur web. Les pages d’application s’exécutent dans le navigateur web.
Toutefois, le modèle objet d’une application de style web « Longhorn » est beaucoup plus simple et beaucoup plus puissant que DHTML. Le code de l’application peut utiliser la couche de présentation complète « Longhorn ». Par conséquent, une application web « Longhorn » peut utiliser des contrôles clients enrichis, prendre en charge les éléments multimédias et graphiques sur la page, gérer les événements localement, tout ce qu’une application cliente normale peut faire. En fait, une application web « Longhorn » n’est pas beaucoup différente d’une application de bureau « Longhorn » autre que celle que les fichiers vivent sur un serveur ; un navigateur héberge généralement, mais pas nécessairement, l’interface utilisateur ; et l’application s’exécute avec des autorisations restreintes, car l’utilisateur ne l’a pas installé sur le système client.
Applications de bureau « Longhorn »
Le modèle d’application « Longhorn » définit également comment écrire des applications de bureau. Une « Longhorn »application de bureau est une application que l’utilisateur a installée localement. Ces applications peuvent s’exécuter en ligne ou hors connexion. Ces applications peuvent s’inscrire auprès de l’interpréteur de commandes, placer des icônes sur le bureau, ajouter des raccourcis au menu Démarrer, etc.
Une application de bureau peut également s’exécuter dans la fenêtre du navigateur ou dans une fenêtre autonome. En fait, une application de bureau peut prendre en charge de nombreuses fonctionnalités traditionnellement associées à une application web, notamment les suivantes :
- Définissez explicitement des points d’entrée externes, c’est-à-dire, peuvent démarrer sur n’importe quelle page
- Partager l’état entre les pages
- Gérer différents événements, y compris les événements de navigation de page
- Contrôler le flux d’application
- Ajouter/supprimer des entrées d’un historique de page/journal de navigation de voyage
- Lancer des fenêtres d’application
Création d’une application « Longhorn »
Pour générer une application « Longhorn », vous définissez le modèle objet de votre application. Vous pouvez définir le modèle par programmation en écrivant du code ou de manière déclarative en écrivant du balisage dans un langage appelé XAML (Extensible Application Markup Language). Vous compilez votre code et/ou balisage dans un ou plusieurs assemblys .NET, un fichier manifeste d’application et un fichier manifeste de déploiement.
Si vous le souhaitez, vous pouvez empaqueter votre application dans un nouveau format de fichier, appelé conteneur. Les fichiers d’application d’un conteneur peuvent être compressés, chiffrés et signés numériquement.
Je discute de la création d’une application « Longhorn » en détail dans le chapitre 2, mais pour l’instant, l’idée principale est que la création d’une application « Longhorn » vous donne le code de l’application, un manifeste d’application qui décrit tous les composants utilisés par l’application et un manifeste de déploiement qui indique au système comment installer et gérer l’application.
Déploiement d’une application « Longhorn »
Le modèle d’application « Longhorn » fournit un déploiement simple et économique de votre application. Dans le cas le plus simple, vous copiez simplement les fichiers d’application sur un serveur. De même, l’installation de votre application est simple et sans impact.
Une option n’est pas d’installer l’application du tout. L’utilisateur peut accéder au manifeste d’application sur un serveur et l’exécuter. « Longhorn » télécharge de façon incrémentielle votre application et l’exécute. Vous n’obtenez aucune demande de confirmation, aucune configuration requise pour le redémarrage et aucune DLL enfer. En fait, vous n’avez même pas besoin de droits d’administrateur pour installer ou exécuter l’application.
Vous pouvez également accéder au manifeste de déploiement de l’application sur le serveur et l’exécuter. « Longhorn » télécharge de façon incrémentielle votre application, l’installe et l’exécute. Par défaut, toutes les applications « Longhorn » s’exécutent dans un environnement d’autorisation limité appelé Environnement d’exécution sécurisée (SEE).
Les applications s’exécutant dans see reçoivent un jeu d’autorisations restreint qui équivaut à peu près aux autorisations accordées aux applications actuelles associées à la zone Internet. Une application qui nécessite des autorisations supplémentaires que « Longhorn » fournit par défaut doit demander ces autorisations supplémentaires dans son manifeste d’application.
La première fois que l’utilisateur exécute une telle application, le Gestionnaire de confiance « Longhorn » évalue la demande d’autorisation élevée, informe l’utilisateur d’un niveau de risque suggéré associé à l’octroi de la demande d’autorisation de l’application et fournit une réponse suggérée pour ce niveau de risque. Lorsque l’utilisateur autorise le Gestionnaire de confiance à accorder à l’application ses autorisations demandées, le Gestionnaire de confiance enregistre ces informations. Les exécutions suivantes de l’application installée continuent sans avertissement de sécurité.
Aujourd’hui, lorsque vous installez une application localement, elle reçoit le jeu d’autorisations FullTrust simplement parce qu’elle se charge à partir de la zone LocalComputer. La sécurité d’accès au code (CAS) fonctionne différemment pour les applications « Longhorn ». Une application locale (ou installée) s’exécute sous la stratégie de sécurité du site à partir duquel l’utilisateur l’a téléchargé au lieu de recevoir automatiquement FullTrust simplement parce qu’il est installé localement.
Lors du chargement d’une application, de ses composants et de ses ressources, « Longhorn » fournit des preuves au système de sécurité CLR (Common Language Runtime) tel que
- Zone Internet et site d’origine (à partir de l’URI [Uniform Resource Identifier])
- Nom du serveur de publication et du module (à partir du manifeste de déploiement)
Le cas fournit ensuite une application basée sur la stratégie de sécurité sur les privilèges d’accès en fonction de la preuve de l’application.
Le manifeste de déploiement d’une application peut spécifier l’intervalle de mise à jour que « Longhorn » doit utiliser lors de la vérification d’une nouvelle version de l’application. Lorsque « Longhorn » détecte qu’une nouvelle version est disponible, elle télécharge et installe la nouvelle version en arrière-plan. La prochaine fois que l’utilisateur exécute l’application, elle reçoit la nouvelle version.
Lors de l’installation d’une application, « Longhorn » conserve la version précédente, le cas échéant. Si vous devez le faire, vous pouvez revenir sans douleur à la version précédente ou même désinstaller complètement l’application à l’aide d’Ajouter/supprimer des programmes. Les services informatiques peuvent envoyer (push) l’installation d’une application vers un système client pour un déploiement mains libres.
Vous spécifiez comment déployer l’application lorsque vous compilez le projet, et vous pouvez modifier le scénario de déploiement en recompilant, généralement avec peu ou pas de modifications apportées à votre code source.
Le programme d’un développeur interagit initialement avec une grande partie de la prise en charge de l’application « Longhorn » via une instance de la classe MSAvalon.Windows.Application. Nous allons donc examiner cette classe.
Classe application
Un programme « Longhorn » contient toujours une seule instance d’un objet d’application. Cet objet dérive directement ou indirectement de la classe MSAvalon.Windows.Application et exécute les fonctions suivantes :
- Fournit un point d’entrée, une encapsulation et une étendue pour l’application
- Permet à une application de partager du code et de l’état sur les pages qui composent l’application
- Fournit des événements au niveau de l’application
- Gère une collection des fenêtres de l’application
- Fournit un modèle de sécurité
- Définit toutes les ressources utilisées par l’application
La classe MSAvalon.Windows.Application fournit une prise en charge des applications de base à une application. En règle générale, vous l’utilisez lorsque votre application a besoin d’une surcharge faible et n’utilise pas les fonctionnalités de navigation de page. Toutefois, la plupart des applications de plateforme « Longhorn » utilisent la classe MSAvalon.Windows.NavigationApplication étroitement associée, qui hérite de MSAvalon.Windows.Application et ajoute la prise en charge de la navigation. Je vais discuter de la classe NavigationApplication
La liste des fichiers sources SimpleApplication1.cs, illustrée ici, illustre l’utilisation de l’objet Application. La méthode EntryClass.Main crée mon objet d’application spécialisé, MyAppet appelle sa méthode Exécuter pour lancer l’application. La classe MyApp remplace la méthode OnStartingUp, qui reçoit le contrôle lors du démarrage de l’application. Lorsque le système appelle la méthode OnStartingUp, j’appelle une méthode d’assistance qui crée la fenêtre principale de l’application, ajoute du texte à la fenêtre et affiche la fenêtre.
SimpleApplication1.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
namespace IntroLonghorn {
public class MyApp : MSAvalon.Windows.Application {
MSAvalon.Windows.Controls.SimpleText txtElement;
MSAvalon.Windows.Window mainWindow;
protected override void OnStartingUp (StartingUpCancelEventArgs e) {
base.OnStartingUp (e);
CreateAndShowMainWindow ();
}
private void CreateAndShowMainWindow () {
// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();
// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new
MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14,
FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();
}
}
internal sealed class EntryClass {
[System.STAThread]
private static void Main () {
MyApp app = new MyApp ();
app.Run ();
}
}
}
J’ai utilisé la ligne de commande suivante pour compiler le code source SimpleApplication1.cs dans une application exécutable. Vous devrez peut-être ajuster les chemins d’accès aux assemblys référencés.
csc /r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationCore.dll
/r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationFramework.dll
/r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\WindowsBase.dll
SimpleApplication1.cs
La classe Application contient plusieurs autres propriétés, méthodes et événements utiles. Par exemple, votre classe d’application peut remplacer la méthode virtuelle OnShuttingDown pour fournir un comportement d’arrêt personnalisé. La classe d’application fournit également les événements StartingUp et ShuttingDown afin que d’autres classes puissent s’inscrire aux notifications de démarrage et d’arrêt. La méthode Shutdown vous permet de lancer l’arrêt de l’application par programmation.
Vous pouvez référencer votre objet d’application à partir de plusieurs emplacements dans votre code source. Par conséquent, la classe Application fournit la propriété statique Current qui retourne une référence à votre objet d’application. Le fragment de code suivant utilise la propriété Current pour localiser l’objet d’application et s’inscrire à une notification d’événement d’arrêt :
MyApp app = (MyApp) MSAvalon.Windows.Application.Current;
app.ShuttingDown += new
Application.ShuttingDownEventHandler (ShutDownHandler);
§
private static void
ShutDownHandler (object sender, MSAvalon.Windows.ShuttingDownEventArgs e) {
§
}
Classe NavigationApplication
Lorsque vous souhaitez prendre en charge la navigation pour votre application, vous utiliserez généralement la classe MSAvalon.Windows.Navigation.NavigationApplication, qui étend la classe MSAvalon.Windows.Application. Bien que vous puissiez créer une application basée sur la navigation sans utiliser la classe NavigationApplication, l’utilisation de la classe fournit les fonctionnalités supplémentaires suivantes à votre application :
- Simplifie l’écriture d’applications basées sur la navigation ; généralement nécessaire pour sous-classer la classe
- Détermine quand une connexion est disponible
- Fournit des événements de navigation, tels que navigation, NavigationProcess, navigated, NavigationError, LoadCompletedet Arrêté— qui se déclenche lorsque l’événement approprié se produit dans l’une des fenêtres de l’application
- Partage l’état entre les pages
- Fournit un conteneur pour les valeurs de propriété partagées entre les pages
- Implémente une stratégie qui ouvre une fenêtre initiale par défaut
En externe, l’utilisateur d’une application de navigation ne peut accéder qu’aux points d’entrée bien définis de l’application. Toutefois, en interne, le développeur contrôle la navigation en raccordant des événements. Vous pouvez déterminer quand une fenêtre ou un cadre tente d’accéder à une nouvelle page et lorsque la navigation est terminée. Vous pouvez annuler ou rediriger n’importe quelle navigation. Vous trouverez l’identité de la page cible. Vous pouvez gérer les erreurs de navigation.
Le modèle de navigation familier facilite l’utilisation d’une application. Une application de navigation fournit un comportement similaire au web. Votre application peut utiliser des liens hypertexte, fournir des boutons Transférer et Précédent, afficher une liste Favoris et gérer un historique des pages. La classe « Longhorn » NavigationApplication classe et les classes associées fournissent toute la prise en charge de ces fonctionnalités.
Une application de navigation fonctionne en ligne ou hors connexion, et elle fonctionne de la même façon qu’un navigateur héberge l’application ou que l’application s’exécute en tant que autonome. En outre, vous avez un contrôle total sur ce comportement Weblike. Vous pouvez personnaliser l’expérience utilisateur en fonction des besoins. Vous pouvez insérer, supprimer et modifier des entrées Travelog pour contrôler l’emplacement des opérations Avant et Retour. Vous pouvez définir les pages (points d’entrée) journalisées dans l’historique.
Une application de navigation crée généralement une ou plusieurs instances de la classe MSAvalon.Windows.Navigation.NavigationWindow. La liste SimpleApplication2.cs, présentée ici, illustre une utilisation de ces classes. Cette liste est identique à SimpleApplication1.cs, sauf qu’elle utilise les classes NavigationApplication
SimpleApplication2.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Navigation;
namespace IntroLonghorn {
public class MyApp : MSAvalon.Windows.Navigation.NavigationApplication {
protected override void OnStartingUp (StartingUpCancelEventArgs e) {
base.OnStartingUp (e);
CreateAndShowMainWindow ();
}
private void CreateAndShowMainWindow () {
// Create the application's main window
mainWindow = new MSAvalon.Windows.Navigation.NavigationWindow ();
// Fill window with appropriate controls
§
// Show the window
mainWindow.Show ();
}
}
internal sealed class EntryClass {
[System.STAThread]
private static void Main () {
MyApp app = new MyApp ();
app.Run ();
}
}
}
Le code que vous avez vu jusqu’à présent n’est qu’une autre variante sur les modèles de programmation traditionnels. Le seul aspect nouveau est les classes réelles que j’ai utilisées. Toutefois, la plupart du temps, vous n’écrirez pas beaucoup de ce code. Prenons un léger détour et apprenons-en davantage sur un nouveau langage de programmation qui vous permet d’écrire ce même code dans un format beaucoup plus compact et, au moins, plus compréhensible.
Extensible Application Markup Language (XAML)
Dans de nombreuses applications, la plupart du code que vous écrivez concerne la création et la mise à jour de l’interface utilisateur de l’application. En fait, dans les exemples précédents, il n’y avait pas de code autre que celui requis pour créer l’interface utilisateur. Au cours des dernières années, de nombreux développeurs ont appris à écrire, et même à préférer définir, l’interface utilisateur d’une application à l’aide d’un certain nombre de langages de balisage disponibles. La plateforme « Longhorn » définit un nouveau langage de balisage nommé extensible Application Markup Language (XAML ; prononcé « Zamel », qui rime avec « chameau »).
L’utilisation d’un langage de balisage pour définir une interface utilisateur présente un certain nombre d’avantages par rapport à l’utilisation d’un langage de programmation procédural. Ces avantages sont les suivants :
- Hiérarchies de contrôle plus apparentes
- Héritage de propriété plus apparent
- Traitement et interprétation plus faciles du langage de balisage par les outils
- Séparation potentielle de l’interface utilisateur et du code procédural
J’aime XAML et je préfère l’utiliser pour définir mes INTERFACES utilisateur plutôt que d’utiliser le codage de type procédural que je vous ai montré jusqu’à présent dans ce chapitre. Toutefois, ne pensez pas que vous serez en mesure de faire tout ce dont vous aurez besoin en utilisant rien, mais XAML.
Considérez cette instruction à partir de la documentation : « Les documents peuvent souvent être écrits entièrement en XAML et affichés dans le navigateur ». Je souligne avec hâte que cette phrase utilise le mot documents, pas applications, et qu’elle qualifie l’instruction avec le terme souvent. Lorsque vous écrivez un document qui affiche du contenu statique, vous pouvez le créer en XAML pur. Vous pouvez même écrire un document qui utilise la liaison de données pour afficher et mettre à jour le contenu à partir d’une source de données à l’aide de rien d’autre que XAML. Vous pouvez définir des animations et des effets sur la souris à l’aide de rien, mais de XAML. Vous pouvez faire un tas d’utilisation de rien, mais XAML. (En fait, j’essaie de faire autant que possible en XAML et aussi peu que possible dans le code. Mes applications semblent être moins buggy et travailler plus rapidement le moins de code que j’écris !) Néanmoins, pour écrire une application de production, vous devez généralement réagir aux événements, fournir une logique de décision personnalisée ou inclure de nombreuses autres opérations autres que l’interface utilisateur. Vous devrez donc combiner xaml et code. Heureusement, c’est extrêmement facile à faire.
Je vais décrire les fichiers XAML plus en détail dans le chapitre 3 ; pour l’instant, examinons un primer pour XAML :
- Un nom d’élément XAML est un nom de classe .NET Framework. Lorsque vous définissez un élément XAML, vous créez efficacement une instance de la classe .NET Framework portant le même nom que l’élément XAML.
- Un nom d’attribut XAML correspond à la propriété ou au champ portant le même nom, généralement dans l’instance de classe.
Dans le programme SimpleApplication1.cs, je crée une fenêtre et y ajoute des contrôles à l’aide du code suivant :
// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();
// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new
MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14, FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();
Le document XAML suivant produit exactement cette même interface utilisateur.
HelloWorld.xaml
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
<SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
</Window>
L’élément Window racine crée une instance d’une classe nommée MSAvalon.Windows.Window. En quelque sorte, le système de génération doit savoir que l’élément XAML nommé Window fait référence à une instance de la classe nommée MSAvalon.Windows.Window. Le xmlns valeur d’attribut fournit ce mappage.
Les analyseurs XML interprètent des noms d’éléments non qualifiés par rapport à l’espace de noms spécifié dans l’attribut d’espace de noms le plus récent, dans l’étendue, l’attribut d’espace de noms par défaut, xmlns. Lorsque vous spécifiez une valeur de xmlns de «https://schemas.microsoft.com/2003/xaml", le système de build interprète un nom d’élément non qualifié sur l’élément de définition, ou l’un de ses éléments subordonnés, comme le nom d’une classe dans un ensemble prédéfini d’espaces de noms.
Permettez-moi de le reposer en termes plus concrets, en utilisant C# comme exemple. La déclaration xmlns
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Controls.Primitives;
using MSAvalon.Windows.Data;
using MSAvalon.Windows.Documents;
using MSAvalon.Windows.Shapes;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Media.Animation;
using MSAvalon.Windows.Navigation;
La déclaration d’espace de noms par défaut standard fait également référence au système de build PresentationFramework et assemblys PresentationCore, qui contiennent des classes dans les espaces de noms précédemment répertoriés.
Je définisse l’attribut Visible de l’élément Window sur true. Cela correspond à mon code d’origine qui affiche la fenêtre en appelant sa méthode Show.
J’ai imbriqué un élément
Enregistrez le code XAML précédent dans un fichier nommé HelloWorld.xaml et exécutez le fichier. Le navigateur interprète le code XAML dans le fichier et affiche l’interface utilisateur, comme illustré dans la figure 1-1.
.gif)
Figure 1-1. Navigateur affichant la version XAML de Hello World (cliquez sur l’image pour afficher une image plus grande)
Vous pouvez utiliser une classe .NET qui n’est pas définie dans l’un des espaces de noms par défaut répertoriés précédemment. Un exemple classique utilise une classe à partir d’un assembly que vous créez. Le système de génération doit pouvoir mapper le nom de l’élément que vous spécifiez dans le fichier source XAML à la classe .NET appropriée dans l’assembly approprié. XAML définit une instruction de traitement XML nommée ? Mappage que vous utilisez pour créer cette association.
Le ? Le mappage PI vous permet de définir un préfixe d’espace de noms XML mappé à un espace de noms CLR et à un assembly. Lorsque vous qualifiez un nom d’élément XAML avec ce préfixe d’espace de noms, vous indiquez au système de génération, en effet, de prendre le nom de l’élément, d’ajouter le préfixe CLR au nom et de créer une instance de la classe avec le nom résultant. Le compilateur référence l’assembly spécifié afin qu’il puisse trouver la définition de la classe.
L’exemple suivant crée une instance de la classe WiseOwl.Statistics.PoissonDeviate, dont la définition réside dans l’assembly WiseOwl.Statistics.Library :
<?Mapping XmlNamespace="stat" ClrNamespace="WiseOwl.Statistics"
Assembly="WiseOwl.Statistics.Library" ?>
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
<SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
<stat:PoissonDeviate Mean="5.0" />
</Window>
Je ne peux pas insister suffisamment sur le fait que XAML est simplement un autre moyen de produire du code qui utilise les classes d’interface utilisateur .NET Framework. En fait, vous pouvez avoir un outil qui affiche une spécification d’interface utilisateur XAML graphiquement à l’aide d’un concepteur visuel. Un autre outil peut effectuer l’inverse et vous permettre de concevoir l’interface utilisateur graphiquement et de l’enregistrer sous forme de fichier XAML. Pourtant, un autre outil peut enregistrer la conception de l’interface utilisateur en tant que code procédural, ce qui est similaire au fonctionnement du concepteur WinForms. Toutes ces approches sont simplement différentes méthodes de spécification des mêmes informations.
Plus haut dans ce chapitre, j’ai mentionné que le navigateur pouvait afficher un fichier XAML dans sa fenêtre. Le navigateur ne peut le faire que lorsque le fichier XAML ne contient que du balisage, comme l’exemple simple illustré. À mesure que votre interface utilisateur devient plus complexe, vous devez généralement utiliser des gestionnaires d’événements et d’autres codes sources nonmarkup en plus du code XAML qui décrit l’interface utilisateur. Chaque fois que vous disposez d’une base de code source mixte, c’est-à-dire du balisage et du code source nonmarkup, vous devez compiler le balisage et le code source à l’aide de l’utilitaire MSBuild. Après la compilation, vous pouvez exécuter l’application en tant que composant autonome ou afficher l’interface utilisateur obtenue par le navigateur.
Résumé
D’accord! Vous comprenez maintenant les principes de base du nouveau modèle d’application. Vous avez appris à utiliser le balisage pour créer une interface utilisateur déclarativement, bien qu’une interface utilisateur très simple. Vous pouvez écrire l’équivalent de pages Web à l’aide de fichiers XAML et déployer ces fichiers sur un serveur pour qu’un utilisateur puisse parcourir. Toutefois, les scénarios plus intéressants nécessitent généralement de compiler l’application avant de la déployer. Nous allons donc vous lancer et apprendre à créer et déployer une application « Longhorn ».
continuer au chapitre 2 : Création d’une application « Longhorn ».
© Microsoft Corporation 2003. Tous les droits réservés.
IntelliSense, Microsoft, MSDN, MS-DOS, Visual Basic .NET et Visual Studio .NET sont des marques déposées ou des marques déposées de Microsoft Corporation aux États-Unis et/ou dans d’autres pays. D’autres noms de produits et de sociétés mentionnés ici peuvent être les marques de leurs propriétaires respectifs.