Comme je vous l’avez écrit dans mon précédent article, quelques prérequis doivent être connus afin de continuer à bien notre quête. En effet, le chemin sera long avant de maîtriser tous les tenants et aboutissants de cette matière vaste. Selon l’adage, “petit train ira loin”, je m’efforcerai le plus possible à rentrer dans les détails, quitte parfois à sortir de notre but initial. Prenons par exemple cet article, il traîte du databinding, bien qu’il se détourne de notre but (Composite Application Guidance), il pourra néanmoins vous servir pour comprendre le principe du binding dans wpf et silverlight (ce qui pourra vous servir pour d’autres projets). Et finalement, ce n’est pas cela être Agile ?  Se développer de manière indépendante et ensuire recoller les morceaux (ici l’apprentissage) afin de former un tout (la connaissance).

Qu’est ce que le databinding ?

Selon Ms, c’est la méthode qui permet de lier les composants UI (textbox, listbox,…) à la couche métier. En effet, si les données changent dans la couche métier et que le binding est correctement configuré, les éléments UI se mettront à jour automatiquement. Mais l’inverse est également vrai, si l’utilisateur rentre une valuer dans un textbox, par le binding, le changement sera automatiquement reflété dans la couche métier.

Concept du databinding :

fig 1 (from MSDN)

• La databinding est le lien entre l’objet cible (target en anglais) et l’objet source. Chaque Binding possède quatre composants, un “binding target object” (l’objet cible), une “property target” (la propriété cible de l’ojet cible), un “binding source object” (la source de donnée), et un “path” c’est à dire un chemin vers la valeur se trouvant dans l’objet source.

Par exemple, si vous vouler “binder” le contenu d’un Textbox à la propriété Nom d’un objet Humain, votre objet cible sera la TextBox,
la propriété cible sera la propriété Text de l’object Textbox, la valeur à exploité (le “path”) est la propriété source Nom de l’objet source Humain.

• La propriété de l’objet cible que nous voulons manipuler est un “Dependency Property”  traduction une propriété dépendante. Ceci afin de pouvoir lier cette propriété par databinding. Presque toutes les propriétés des éléments UI (textbox, listbox) sont des “Dependence Property” sauf les “Read-Only”. En effet, ces classes dérivent tous du DependencyObject class (voir ici et ici) qui permet de définir des DependencyProperty qui support le binding.
• L’objet source n’est seulement un object CLR personnalisé (un object comme que vous avez créé comme, par exemple, humain), cela pourrait être tout aussi bien, des objets qui proviennet d’ADO.NET, de webservice ou encore, d’un noeud XML qui contient des données.

A noter que pour créer ces liens (ce databind), vous utilisez des BindingOjbects, c’est grâce à ces objets que le lien peut se faire.

La direction du flux de donnée :

figure 2 (from MSDN)

En effet, le flux de données à un sens, comme l’on peut le voir dans la figure 2. Il y a un sens aux flèches. Le flux de donnée va d’un object source vers un objet cible. La propriété name du textbox pourrait être tout aussi bien être la cible que la source. Ce n’est plus la propriété text du TextBox qui se “remplit” de la proriété Nom de l’objet Humain mais c’est maintenant la propriété text du TextBox qui “remplit” la propriété Nom de l’objet Humain. Ceci implique donc trois sens pour les flux de données (noms donnés en anglais).

• One Way: la propriété cible change selon les données de la propriété source mais l’inverse n’est pas vrai. Ceci convient pour les contrôles de type Read-Only.
• Two Way: le flux de données se propagent dans les deux sens, la propriété est tantôt une propriété source, tantôt une propriété cible. Générallement, nous utiliserons Two Way pour les objets de type formulaire. Par exemple, la propriété Text du TextBox et la propriété IsChecked de l’objet CheckBox est par défaut Two Way.
• OneWayToSource: il est l’inverse de OneWay, il met à jour la propriété source lorsqu’il y a un changement dans la propriété cible.
• One Time (ne se trouve pas dans la figure 2): Initialise la propriété source mais les changements futures ne seront pas propagés. Ce type de “binding” (de lien) est utilisé si vous voulez prendre un instantané de l’état de votre couche métier. Il est plus ou moins équivalent au OneWay mais est plus performant, il est donc à utiliser lorsque les valeurs sont statiques.

