Création d’une application Internet riche (RIA) à l’aide de Silverlight – Partie I

Auteur : Richard Griffin – Conchango
Blog : http://blogs.conchango.com/richardgriffin

This article appeared in the Expression Newsletter; subscribe to get the next issue.

Dans cet article et les articles suivants, nous vous montrerons comment créer une application RIA en utilisant Silverlight, nous illustrerons le flux de travail concepteur/développeur et nous vous expliquerons de quelle manière exploiter pleinement les outils dont vous vous servez depuis des années tout comme certains outils que vous ne connaissez peut-être pas encore ou que vous venez tout juste de commencer à utiliser.

L’application que nous allons créer au cours de cette série d’articles sera fondée sur l’API de création de signets sociaux du service del.icio.us. Si vous n’avez jamais entendu parler de ce service, je vous recommande fortement d’aller le découvrir pour vous rendre compte à quel point il peut faciliter la gestion de vos signets. De mon point de vue, ce service présente deux avantages évidents. En premier lieu, en tant qu’utilisateur de plusieurs ordinateurs, je devais me souvenir des URL de site trouvées sur un ordinateur lorsque je passais d’un PC à un autre pour surfer sur Internet ; avec del.icio.us, ce n’est plus le cas. En second lieu, del.icio.us constitue un formidable réseau social grâce auquel je peux partager des signets avec d’autres utilisateurs qui ont les mêmes centres d’intérêt que moi, mais également consulter facilement l’ensemble des signets créés par les internautes.

Del.icio.us comporte une API simple que vous pouvez appeler pour qu’elle renvoie les données demandées au format XML. L’application Netlicious a été initialement conçue et développée par XXX en tant que client Windows Forms qui permettait aux utilisateurs de consulter facilement tous les signets organisés par mot clé (ou « tag ») ou sous forme de liste publiée ou de lot créés par l’utilisateur directement sur votre bureau, sans avoir à ouvrir une fenêtre de navigateur pour accéder à votre page d’accueil Delicious.  L’application est un exemple idéal pour illustrer la façon dont on peut utiliser Silverlight pour créer une application RIA qui s’exécute dans le navigateur et optimise l’espace de persistance de l’utilisateur, tout en exploitant le nuage pour fournir toutes les données dont a besoin l’application pour fonctionner correctement.

Pour les besoins de cet exemple, nous supposerons que l’application est conçue sur le même modèle que l’application Netlicious initiale et que nous sommes chargés de développer une version RIA dans Silverlight. Ma première tâche de développeur consiste à créer la solution Visual Studio que nous utiliserons et à créer la structure de l’architecture requise. Collecter toutes les données du nuage pour les intégrer aux couches présentation n’est pas ma seule tâche initiale, je dois aussi créer et implémenter un modèle de présentation qui sépare les tâches entre Felix, chargé d’implémenter la conception de l’interface utilisateur, et moi-même. En adoptant ce modèle, je propose également une architecture qui rend possible l’affichage des données dans Blend, ce qui permet de tester en pseudo runtime le comportement et l’apparence des contrôles que le concepteur doit créer. L’un des problèmes auxquels nous avons été confrontés dans le passé est que même si les données XAML s’affichaient correctement au moment de l’exécution, elles n’étaient pas toujours visibles dans Blend ; ce problème se produisait lorsque l’interface utilisateur était étroitement liée à des objets et services métier qui n’étaient pas disponibles au moment de la conception. Une autre des tâches des développeurs d’interface utilisateur est de fournir une version de l’application au moment de la conception afin que les concepteurs soient plus productifs. Avec les nouvelles versions de Blend, les développeurs d’interface utilisateur auront la possibilité de créer des représentations du modèle de données XML pour fournir aux concepteurs une version au moment de la conception.

L’utilisation du modèle d’affichage passif (Passive View) créé par Martin Fowler est a priori une tâche spécifique au développeur. Toutefois, il est essentiel que le concepteur sache de quelle façon la couche présentation a été construite, car une meilleure compréhension du modèle utilisé aidera le concepteur à travailler plus efficacement à différents niveaux. Sur le plan de la communication tout d’abord, une meilleure compréhension du modèle facilitera la communication avec le développeur. Ensuite, elle permettra au concepteur, lors de la création de contrôles utilisateur ou de styles et modèles pour les contrôles basés sur un modèle, d’appréhender plus précisément les motivations qui ont conduit à implémenter une structure donnée. Même si la plupart des concepteurs ne montre pas un grand intérêt pour les architectures logicielles, le fait d’avoir une vue d’ensemble contribue à améliorer le flux de travail concepteur/développeur. Cela s’applique également aux développeurs pour qui il est essentiel de mieux comprendre la conception et l’utilisation finale de l’application.