Comment détecter des changements dans l’objet source (ceci uniquement pour OneWay et TwoWay) ?

L’objet doit implémenter un méchanisme de notification, en implémentant l’interface INotifyPropertyChange (nous verrons pourquoi plus tard).

Que déclenche un changement dans la source ?

Les databindings qui sont TwoWay et OneWayToSource doivent être attentif aux changements de la propriété cible afin de les propagers vers l’objet source. Le sens du flux de données est assuré par la propriété Mode de l’objet Binding.

Cependant, est-ce que la valeur de votre objet source (par exemple la propriété Nom de l’objet Humain) change t’elle lorsque vous être entrain de changer cette valeur (lors de la saisie dans le TextBox) ou après que vous ayez fini (de changer la valeur du TextBox) ?

En fait, c’est la propriété UpdateSourceTrigger qui détermine ce qui va déclencher la mise à jour de l’objet source.

figure 3 (from MSDN)

Si nous regardons la figure 3, les points représentés aux extrémités des flèches illustrent le rôle de l’UpdateSourceTrigger.

Si l’UpdateSourceTrigger à la valeur “PropertyChanged”, dès que la valeur dans le textbox changera, la valeur de l’object source changera également. Par contre, si l’UpdateSourceTrigger à comme valeur “LostFocus”, la valeur de l’objet source sera propagée lorsque nous nous retirerons du TextBox (passer à un autre textbox par ex.). La valeur par défaut de UpdateSourceTrigger dépend de l’objet. Pour un TextBox cette valeur est, par défaut, LostFocus. En effet, si nous devrions propager la valeur à chaque fois que nous entrons une lettre dans le textbox, les performances diminueraient, c’est pour cette raison que la valeur par défaut de UpdateSourceTrigger est LostFocus et non pas PorpertyChanged.

Il existe également pour le textbox une troisième valeur pour UpdateSourceTrigger, Explicit, utilisée par exemple pour mettre à jour la valeur seulement lors d’un clique de bouton par l’utilisateur (plus d’info sur l’UpdateSourceTrigger : ici ).

Créer un Binding :

Passons au pratique, nous allons établir un lien à l’aide de l’objet binding. Je ne vais pas vous le cacher, pour commencer je vais prendre un exemple MSDN.

Nous avons un object source qui est une classe MyData, elle a une propriété string ColorName dont la valeur est rouge. Nous voulons lier la couleur du background à la valeur ColorName de MyData.

Voici le code en XAML : pour plus d’info sur la syntaxt du binding (ici)

Et voici le code C# :

Ce binding est un binding OneWay en effet, la propriété background du TextBox est par défaut OneWay.

figure 4

Le background property de l’object textbox est de type brush, néanmoins nous lui passons un string, ceci fonctionne par une conversion implicite (plus d’info ici).

Spécifier le Binding Source :

Ici le binding source est défini spécifiant une valeur au DataContext. Le DataContext du Window1 est l’objet MyData. TextBoxt hérite de ce datacontext par l’objet Window1 (son parent). En donnant le chemin vers la propriété qui doit être lié dans le background du textblock. Celui-ci sera où prendre ces données. Si nous ne définissons aucune valeur pour le datacontext, le background du textbox ne prendrait pas la couleur rouge.

Nous obtenons alors le résultat suivant :

Il est intéressant de définir le datacontext dans un niveau parent lorsque vous voulez utilisez ce contexte pour plusieurs enfants. Dans le cas contraire, vous pouvez définir ce contexte rien que pour l’élément que vous voulez lier.

La Classe BindingExpression :

Comme défini plus haut, Binding class est la classe haut niveau pour définir un Binding. Le BindingExpression qui est une sous-jacente de l’objet Binding, cet objet permet de maintenir la connexion entre l’objet source et l’objet target. Un objet Binding contient toute l’information et peut être partagée par plusieurs BindingExpression. Une BindingExpression est une expression d’instance qui ne peut partager ses informations, elle contient toute l’information de l’instance du Binding.

myDataObject est une instance de la classe MyData, myBinding est la source de l’objet Binding, MyData est une classe qui contient la propriété string MyDataProperty. Cet exemple lie le contenu text d’une instance de TextBLock myText vers MyDataProperty.

Dans ce cas, vous pouvez réutiliser l’objet myBinding, par exemple, en liant à un propriété d’un TextBlock. A ce moment, il n’y aura qu’un objet Binding mais deux instances de BindingExpression qui se partage l’objet Binding.

DataConversion :

Dans l’exemple précédent, la propriété background du Texbox est lié à une propriété string avec la valeur « Red ». Cela fonctionne car le type Brush est capable de convertir un string en un objet Brush .

figure 5

Comme l’on peut remarquer sur la figure 5, le Type Brush à une conversion par défaut qui permet de convertir un objet de type string en objet de type Brush.

Que se passerait t’il si notre objet source avait un type Color pour la propriété ColorName. Nous devrions implémenter l’interface IValueConverter (pour plus d’info sur IValueConverter, cela se passe ici). De cette manière l’objet binding sait comment convertir un objet Color en objet de type SolidColorBrush.

Par l’implémentation de cette inferface, notre schéma devient alors :

figure 6

Généralement, pour les types cible connus, la conversion par défaut devrait fonctionner. En cas de doute, vous devriez implémenter l’interface IValueConverter.

Voici une liste de cas où l’utilisation de cette interface est préconisée :

• Vos données devront être affichées différement suivant la culture que vous utilisez. Vous pourriez implémenter un convertisseur de change et/ou un convertisseur de date utilisée par une certaine culture.
• La valeur qui est manipulée ne servira pas à changer la propriété Text du Textbox mais d’autres valeurs comme une source d’image, la couleur ou le style de text affiché. Les convertisseurs peuvent alors être utilisés en convertissant des propriétés qui ne semblerait pas lié entres-elles. Comme par exemple, lier la valeur d’un textbox à une couleur de fond pour une cellule d’un tableau.
• Plus d’un contrôle ou même plusieurs propriétés d’un contrôle peuvent être liées à une même source. Générallement, le “Binding” primaire affichera le texte et d’autres types de “Binding” posséderont certaines particularités sur la manière de relier les éléments entre eux, ceci tout en continuant à utiliser la même source d’information.
• Dans le cas où nous utiliserons des MultiBinding , dans ce cas un propriété cible sera lié à une collection de Binding. Dans le cas d’un multibinding vous utiliserez l’interface IMultiValueConverter afin de produire une valeur finale à partir des valeurs contenues dans votre collection de Binding.

Binding to Collection :

Dans un Binding, un objet source peut être soit traité comme un simple objet dans lequel ses propriétés contiennent des données soit comme une collection de données d’objets polymorphiques groupés ensembles (comme le résultat d’une query provenant d’une base de données). Ici nous avons toujours utilisés des objets simples mais nous aurions pu utiliser des ItemsControl comme des ListBox, des ListView, des TreeView afin d’afficher des collections d’objets.

figure 6

Comme l’on peut remarquer dans le diagramme précédent, pour lié un ItemsControl à une collection d’objet, nous devons utiliser la propriété ItemsSource. ItemsSource est en quelque sorte le contenu du ItemsControl. Par défaut la direction du flux de donnée pour un ItemsControl sera OneWay.

Comment implémenter les collections ?

Vous pouvez utiliser n’importe quelles collections qui utilisent l’interface IEnumerable. Pour gérer un binding qui permettrait l’insertion, la suppression ou l’update de donnée automatiquement retranscrite dans l’UI, la collection doit implémenter l’interface INotifyCollectionChange. Cette interface permet d’exposer un évênement qui sera déclenché à chaque changement dans la collection.

WPF founit la classe ObservableCollection(T) qui est une implémentation d’une collection de donnée qui comprend l’interface INotifyCollectionChange. A noter que pour supporter le transfert de données entre l’objet cible et l’objet source, chaque objet dans la collection doit implémenter l’interface INotifyPropertyChange.

Avant d’utiliser votre propre collection, tentez d’utiliser ObservableCollection(T) ou l’une des classes de collection existante comme List(T), Collection(T), BindingList(T), parmis d’autres.

Collection Views