Silverlight et WPF leur permet d’adopter le modèle d’affichage passif qui facilite l’application des principes de séparation des tâches et de responsabilité unique pour les composants requis dans l’architecture. L’un des avantages de ce modèle est de faciliter le test des composants. Il est établi que le modèle présente plusieurs avantages, mais son implémentation est-elle compliquée, notamment pour un développeur d’interface utilisateur qui n’a jamais utilisé ce modèle auparavant ? Il existe un outil très utile, appelé Ninject, qui a été développé par Nate XXX dans le but de créer un modèle simple d’injection de dépendance. L’injection de dépendance (DI) nous aide à appliquer le principe de responsabilité unique que nous voulons utiliser dans l’application et constitue par ailleurs un mécanisme qui permet une utilisation efficace du modèle d’affichage dans l’application. Pour plus d’informations sur l’injection de dépendance, cliquez ici. L’injection de dépendance permet de créer des composants à faible couplage et à forte cohésion.

Nous avons vu quelques-uns des principes généraux que nous souhaitons utiliser dans l’application, nous allons maintenant créer l’architecture de l’application ainsi que les références appropriées ; une remarque rapide sur les références, je préfère généralement ajouter tous les assemblys référencés qui sont externes à l’infrastructure dans un dossier distinct appelé Lib et situé dans le répertoire racine de l’application.

Si vous ne l’avez pas encore fait, démarrez Visual Studio et créez une application Silverlight, en veillant à sélectionner l’option pour créer un projet Web qui hébergera votre application Silverlight. Nous pourrions utiliser l’option de génération dynamique, mais nous voulons utiliser une page de test HTML pour exécuter les tests que nous prévoyons de faire au cours des articles ultérieurs.

Une fois que la solution d’application Silverlight a été créée dans Visual Studio, nous devons créer les autres projets Silverlight qui seront utilisés dans la solution. Commencez par créer le projet principal Delicious qui contiendra toutes les classes du modèle de données et les wrappers autour des appels de l’API Delicious que nous allons utiliser. Puis ajoutez une nouvelle bibliothèque de classes Silverlight à la solution appelée Delicious.

Afin d’obtenir la disposition souhaitée pour le nuage de mots clés (Tag Cloud) qui sera le premier élément d’interface utilisateur généré, je vais me servir du panneau d’agencement animé (Animated Wrap Panel) de Dave Reylea. Pour cela, nous ajoutons le projet à la solution existante. J’ai également créé un projet de test Silverlight de Dave Wilcox, que nous expliquerons dans un article ultérieur. Lorsque tous les projets dont nous avons besoin pour l’application ont été ajoutés, la solution et la structure des projets doit ressembler à ceci.

Prenons une minute pour récapituler ce que nous venons de faire, notamment identifier les projets qui ont été ajoutés.

1. Le panneau d’agencement animé définit la disposition des éléments d’interface utilisateur du nuage de mots clés.
2. Delicious est le projet principal qui fournit le modèle de données et les services.
3. Delicious.Test contiendra tout notre code de test.
4. DeliciousSilverlight regroupera tous nos éléments d’interface utilisateur XAML.
5. DeliciousSilverlightWeb est le projet Web qui contient l’objet Silverlight de notre page HTML.

Tous les composants ayant été ajoutés, le projet d’interface utilisateur DeliciousSilverlight doit maintenant référencer les projets et assemblys nécessaires. Notre prochaine tâche sera donc d’ajouter ces références. Cliquez avec le bouton droit sur le projet DeliciousSilverlight et ajoutez les références au panneau d’agencement animé, au projet principal Delicious et aux assemblys principaux Ninject. Nous devons également ajouter une référence à l’assembly System.Xml.Linq.

Le projet d’interface utilisateur contient maintenant toutes les références souhaitées. Nous pouvons donc ajouter notre classe Module et notre classe Service Locator qui fourniront le modèle d’affichage passif dont nous avons parlé précédemment. L’utilisation de la classe Module requise par Ninject permet au développeur de fournir des exemples de données au concepteur lorsque celui-ci utilise Blend pour modifier des éléments d’interface utilisateur avec des données de test liées aux contrôles au moment de l’exécution. Pour plus d’informations sur les classes Module et Kernel, cliquez ici.

Le code contient tout le code nécessaire pour le module de l’application ; il fournit à l’application toutes les informations relatives à la liaison des services et des modèles d’affichage correspondants utilisés dans l’application. Vous pouvez voir ici que nous collectons les données de la classe Post Service et son modèle d’affichage, tout comme celles de la classe Tag Service. Deux autres points importants sont à noter. Première chose, nous allons injecter le service dans le modèle d’affichage qui fournit les composants à faible couplage et à forte cohésion. Deuxième chose, nous injectons la chaîne proxy dans les classes d’implémentation Post Service et Tag Service, et nous n’exécuterons ce code que si l’application est exécutée dans le navigateur.  Une fois que ce code est défini, nous devons créer les classes du modèle d’affichage pour chaque affichage. Un affichage est classé en tant que contrôle utilisateur et, personnellement, j’ai l’habitude de nommer tous les contrôles utilisateur en ajoutant View à la fin de leur nom. Cela permet d’identifier rapidement les contrôles. Chaque affichage est associé à un modèle d’affichage. Par exemple, TagView et TagViewModel permettent de savoir facilement et rapidement à quels modèles d’affichage sont associés les affichages en question.