Une fois que votre ItemsControl est lié à un collection de données, vous pourriez vouloir trier, filtrer ou grouper les données. Pour faire cela, vous utilisez les collection views, qui sont des classes qui implémente l’interface ICollectionView.

Que sont les Collection Views ?

Une collection est une couche supérrieur par rapport à une “binding source collection” ce qui vous permet de naviguer et d’afficher la collection source triée, flitrée et groupée en queries, ceci sans changer la source sous-jacente elle même. Une “collection view” maintient également un pointeur vers l’item courant dans la collection. Si la collection source implémente l’interface INotifyCollectionChange, les changements seront déclenchés par l’évênement CollectionChanged  qui sera propagé aux vues.

Parce ques les vues ne changent pas la collection source adjacente, chaque collection source peut avoir plusieurs vues associées à elle. Par exemple, vous pourriez avoir une collection d’objets Task. Avec l’utilisation de vues, vous pourriez afficher la même donnée sous différentes vues. Par exemple, à gauche vous afficheriez les Tasks triées par priorité et de l’autre triée par date.

Commen créer une vue ?

Une façon de créer et utiliser une vue est d’instancier les objets vues directement et les utiliser comme source pour le binding.

figure 7

figure8

Comme nous voyons dans l’exmple ci-dessus qui provient de MSDN, nous pouvons voir que le ListBox à pour Object source un CollectionViewSource lui-même lié à une liste d’objet AuctionItems . Vous pourriez réutililiser ce CollectionViewSource pour un autre type de contrôle, ce qui est important ici est de ne pas oublié de définir le x:Key dans la CollectionViewSource afin de que le contrôle puisse savoir où il va chercher ses données.

Le tableau suivant nous montre quels types de données (vue) sont crées comme CollectionView par défaut (IList -> ListCollectionView). Le résultat serait le même si nous utiliserions un CollectionViewSource afin de créer les CollectionViews.

Utiliser une Default View

Spécifier une collection view comme un “binding” source est une des solutions pour créer et utiliser des collection view. WPF crée également une default collection view pour chaque collection utilisée comme source du binding. Is vous liez directement un contrôle, WPF la lie à sa vue par défaut. Cette vue par défaut est partagée par tout les “bindings” de la même collection, donc un changement fait à la vue par défaut par un contrôle lié ou du code (trier, filtrer,…) est reflétée dans tous les autres bindings de la même collection.

Collection Views avec ADO.NET DataTables

En vue d’améliorer les performances, les collection views pour ADO.NET DataTable ou les DataView délèguent le tri, les filtres au DataView. En conséquent, le tri et le filtrage sera partagé à travers toutes les collections du datasource. Afin de mettre en place le tri et le filtrage sur chaque collection view, vous devez initialiser chaque collection view avec son propre DataView object.

Sorting

Comme mentioné ci-dessus, les vues peuvent trier un collection. Comme il existe dans la collection adjacente, vos données pourraient ne pas être dans un ordre pertinant. La vue au dessous de cette collection adjacente vous permet d’imposer un ordre et de changer l’ordre par défaut, basé sur des critères de comparaison que vous définissez. Parceque c’est un client-based view des données, un scénario commun pourrait être un utisateur qui veut trier les colonnes d’un tableau suivant ses valeurs correspondantes. En utilisant les vues, ce tri personnalisé pourrait être appliqué, et ce, sans faire de changement dans la collection de la couche adjacente et sans devoir faire de query dans cette couche adjacente (plus d’info ici).

Voici un exemple de tri qui trie par Catégorie et par StartDate :

Vous pouvez trouver un exmple de binding intéressant sur MSDN, ici.

Filtering :

Une vue peut également appliquer un filtre à une collection. Cela ne permet d’afficher qu’un sous-esemble d’une collection. Vous pouvez également trier sous des conditions personnalisées.

Voici un exemple de filtre qui provient de la démo fournie par MSDN.

The ShowOnlyBargainsFilter event handler

Grouping :

Exepté pour les classe internal qui sont retranscrite en IEnumerable collection, toutes les collections views supporte la fonctionnalité de grouping. Ceci permets aux utilisateurs de subdiviser la collection dans la collection view dans un groupe logique. Les groupes peuvent être explicite, l’utilisateur fournit une liste de groups ou implitcit, les groups sont générés dynamiquement dépendamment des données.

Voici un exemple de fonction de grouping :

Pointer sur l’item actuel:

Les vues supportent également la notion d’item actuel. Vous pourriez naviguer à travers les objets dans une collection view. Pendant que vous naviguer, vous passez d’un item à un autre et un pointeur d’item vous permet de retirer les informations de l’item actuel.

Comme WPF est lié à une collection uniquement en utilisant une vue, toutes les liaisons vers les collections possèdent ce pointeur d’item. Quand vous liez à une vue le caractère “/” désigne le chemin vers la valeur actuel. Dans l’exemple suivant, le data context est une collection view, le premier binding est lié à la collection, le second binding est lié à l’item actuel de la collection et le troisième est lié à la propriété Description de l’item actuel.

Ex :

Le Master Detail Binding Scenario

La notion d’item actuel est utile pour le Master Detail Binding Scenario. Si nous regardons dans l’exemple ci-dessous où le contenu du ListBox détermine le contenu affiché dans le ContentControl. Vous pouvez déterminer le Master Detail Binding scenario en liant deux ou plus contrôle à une même vue.

Ces deux contrôles sont liés à une même vue (listingDataView). Cette exemple marchera car lorsque un objet singleton (ici ContentControl) est lié à une collection view, il est automatiquement à l’item actuel (CurrentItem) de la vue. Si le list control n’est pas lié à un objet CollectionViewSource comme dans l’exemple, alors, vous devriez définir la propriété IsSynchronizedWithCurrentItem à “true” pour que cela fonctionne. L’exemple ci-dessous ne fonctionnerait pas si il n’utiliserait pas un template (voir prochain article).

DataTemplate :

Je reviendrai dans un prochaine sur l’utilisation de DataTemplate.

En attendant, voici une série de lien qui pourra vous être utiles :

http://msdn.microsoft.com/en-us/library/ms752347.aspx#specifying_the_binding_source

http://msdn.microsoft.com/en-us/library/ms752347.aspx#data_conversion

http://msdn.microsoft.com/en-us/library/ms752347.aspx#data_conversion

http://msdn.microsoft.com/en-us/library/dd458894.aspx

http://msdn.microsoft.com/en-us/magazine/cc163299.aspx

http://odetocode.com/articles/740.aspx

Routed Event :

Ce qui est difficile pour moi qui vient du monde ASP.NET, c’est le nombre de nouveaux concepts qu’il faut apprendre avant de maîtriser WPF. En effet, il y a plusieurs concepts nouveaux en WPF. Les dependency property (qui servent pour le databinding, le styling,…) mais également les RoutedEvents et les RoutedCommand. En effet, WPF n’utilise pas le système standard des événements mais une version plus puissante. Pour qu’un objet puisse avoir la possibilité de bénéficier de ces nouvelles fonctionnalités, il doit obligatoirement dérivée de la classe UIElement.

Généralement, vous utilisez les Routed Event sans vous en rendre compte. Par exemple, vous ajoutez un bouton dans un objet Windows, vous le nommez MyButton, vous double-cliquez sur ce bouton, il va créer tout ce qu’il vous faut pour que vous puissiez créer l’action que vous désirez déclencher lors de l’évènement click de l’élément bouton. Vous ne verrez alors aucune différence entre WPF et Winforms ou ASP.NET.

Prenons le bouton XAML :

 La déclaration en XAML pour se «  raccorder » à l’événement  est juste une propriété Click du contrôle Bouton. En fait, ce raccordement se trouve dans un « compile-time-generated » de la classe partiel de votre Windows (en gros le framework fait tout pour que ce soit transparent pour vous). Pour visualiser tous ces appels « automatiques », faites un clique droit sur la méthode InitializeComponent() de votre Window. Si vous descendez un peu vous verrez les lignes suivantes :

La classe partielle est générée à partir du XAML lors de la compilation et contient tous les éléments XAML qu’a besoin le « design-time compilator ».

Si nous regardons de plus près le code de cette classe partiel, le Click handler ressemble à ceci :