À présent, nous devons créer les modèles d’affichage nécessaires pour présenter les données dans les affichages. Tous les modèles d’affichage implémentent INotifyPropertyChanged. L’interface INotifyPropertyChanged permet d’utiliser des notifications intégrées pour notifier les changements de données à l’affichage en liant le contexte de données de l’affichage directement au modèle d’affichage.  Cette méthode simple garantit une parfaite synchronisation entre l’affichage et les données renvoyées par le service. La classe du modèle d’affichage est structurée de sorte qu’elle présente les données demandées par l’affichage, son autre responsabilité étant d’appeler le service pour demander des données.

Le code ci-dessus illustre le constructeur du modèle d’affichage et il est important de noter que nous avons ajouté l’attribut Inject de Ninject au constructeur afin de permettre l’injection. Vous pouvez aussi noter que le constructeur renferme un appel pour extraire les mots clés du service de mots clés. Après avoir créé le modèle d’affichage, nous devons maintenant le lier à l’affichage approprié.

Commençons par le code-behind de l’affichage. Lors de cette nouvelle étape, nous allons lier le panneau d’agencement animé avec l’animation requise et avec le gestionnaire d’événements PropertyChanged sur le modèle d’affichage afin que l’affichage soit notifié des nouvelles données à afficher dans l’interface utilisateur. Nous ajoutons d’abord la propriété du contexte de données qui fournit l’affichage avec une référence au modèle d’affichage. Nous reparlerons de cela tout à l’heure lorsque nous verrons les éléments XAML. Dans le constructeur de l’affichage, nous pouvons intégrer une condition qui détecte si l’affichage est exécuté dans Blend. L’appel de DesignerProperties est très utile pour permettre au concepteur d’utiliser les affichages au moment de la conception. Nous devons ensuite ajouter un gestionnaire d’événements à l’événement modifié de la propriété des modèles d’affichage et enfin, indiquer au panneau d’agencement animé la durée de l’animation ainsi que le type d’animation à utiliser.

Dans le gestionnaire de l’événement modifié de la propriété, nous devons rechercher manuellement quelle propriété a changé et, dans ce cas précis, l’affichage ne porte que sur la collection de mots clés. Si la collection de mots clés a été modifiée, nous créons un élément d’interface utilisateur TextBlock, nous définissons le nom du mot clé comme texte et nous attribuons une valeur à FontSize.

Nous obtenons enfin l’affichage souhaité. Cela nous a pris un peu de temps de passer par toutes les couches, mais cette organisation des composants offre de nombreux avantages, comme nous l’avons expliqué auparavant. Le principal élément à remarquer dans l’affichage est le contexte de données (DataContext) qui est lié au modèle d’affichage. Nous procédons généralement ainsi pour tirer profit de la puissante fonctionnalité de liaison de données offerte par Silverlight. J’ai également ajouté au panneau d’agencement animé une visionneuse qui permet à l’utilisateur de faire défiler un grand nombre de mots clés. Le résultat final est présenté ci-dessous. Avec le panneau d’agencement animé, la disposition des mots clés est conservée lorsque nous redimensionnons la fenêtre du navigateur, tout en offrant une animation attrayante.

Nous avons abordé beaucoup de points dans ce premier article. L’expérience que j’ai pu avoir sur des projets clients m’a montré que les premières étapes sont prises par le développeur et c’est pourquoi j’ai voulu dans cet article illustrer et décrire les objectifs à atteindre par le développeur d’interface utilisateur. Notre but n’est pas seulement de créer une application qui puisse être testée, mais de créer aussi une application fondée sur une solide architecture avec des composants à faible couplage et à forte cohésion. Nous devons également nous assurer que les affichages que nous intégrons à l’architecture peuvent être visibles au moment de la conception dans Blend, et cela peut être plus simple qu’il n’y paraît.

Dans l’article suivant, nous créerons une interface utilisateur graphique plus proche de la conception réelle. C’est le moment où nous commençons à voir les avantages de mettre en avant les concepteurs dans un monde qui était essentiellement tourné vers les développeurs, sans oublier que la possibilité donnée aux concepteurs d’utiliser des outils qui manipulent directement les fichiers sur lesquels nous travaillons comporte aussi des inconvénients.