Ce qui ressemble fortement à ce que vous connaissez déjà dans le monde .NET. La seule chose différente est que vous n’utilisez plus EventArg comme type d’argument mais RoutedEventArgs.

Mais qu’y a-t-il de si différent ? Avant de vous expliquer cela, vous devez comprendre la composition des éléments du modèle WPF.

WPF, structure en Arbre :

Si vous démarrez un nouveau projet WPF, vous allez directement vous retrouver avec un code qui ressemble à ceci :

Chaque élément représente une Runtime instance correspondant à un type .NET, et nous remarquons la structure en arbre (logical tree) qui impose une hiérarchie entre les éléments. De plus, la plupart des éléments en WPF sont dit soit ContentControl ou ItemsControl .Ce qui veut dire qu’ils peuvent comprendre des éléments enfants.

Par exemple, un Bouton est un ContentControl , il peut avoir une hiérarchie complexe d’enfant en dessous de lui. Nous pourrions alors écrire ceci :

L’application ressemblerait alors à quelque chose du genre :

Comme vous en doutez, l’arborescence de cette structure peut devenir extrêmement complexe. Mais n’oubliez pas qu’en WPF tout ce que vous voyez n’est pas nécessairement ce que vous avez au Runtime.

Ci-dessous, l’arbre logique de notre bouton contenant un stackpanel  comprenant lui-même une image et un textblock.

Vous pouvez remarque que l’élément windows (EventsWindows) englobe son contenu dans un Border et un AdornerDecorator et présente le contenu à l’intérieur d’un ContentPresenter. Le bouton fait de même en englobant son contenu avec un objet ButtonChrome et présente son contenu dans un ContentPresenter.

Quand je clique sur le bouton, je pourrais ne pas cliquer du tout sur l’élément Bouton mais sur un de ses enfants dans l’arbre logique, peut-être même un qui n’est même pas dans cette structure en arbre (ButtonChrome). Par exemple, je clique avec ma souris sur le coin supérieur de l’image contenu dans le bouton. Cette action se manifeste comme un évènement MouseLeftButtonDown à l’intérieur de l’élément image ; mais nous voudrions que celui-ci soit transmis comme évènement click au niveau de l’élément bouton. C’est ici que rentre en jeux les RoutedEvents.

Les évènements routés :

Bien comprendre la structure en arbre des éléments dans WPF est primordial pour bien comprendre les routed events. En effet, les routed events sont routées par défaut sur cette structure en arbre. Ils supportent également les RoutingStrategy de type Bubble, Tunnel et Direct.

Bubble :

Bubble est le plus commun, l’évènement se propagera vers le haut de la structure à partir de l’élément source jusqu’à ce qu’il soit géré où qu’il ait atteint l’élément racine. Cela vous permet de gérer un évènement par un objet qui se trouve plus éloigné dans la structure que votre élément source. Par exemple, vous pourriez attacher un Button.Click handler sur l’élément Grid compris dans l’objet Button lui-même. Les évènements Bubble ont juste leur nom qui indique leur action (par exemple, MouseDown).

L’évènement Tunnel, lui, part de l’élément racine et traverse vers le bas les éléments de la structure jusqu’à ce qu’il soit pris en compte où qu’il atteigne l’élément source de l’évènement. Cela permet d’intercepter des évènements en amont et de le manipuler avant que celui-ci n’atteignent l’élément source. Les évènements Tunnel sont généralement nommés par le préfixe Preview par convention (PreviewMouseDown).

Les évènements Direct, eux, se comporte de la même manière que les évènements normaux dans le Framework .NET. Le seul handler possible pour ce type d’évènement est un delegate qui souscrit à cet évènement.

Généralement, pour chaque évènement Tunnel correspond un évènement Bubble. Dans ce cas, l’évènement Tunnel est déclenché en premier ; ils commencent de l’élément racine et descend vers l’élément source en cherchant un handler. Une fois qu’il a été intercepté ou a atteint l’élément source, le Bubble event correspondant est lancé. Partant de l’élément source et remontant vers le haut de la structure cherchant un handler.

A noter qu’un évènement Bubble ou Tunnel ne se stoppent pas parcequ’un EventHandler a été appelé. Si vous voulez stopper un évènement Bubble ou Tunnel, vous devez marquer l’évènement comme « handled » en utilisant l’argument évènement qui lui est passé.

Le fait que l’évènement stoppe lorsque celui-ci est marqué «handled » n’est pas totalement vrai. En réalité le processus continue en arrière scène et vous pourriez intercepter de nouveaux cet évènement en « overridant » UIElement.AddHandler method qui possède un flag permettant de continué la propagation de l’évènement, c’est-à-dire  « Appelle moi-même si l’évènement est marqué comme handled ».

Voici comment spécifier ce flag :

Le premier paramètre est le RoutedEvent que vous voulez manipuler, le second est une fonction delegate à la méthode qui manipulera l’évènement (qui devra posséder une signature correcte pour le delegate de cet évènement), le troisième paramètre indique si oui ou non vous voulez être notifié (même si un autre handler a marqué cet évènement comme « handled »). L’élément du quel vous appelez AddHandler est celui qui surveillera l’évènement pendant que celui-ci traverse la structure en arbre.

Routed Events et Composition :

Prenons comme exemple l’évènement Click du Bouton ci-dessus. Lorsque nous cliquons sur l’image qui se trouvent dans cet élément bouton. Comme mentionné ci-dessus, un utilisateur va initier un évènement Click avec un MouseLeftButtonDown event sur certain des éléments enfant dans cette structure en arbre de votre bouton (comme l’élément image dans notre cas du dessus).

Quand le MouseLeftButtonDown évènement se déclenche à partir de l’élément Image, l’évènement PreviewMouseLeftDown commence de l’élément root et se propage jusqu’à l’élément Image. Si personne n’a manipulé cet évènement et a marqué l’évènement comme « handled », un évènement MouseLeftDown  de type « bubble » sera propagé depuis l’élément image jusqu’à l’élément bouton. Le bouton manipule alors cet évènement, marque l’évènement comme handled et propage alors un évènement Click.

Attached Events :

Pour permettre à un élément de manipuler un évènement qui est déclaré dans un élément différent. WPF supporte les Attached Events. Attached Event sont des RoutedEvent qui supporte une déclaration d’un handler dans un autre type que celui où l’évènement est propagé. Par exemple, un élément Grid qui écouterait l’évènement Click de l’élément bouton.

Le code généré par la classe partiel compile-time

Plus d’information :

Si vous voulez créer vos propre RoutedEvent, je vous invite à lire cet article très intéressant sur les RoutedEvent : http://blogs.developpeur.org/raptorxp/archive/2007/07/18/wpf-comprendre-les-routed-events.aspx

En conclusion :

Vous savez maintenant ce qu’est un RoutedEvent, cette notion est une notion de base de l’environnement WPF et il était un pré requis à connaître avant de rentrer dans les détails du Composite Application Guidance. Si vous avez des questions, des suggestions et/ou des compléments d’information, n’hésitez-pas commenter cet article.

Bon voilà, après quelques années dans le monde de l’ASP.NET, j’ai envie de faire un tour du coté des applications clients de la plateforme .NET. Non pas que je sois blasé par cette technologie mais simplement la curiosité de découvrir un autre monde. Après avoir lu quelques tutoriaux, et vu quelques videos, programmé quelques applications du style Hello World, je me lance dans le vif du sujet. Je tenterai à la manière de Rob Connery d’apprendre et de vous faire apprendre de façon simultanée, ceci, en anglais plus connu sous le nom de “public learning”. J’attendrai donc des retours de votre part via commentaires ou mails (pierre at dervalp.com). Ne soyez pas surpris de trouver des mots non traduit, je ne tenterai pas de traduire certains mots. Je ne suis pas particulièrement un adepte du franglais mais certains mots dans le domaine informatique perdent de leur sens lorsqu’ils sont traduits (le language C# n’est-il lui-même pas écrit en anglais ?).

Revenons à nos moutons, c’est par l’intermédiaire d’une connaissance qui m’a présenté le pattern MVVM que je suis tombé sur une partie très intéressante sur MSDN, le “Composite Application Guidance for WPF and Silverlight” ou sous le nom plus connu de PRISM v2. Ce guide vous permettra de créer des applications qui sont voués à grandir et à supporter les assaults du temps par l’ajout de vue, l’ajout de modules,…

Avant de se lancer dans ce monstre qu’est PRISM v2, je vous invite à vérifier les spécifications systèmes (rien de bien effrayant là dedans) :

• Microsoft Visual Studio 2008 SP1
• Microsoft .NET Framework 3.5 SP1 (le .NET Framework 3.5 qui inclu WPF)
• Microsoft Silverlight (seulement pour les applications Silverlight)
• Microsoft Silverlight Tools for Visual Studio 2008 SP1 (seulement pour les applications Silverlight)

Pour plus d’info : http://msdn.microsoft.com/en-us/library/dd458809.aspx

Pourquoi utiliser Composite Application Guidance ? Selon Ms, il nous aidera à nous guider dans le but de créer des applications WPF et Silverlight complexes et  flexibles (cela tombe bien, c’est mon but). Des applications “loosely coupled” (cliquez-ici pour la traduction) et dont chaque module peut évoluer de manière indépendante (SoC). En gros, l’application presque parfaite…

Pré-requis :

Afin de bien comprendre tous les concepts présents, il vous faut des connaissances générales en WPF, en Silverlight mais aussi dans ces domaines:

• le databinding (en gros comment les éléments UI sont reliés aux données dans Silverlight et WPF)
•  les ressources (data template, control template, style,…)
• Routed Command (commande routée en français ou comment le client et les entrées de données sont connectées aux contrôles )
• Routed Events (pour permettre plusieurs “listeners” de recevoir et gérer les êvènements)
• Users Controls (composants qui permettent de créer des comportements ou des apparences customisées)
• Dependency Property
• XAML

Je vous rassure tout de suite, je vous expliquerai un à un ces points lors de différents articles (c’est cela le public learning, on rencontre un concept, on l’explique ).

Quand utiliser Composite Application Guidance ?

Une équipe de développement fait face toujours aux même problèmes au cours d’un projet, le changement de spécification, l’ajout de modules non prévus au départ, nouvelle technologie, mauvais feedback du client,… Tout cela, vous le connaissez aussi bien que moi n’est-ce pas ? C’est pour cela qu’il nous faut être agile ( ), c’est à dire être flexible et pouvoir améliorer son application en continu sans difficulté.  

Ce sont ces défis que Composite Application Guidance tente de relever, enfin rectification, ce sont les developpeurs à l’aide de Composite Application Guidance qui tenteront de relever ces différents défis. Ceci en divisant l’application en des parties peu couplés et semi-indépendantes qui pourront être développées et testées individuellement et ensuite regroupées ensemble dans une application “shell” (coquille en anglais) pour former une solution cohérente et performante. Que de beaux mots, en gros, pour les projets de grande envergures qui sont voués à évoluer au travers le temps.

Exemple d’une application composite (image provenant de MSDN):

Composite Application permet de développer, tester et déployer des modules de manière indépendante.

Il fournit également un « shell » commun composé de composant UI construit à partir de modules variés de manière peu couplée. Cela standardise l’apparence et permet d’ajouter des nouvelles fonctionnalités plus facilement.

Il permet la «separation of concerns» pour ce qui du logging et de l’authentification (capacité horizontal) mais également pour ce qui est des fonctionnalités business spécifique à vos applications (capacité vertical).

Il aide à la subdivision d’équipe en spécialisant les développeurs dans sa couche. Ceci permet de bien séparer l’application entre l’interface utilisateur et l’aspect business logic.

Quand ne pas utiliser Composite Application Guidance ?

 Le Composite Application Guidance est déconseillé pour les infrastructures telles que client/serveur, les communications assynchrones et les communications encryptées. Les applications où la performance est la priorité numéro une, les applications d’authenfication et d’authorisation. Il y certainement encore des cas où l’utilisation de Composite Application Guidance ne s’applique pas, nous verrons cela par la suite.

Conclusion :

J’espère vous avoir donné l’envie d’en connaître plus sur cette partie du monde du développement .NET. Je reviendrai très vite avec un prochain article qui vous expliquera les différents requis (databinding, routed command) afin d’être paré lors des explications plus techniques sur le fonctionnement de PRISM.