<navigation:Frame
     x:Name="MasterPageContentFrame"
     Style="{StaticResource ContentFrameStyle}">
      <navigation:Frame.UriMapper>
       <uriMapper:UriMapper>
         <uriMapper:UriMapping Uri="/{SubDirectory}/{pageName}" MappedUri="/Views/{SubDirectory}/{pageName}.xaml"/>
       </uriMapper:UriMapper>
      </navigation:Frame.UriMapper>
 </navigation:Frame>

Dans cet article je vous propose de mettre en place un système permettant de notifier l’utilisateur si il essaie de naviguer vers une autre page, alors que des modifications sont en cours.

Par modifications en cours il pourrait s’agir d’un changement non validé du model, ou d’un état non valide du ViewModel pour les personnes souhaitant mettre en place MVVM.

Notre service chargé de cette opération est composé de deux parties.

• La première, pièce essentielle du service sera représentée par une interface nommée ITracker
• La seconde, utilisée par ITracker sera nommée ITrackedPart.

Comme vous l’aurez compris en voyant les noms donnés, ITracker sera chargé d’effectuer le suivi des ITrackedPart et par conséquent indiquer si au moins une ITrackedPart contient une modification.

Regardons plus en détail ces éléments en commençant par l’interface ITracker.

public interface ITracker
    {
        List<ITrackedPart> TrakerStore { get; }
        void Register(ITrackedPart[] trackers);
        void UnRegister(ITrackedPart[] trackers);
        bool HasChanges { get; }
    }

public interface ITrackedPart
    {
        bool PartHasChanges { get; }
        bool IsChangeTrackingEnabled { get; }
        void MarkChangesAsHandled();
    }

• PartHasChanges indique si il y a des changements.
• IsChangeTrackingEnabled permet de faire savoir au ITracker si la surveillance est active sur cette part.
• Enfin la méthode MarkChangesAsHandled, permet de faire savoir à la part que les changements sont considérés comme ayant été validés.

Regardons maintenant comment implémenter ces deux interfaces:

Pour le Tracker voici une implémentation fonctionnant dans un environnement avec MEF:

    [Export(typeof(ITracker))]
    [PartCreationPolicy(CreationPolicy.Shared)]
    public class Tracker : ITracker, IDisposable
    {
        private List<ITrackedPart> trackerStore = null;

        public List<ITrackedPart> TrakerStore { get { return trackerStore; } }

        [ImportingConstructor]
        public Tracker()
        {
            trackerStore = new List<ITrackedPart>();
        }

        #region IPropertyChangeNotifier Members

        public void Register(ITrackedPart[] trackers)
        {
            if (trackers == null)
                throw new ArgumentNullException("trackers");

                foreach (ITrackedPart p in trackers)
                {
                    if (!trackerStore.Contains(p))
                        trackerStore.Add(p);
                }

        }

        public bool HasChanges
        {
            get
            {
                return trackerStore.Any(t => t.IsChangeTrackingEnabled && t.PartHasChanges);
            }
        }

        public void UnRegister(ITrackedPart[] trackers)
        {
            if (trackers == null)
                throw new ArgumentNullException("trackers");

                foreach (ITrackedPart p in trackers)
                {
                    if (trackerStore.Contains(p))
                        trackerStore.Remove(p);
                }
        }

        #endregion

        #region IDisposable Members

        public void Dispose()
        {
                trackerStore.Clear();
                trackerStore = null;
        }

        #endregion
    }

Mise à part les deux attributs spécifiques à MEF, indiquant que l’on fournit un export de type ITracker  et que ce dernier est de type singleton, le code est simple à comprendre.

Pour ITrackedPart la solution est un peu plus complexe, puisque vous pourriez décider de l’implémenter sur des composants différents.

Dans une application Silverlight utilisant les RIAServices on peut tout à fait imaginer que vous souhaitiez savoir si des modifications sont en cours sur un DomainContext. Alors certes vous pourriez dire qu’un DomainContext possède déjà un système permettant de savoir il y a des changements, mais en liant le DomainContext ou d’autres objets à ce service, vous pourrez savoir via un seul service si une modification est en cours.

Exemple d’implémentation sur un DomainContext:

[Export(typeof(MyDomainContext))]
[PartCreationPolicy(CreationPolicy.NonShared)]
    public partial class MyDomainContext : ITrackedPart
    {
        #region IChangesTracker Members

        public bool PartHasChanges
        {
            get { return this.HasChanges; }
        }

        public bool IsChangeTrackingEnabled
        {
            get { return true; }
        }

        public void MarkChangesAsHandled()
        {
            if (this.HasChanges)
                this.RejectChanges();
        }
        #endregion

    }

Pour une implémentation sur un ViewModel, j’ai décidé de créer un attribut servant à décorer les propriétés du ViewModel que l’on souhaite suivre.

[AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = false)]
    public class TrackedPropertyAttribute : Attribute
    {
    }

Pour l’utiliser ajoutez le de cette manière:

[TrackedProperty]
public MyType MyProperty

Il ne vous reste plus qu’à implémenter l’interface ITrackedPart sur votre ViewModel comme dans l’exemple suivant et à enregistrer le ViewModel via la propriété Register du Tracker.

public abstract class ViewModelBase:NotifyPropertyChangedBase,ITrackedPart
{
  [Import(typeof(ITracker), RequiredCreationPolicy = CreationPolicy.Shared)]
  public ITracker Tracker { get; set; }

  public ViewModelBase()
  {
         RegisterTracker(new ITrackedPart[] { this });
  }

  #region TrackChanges

   protected virtual void RegisterTracker(ITrackedPart[] trackers)
   {
      if (IsChangeTrackingEnabled)
      {
       if (trackers.Contains(this))
            PropertyChanged += new System.ComponentModel.PropertyChangedEventHandler(Tracker_PropertyChanged);
              Tracker.Register(trackers);
          }
      }

       protected virtual void UnRegisterTracker(ITrackedPart[] trackers)
      {
          if (trackers.Contains(this))
              PropertyChanged -= new System.ComponentModel.PropertyChangedEventHandler(Tracker_PropertyChanged);
          Tracker.UnRegister(trackers);
      }

      void Tracker_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
      {
          Type type = this.GetType();
          PropertyInfo pInfo = type.GetProperty(e.PropertyName);
          TrackedPropertyAttribute attr = pInfo.GetCustomAttributes(false).OfType<TrackedPropertyAttribute>().FirstOrDefault();
          if (attr != null)
              hasChanges = true;
      }

      #endregion

      #region IChangesTracker Members

      private bool hasChanges;

      public bool PartHasChanges
      {
          get
          {
              return hasChanges;
          }
      }

      public virtual bool IsChangeTrackingEnabled
      {
          get { return true; }
      }

      public void MarkChangesAsHandled()
      {
          hasChanges = false;
      }

      #endregion

  }

Que pouvons-nous dire sur ce bout de code.

La classe ViewModel hérite de NotifyPropertyChangedBase qui est une classe implémentant l’interface INotifyPropertyChanged.

Grâce à cette classe et juste avant d’enregistrer le viewModel dans le Tracker, nous allons nous abonner à l’event PropertyChanged. Ainsi, lorsqu’une propriété va être modifiée, nous allons juste vérifier si elle est décorée de l’attribut TrackedPropertyAttribute créé un peu plus haut dans ce billet. Si c’est le cas, on assigne simplement la valeur true à une variable de type bool nommée hasChanges pour dire qu’il y a eu une modification. Cette variable est ensuite utilisée par les membres de l’interface ITrackedPart pour indiquer l’état actuel.

Dernier point qu’il nous reste à voir, l’appel du service Tracker lors du changement de la page.

Pour faire simple dans cette démo, je me suis simplement abonné à l’évènement Navigating de la navigation frame de la page principale.

public void MasterPageContentFrame_Navigating(object sender, NavigatingCancelEventArgs e)
{
  if (Tracker != null && Tracker.HasChanges)
  {
      e.Cancel = true;
      NotifyChangesWindow w = new NotifyChangesWindow();
      w.Closed += (s, ev) =>
      {
        if (w.DialogResult.HasValue && w.DialogResult.Value)
        {
          Traker.Store.ForEach(p => p.MarkChangesAsHandled());
          NavigationService.Navigate(e.Uri.ToString());
        }
      };
      w.Show();
  }
}

Comme le laisse entendre le nom de l’event Navigating, la Navigation ne s’est pas encore passée, on fait donc appel au ITracker et à sa propriété HasChanges qui va nous retourner une réponse de type bool pour dire si des modifications sont en cours sur au moins un des éléments enregistrés dans le Tracker.

Avant toute chose on annule la navigation en cours. Ensuite on lance la fenêtre demandant à l’utilisateur si il souhaite continuer ou pas. Si il le souhaite on ferme la fenêtre de notification et on relance la navigation. Dans le cas contraire on ferme simplement la fenêtre de notification.

Voilà ce billet touche à sa fin. On pourrait très bien ajouter des fonctionnalités plus évoluées à ce service, mais pour cela je laisse faire votre imagination.

Dans ce billet je vous propose juste de mettre en place une méthode helper pour simplifier la récupération de cette description par le code.

Pour cela, commençons par créer une classe “static” que l’on nommera DescriptionHelper et dans laquelle nous allons également ajouter une méthode générique GetDescription prenant en paramètre une expression.

public static class DescriptionHelper
   {
       public static string GetDescription<T, U>(Expression<Func<T, U>> exp)
       {

       }
   }

Comme vous pouvez le constater cette méthode est générique et l’on vient de voir qu’elle prend en paramètre une expression. Pourquoi ?

Pour deux raisons:

• Premièrement nous allons pouvoir récupérer la description d’une propriété de n’importe quel objet quelque soit son type.
• Deuxième point, nous allons pouvoir indiquer la propriété à interroger via une expression lambda et non directement par une string. On évite ainsi toute erreur au runtime suite à une erreur de nommage.

Ajoutons  maintenant dans cette méthode le code permettant de récupérer le nom de la propriété.

if (exp == null)
   throw new ArgumentNullException("exp");

   var memberExpression = exp.Body as MemberExpression;

   if (memberExpression == null ||
       memberExpression.Member.MemberType != MemberTypes.Property)
   {
       throw new InvalidOperationException();
   }

   return typeof(T).GetPropertyDescription(memberExpression.Member.Name);

En travaillant avec les MemberExpression, vous pouvez voir comment il est relativement simple de récupérer le nom de la propriété indiquée via l’expression.

Pour enfin récupérer la description nous appelons la méthode GetPropertyDescription en lui passant le nom de la propriété à partir du type d’objet auquel la propriété appartient.

GetPropertyDescription est une petite méthode d’extension qui se base sur le type Type.

public static class TypeExtension
{
  public static string
    GetPropertyDescription(this Type type, string propertyName)
  {
   PropertyDescriptor desc =
         TypeDescriptor.GetProperties(type)[propertyName];
   DescriptionAttribute descriptionAttr =
        desc.Attributes.OfType<DescriptionAttribute>().FirstOrDefault();
   return descriptionAttr != null ? descriptionAttr.Description : null;
  }
 }

Comme nous avons le Type de l’objet et le nom de la propriété, nous pouvons récupérer le PropertyDescriptor via la méthode TypeDescriptor.GetProperties et donc accéder aux attributs appliqués à la propriété. Si il existe un attribut de type DescriptionAttribute,on récupère la valeur de la description sinon on retourne null.

Pour terminer ce billet, ajoutons un exemple.

Partons du principe que nous avons une entité InfoDemandeur avec une propriété Adresse. Pour récupérer la description liée à la propriété Adresse, il suffit d’insérer la ligne de code suivante:

string description =
     DescriptionHelper.GetDescription<InfoDemandeur, string>(i => i.Adresse);

Le chargement du contrôle est lié au thread de l’interface utilisateur et le temps que le contrôle n’est pas entièrement chargé l’utilisateur ne peut effectuer aucune autre action via l’interface. Une interface non utilisable, même quelques secondes peut être qualifiée comme un “plantage”, et il n’est pas rare de voir alors l’utilisateur essayer de cliquer plusieurs fois.

En WPF, lorsque l’application est démarrée, un thread dédié à l’UI est créé. Tout contrôle créé sur ce thread ne peut être utilisé sur un autre thread. C’est ce qu’on appelle l’affinité de thread.

Cette affinité est gérée par la classe Dispatcher. Il faut voir le dispatcher comme un ensemble de messages priorisés. Chaque message est alors exécuté selon la priorité qui lui est associée et impacte l’UI. Une instance de dispatcher est associée à un et un seul thread d’UI.

Si on revient au problème initial, à savoir que l’interface est bloquée pendant quelques secondes, j’aimerais afficher une animations pour indiquer à l’utilisateur qu’une opération est en cours.

D’après ce qu’on a vu, une solution est donc de créer un nouveau thread, auquel nous allons associé un nouveau Dispatcher.

Pour notre exemple on partira du principe que l’on a un contrôle nommé Loader qui se charge de l’animation pour faire patienter l’utilisateur.

Commençons par créer un nouveau thread.

Thread thread = new Thread(arg =>
                   {
                       loader = new Loader();
                       loader.Topmost = true;
                       loader.ShowInTaskbar = false;
                       loader.Show();

                       System.Windows.Threading.Dispatcher.Run();
                   });
        thread.SetApartmentState(ApartmentState.STA);
        thread.Start();

Première chose, vous noterez que l’on assigne à ce thread un ApartmentState STA, obligatoire pour fonctionner avec la plupart des composants graphiques. Ce comportement est plus inhérent à Windows qu’à WPF même. Je vous renvoie vers ce lien si vous souhaitez en savoir plus sur le sujet: http://msdn.microsoft.com/en-us/library/ms680112%28VS.85%29.aspx

Ensuite nous appelons la méthode start qui comme vous pouvez le constater va se charger de créer une nouvelle instance du Loader, de l’afficher par dessus toutes les autres fenêtres. Ce contrôle est une fenêtre et nous ne souhaitons pas l’afficher dans la barre des tâches.

La dernière ligne “System.Windows.Threading.Dispatcher.Run();” permet de démarrer un nouveau Dispatcher associé à ce thread pour effectuer tout nouveau traitement UI (animations…).

Une fois l’opération sous jacente terminée, il ne vous reste plus qu’à arrêter le dispatcher et le thread associé en appelant la méthode suivante:

loader.Dispatcher.InvokeShutdown();

Et voilà comment donner à l’utilisateur une sensation de fluidité de l’application

La solution que je vais présenter dans ce billet n’est en rien LA solution, mais une solution possible que j’utilise dans les projets sur lesquels je travaille.

Comme nous souhaitons afficher un message de confirmation, nous avons que deux résultats possibles.

• Oui je confirme l’action
• Ou non on annule l’action

A ce titre, notre Commande va prendre en paramètre un délégué de type Func<bool>.

Pour rappel, un délégué de ce type permet d’invoquer une méthode qui ne prend aucun paramètre en entrée, mais possède une valeur de retour de type bool.  Cette valeur de retour sera la réponse suite à l’action de l’utilisateur sur la message box.

Dans la méthode appelée suite à l’exécution de la commande, la seule chose que nous avons à faire est d’invoquer le délégué dans une clause IF afin de savoir si l’on doit continuer ou non.

public ICommand DeletePictureCommand
       {
           get
           {
               if (deletePictureCommand == null)
                   deletePictureCommand =
                       new DelegateCommand<Func<bool>>(DeletePicture,  (param)  => true);
               return deletePictureCommand;
           }
       }

       private void DeletePicture(Func<bool> confirmDeletion)
       {

           if (confirmDeletion())
           {

           }
       }

Côté vue, nous allons créer une petite classe Helper nous permettant:

• d’indiquer le message à afficher dans la message box.
• d’instancier et afficher la message box.

Pour cela, commencez par créer une propriété attachée de type string que nous allons nommer ConfirmationMessage.

public static string GetConfirmationMessage(DependencyObject obj)
        {
            return (string)obj.GetValue(ConfirmationMessageProperty);
        }

        public static void SetConfirmationMessage(DependencyObject obj, string value)
        {
            obj.SetValue(ConfirmationMessageProperty, value);
        }

        public static readonly DependencyProperty ConfirmationMessageProperty =
            DependencyProperty.RegisterAttached("ConfirmationMessage", typeof(string), typeof(CommandConfirmationHelper),
            new UIPropertyMetadata(null, new PropertyChangedCallback(OnConfirmationMessageChanged)));

Puis, ajoutez une méthode pour le PropertyChangedCallback dans laquelle nous allons récupérer la commande que l’on souhaite lier à la message box et à laquelle nous allons passer au CommandParameter un délégué de type Func<bool>, qui comme vous pouvez le voir ci-dessous ne fait que retourner le résultat lié à l’appel de la méthode MessageBox.Show. MessageBox de type “YesNo”

private static void OnConfirmationMessageChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
        {
            if (e.NewValue != null)
            {
                ICommandSource commandSource = d as ICommandSource;
                string message = e.NewValue.ToString();
                if (commandSource != null)
                {
                    Func<bool> del =
                        () => { return MessageBox.Show(message, "Titre", MessageBoxButton.YesNo) == MessageBoxResult.Yes; };
                    Type type = d.GetType();
                    PropertyInfo pinfo = type.GetProperty("CommandParameter");
                    pinfo.SetValue(d, del, null);
                }
            }
        }

La dernière chose qu’il nous reste à faire est de mettre à jour le code xaml en y ajoutant une référence à la propriété attachée sur l’élément possédant la commande à exécuter,:

<ListView.InputBindings>
     <KeyBinding Key="Delete"                            uihelper:CommandConfirmationHelper.ConfirmationMessage="Etes-vous sûr de vouloir supprimer la photo ?"
  Command="{Binding DeletePictureCommand}"  />
</ListView.InputBindings>

Et voilà rien de bien compliqué, mais plutôt pratique et simple à mettre en place.

Prenons un exemple.

Deux applications disponibles de la manière suivante:

• Application 1: http://mondomain.com/App1
• Application 2: http://mondomain.com/App2

Chacune des applications se trouvant aux Urls ci-dessus ont un espace de stockage dédié à l’application. Il est possible d’y ajouter ou modifier des éléments à partir d’ApplicationSettings.

IsolatedStorageSettings.ApplicationSettings.Add("key", "value");

Maintenant pour avoir un espace partagé entre les applications xap des sites App1 et App2, il vous suffit simplement d’accéder à l’IsolatedStorage via SiteSettings se trouvant également dans IsolatedStorageSettings.

IsolatedStorageSettings.SiteSettings.Add("key", "value");

Rien de bien compliqué, mais plutôt pratique !!

La méthode que nous venons de voir correspond à un raccourci pour obtenir le contenu des différents stores. Pour une plus grande souplesse vous pouvez accéder à ces stores via les méthodes

IsolatedStorageFile.GetUserStoreForApplication();
IsolatedStorageFile.GetUserStoreForSite();

A partir de là, vous pourrez par exemple créer une arborescence, connaitre l’espace utilisé et restant, agrandir l’espace courant pour stoker un nombre de données plus important…

Besoin:

Dans cette application, nous avons un service d’authentification qui selon certains critères peut choisir tel ou tel module pour authentifier l’utilisateur. La résolution du module en question est faite via MEF. Ce module peut avoir besoin de paramètres comme par exemple l’url d’un Web Service et l’environnement sur lequel on souhaite réaliser cette opération.

Plutôt que de toujours faire appel à ConfigurationManager.AppSettings[key] dans le module lui-même je souhaitais trouver un moyen d’injecter ces valeurs. Ceci est notamment possible avec MEF, c’est ce que nous allons voir tout de suite.

Si vous avez déjà utilisé MEF, vous savez que ce Framework fonctionne avec les attributs Export et Import. Chaque ComposablePart exporte et importe des services vers ou provenant d’autres ComposableParts. Dans le cas de AppSettings, il faut voir une paire de Key/Value comme une ComposablePart qui va nous permettre de créer une part(la valeur) à partir d’un contrat la key.

Généralement, les parts sont reliées entre elles via des contrats de type interface ou classe de base, permettant de faciliter le découplage du code. Si aucun contrat n’est spécifié, MEF va se baser sur le type du service Exporté ou Importé.

Prenons pour exemple la classe suivante:

Ajoutez une classe nommée “MainPart”, contenant deux propriétés, P1 et P2. Pour indiquer que MainPart est une Part, ajoutez lui un attribut Export, puis ajoutez un attribut Import sur chacune des propriétés pour dire qu’on attend que MEF fasse également la résolution de ces deux propriétés / part pour utiliser la classe MainPart.

   [Export]
   public class MainPart
   {
       [Import("AppSettingsKey")]
       public string P1 { get; set; }

       [Import("AppSettingsKey2")]
       public string P2 { get; set; }
   }

Dans le code ci-dessus, vous pouvez voir que pour l’export, nous n’avons rien spécifié, le contrat sera donc le nom complet de MainPart: namespace + nom de la classe. Pour P1 et P2, nous ajoutons manuellement un contrat sous forme de string. Le conteneur s’appuiera sur ces valeurs “AppSettingsKey” et “AppSettingsKey2” pour récupérer la valeur.

Voyons maintenant un peu plus en détail comment créer notre catalogue personnalisé

Première étape à réaliser, la création du catalogue que nous nommerons AppSettingsCatalog.

AppSettingsCatalog doit hériter de ComposablePartCatalog. Le but du catalogue est de fournir une “vue” au conteneur MEF, des différents Export disponibles. Le catalogue ne créé par les parts, il ne fait que fournir une définition des parts au travers de la méthode Parts de type IQueryable<ComposablePartDefinition>.

public class AppSettingsCatalog : ComposablePartCatalog
   {
       public override IQueryable<ComposablePartDefinition> Parts
       {
           get
           {
               return (from k in ConfigurationManager.AppSettings.AllKeys
                       select (ComposablePartDefinition)
                           new AppSettingsPartDefinition { Key = k })
                      .AsQueryable<ComposablePartDefinition>();
           }
       }
   }

Dans le code ci-dessus, on voit par exemple que la méthode Parts donne des AppSettingsPartDefinition à laquelle on passe à chaque fois une clé de AppSettings.

Comme vous l’aurez deviné, la deuxième étape est donc de construire la classe AppSettingPartDefinition. A nouveau cette classe hérite d’une classe parente nommée ComposablePartDefinition.

Le but de cette classe est double: créer une ComposablePart qui se chargera de créer la Part et fournir une description de l’ensemble des contrats que la part peut donner ou utiliser. Il faut voir cet élément un peu comme un élément descriptif / un type au sens Type.

public class AppSettingsPartDefinition : ComposablePartDefinition
{

    private string key;

    public AppSettingsPartDefinition()
    { }

    public string Key
    {

        get { return this.key; }
        set { this.key = value; }

    }

    public override ComposablePart CreatePart()
    {
        return new AppSettingsComposablePart(this);
    }

    public override IEnumerable<ExportDefinition> ExportDefinitions
    {
        get
        {
            var metadata = new Dictionary<string, object>();
            metadata.Add("ExportTypeIdentity", typeof(string).FullName);
            return new[]
                {
                   new ExportDefinition(this.key, metadata)
                };
        }
    }

    public override .IEnumerable<ImportDefinition> ImportDefinitions
    {
        get
        {
            return new ImportDefinition[0];
        }
    }
}

On peut voir que la ComposablePart est créée via la méthode CreatePart. ExportDefinitions et ImportDefinitions liste les différents contrats de la Part. On notera également, que pour chaque key on créé un Export avec un contrat dont le nom est représenté par la key.

Dernier élément qu’il nous reste à voir la classe AppSettingsComposablePart. C’est cette classe qui sera chargée d’instancier l’export et de fournir le résultat via la méthode GetExportedValue.

public override object GetExportedValue(ExportDefinition definition)
{
            return ConfigurationManager.AppSettings[definition.ContractName];
}

ExportDefinition contient notamment l’information sur le nom du contrat. Il nous reste alors plus qu’à passer ce nom de contrat à la propriété AppSettings du ConfigurationManager pour récupérer le résultat. Dans notre exemple la méthode GetExportedValue ne sera appelée qu’une seule fois pour chaque Part, la part ne contenant pas elle même d’autres exports.

Enfin il ne vous reste plus qu’à configurer le conteneur MEF pour utiliser ce nouveau  catalogue et faire la résolution de l’élément MainPart.

Fichier de configuration:

  <appSettings>
    <add key="AppSettingsKey" value="AppSettingValue"/>
    <add key="AppSettingsKey2" value="AppSettingValue2"/>
  </appSettings>

Configuration du conteneur:

var confCatalog = new AppSettingsCatalog();
var typeCatalog = new TypeCatalog(typeof(MainPart));
var aggCatalog = new AggregateCatalog(confCatalog, typeCatalog);
var container = new CompositionContainer(aggCatalog);

Résolution de MainPart:

var exportedPart = container.GetExport<MainPart>().Value;

Le code de démonstration est disponible ici.

Pré-requis de l’application:

• Utilisation de MEF, pour faire la résolution des ViewModels et de leurs services.
• Lorsque l’on navigue sur une nouvelle page, celle-ci doit être dans le même état que lors du premier accès.

Afin de respecter ces deux points, nous avons commencé par créer un CompositionContainer MEF avec un DeployementCatalog pour la découverte des différentes Parts. Le catalogue contient donc toutes les parts du xap courant, peu importe la policy: Shared et NonShared.

Cas de Silverlight 3:

Tests effectués avec la version de MEF (preview 9) présente sur codeplex.

Silverlight 3 intègre un système de navigation par page. Mais dans cette version, nous ne pouvons pas intervenir sur la création d’une page. Chaque page est donc créée par le PageResourceContentLoader. Pour faire la résolution du ViewModel, disponible sur chaque page au travers d’un Import, nous devons pouvoir accéder au conteneur directement depuis la page. Pour cela, j’ai créé une classe App qui est une classe statique. Elle contient une propriété également statique et de type Composition Container qui permet de créer le conteneur principal si il n’existe pas encore puis de le retourner.

App.Container.SatisfyImportsOnce(this)

A chaque changement de page, une nouvelle page est instanciée et le temps que la méthode SatisfyImportsOnce n’est pas appelée, le ViewModel est null. Pour remplir la seconde condition donnée plus haut dans les pré-requis, nous avons fait le choix de demander à MEF de nous donner une nouvelle instance à chaque fois. L’export d’un ViewModel est assigné à NonShared pour la CreationPolicy. Pour rappel lorsque l’on associe une policy NonShared à un export, une instance différente sera donnée pour chaque Import. (Attention, pour avoir toujours une instance différente sur un import d’une même instance, regardez du côté d’ExportFactory). Comme dans notre cas, une nouvelle page est créée à chaque fois, il n’y aura pas de problème une nouvelle instance sera utilisée pour la propriété ViewModel.

D’après la documentation, le conteneur MEF ne tient pas de référence entre une part NonShared et le conteneur chargé de sa création. Cependant après une navigation continue dans l’application, j’ai pu constater que la mémoire montait. Avec l’aide d’un profiler, on se rend compte que les différentes instances de ViewModel créées continuent d’éxister, malgré le fait qu’elles ne soient plus référencées par d’autres objets, du moins cela devrait être le cas. Sauf qu’en y regardant d’un peu plus près, le profiler nous indique clairement, qu’il y a une référence du conteneur et plus précisément de ReflectionComposablePart sur chaque ViewModel. Ils ne peuvent donc pas être pris par le Garbage Collector.

Après quelques recherches supplémentaires, il semblerait qu’il y ait un bug avec cette version.

Pour le contourner et ne pas provoquer de problème mémoire, voici une solution possible:

La création d’un conteneur enfant. L’idée est d’avoir un conteneur MEF global à l’application et pouvant faire la résolution de toutes les parts, qu’il s’agisse d’un Export type NonShared ou Shared. Pour une requête vers une page, on créé un conteneur enfant qui prend un catalogue filtré avec seulement les Parts ayant une policy NonShared. C’est ce conteneur qui fera la résolution du ViewModel.

Lors du changement de page, il suffit de faire un dispose du conteneur enfant. Toutes les parts créées par ce contenur seront alors supprimées. Si un ViewModel implémente l’interface IDisposable, la méthode Dispose sera également appelée.

CompositionContainer rootContainer = App.Container as CompositionContainer;
FilteredCatalog cat = new FilteredCatalog(rootContainer.Catalog,
p =>
 p.Metadata.ContainsKey(CompositionConstants.PartCreationPolicyMetadataName)
  &&
   ((CreationPolicy)p.Metadata[CompositionConstants
      .PartCreationPolicyMetadataName])  == CreationPolicy.NonShared);
child = new CompositionContainer(cat, rootContainer);
child.SatisfyImportsOnce(this);

Cas de Silverlight 4:

Pour effectuer le test avec Silverlight 4, j’ai simplement changé la version utilisée par mes applications et librairies Silverlight en les passant à la version 4, puis j’ai supprimé les références pointant vers les dll du MEF de codeplex pour ajouter celles qui sont natives au framework 4. Vous pouvez également supprimer le conteneur enfant.

Pour que le test soit similaire à celui effectué avec la version 3, j’accède toujours au conteneur depuis la page pour faire la résolution du ViewModel, mais sachez que vous avez la possibilité d’instancier la page via MEF en créant votre propre ContentLoader. Le ViewModel serait alors automatiquement résolu.

Notez qu’à chaque changement de page nous appelons également GC.Collect pour forcer le garbage collector à collecter les objets si ils sont disponibles.

Il suffit ensuite de regarder le profiler pour voir que les parts sont bien supprimées.

Résultat du profiler lors de la navigation vers la homepage:

Résultat du profiler lors de la navigation de homepage vers une autre page sans ViewModel associé:

On peut constater que les instances ne sont plus présentes.

Remarque:

1- Si vous d

écidez de passer votre ViewModel avec une CreationPolicy à Shared, il y aura un lien fort entre le conteneur et l’instance du ViewModel. Ce dernier ne sera détruit que lorsque le conteneur sera également détruit.

2- Si votre ViewModel utilise des ressources non managées et que vous implémentez la l’interface IDisposable, le conteneur MEF gardera également une référence vers l’instance. Pour la détruire avant que le conteneur ne soit détruit, vous pouvez par exemple utiliser la méthode ReleaseExport du conteneur.

Ce que je vous propose dans ce billet c’est donc d’en développer un simple.

A quoi doit-il ressembler ?

Graphiquement, il sera composé de quatre parties:

• une partie header pour afficher une description de la partie en question.
• un bouton au niveau du header pour activer l’animation permettant de masquer ou afficher le contenu.
• une partie dans laquelle se trouvera le  contenu à masquer ou à afficher.
• Et un séparateur entre le header et le contenu à afficher.

Allez démarrons…

Ouvrez votre Visual Studio et ajoutez un nouvel item basé sur le type "Silverlight Templated  Control". Vous devriez maintenant avoir un fichier cs et un dossier Themes contenant un fichier generic.xaml

Commençons par éditer le generic.xaml pour définir le style de notre contrôle et en particulier la propriété Template.

• Pour le header ajoutons un simple TextBlock. Pas besoin de faire bien compliqué un simple texte décrivant le contenu suffira.
• Pour le séparateur, mettons un rectangle, nous y associerons ensuite un Style pour indiquer la couleur, la hauteur…
• Pour le bouton chargé de l’animation pour masquer le contenu, utilisons un ToggleButton. Nous verrons un peu plus loin pourquoi j’ai fais ce choix.
• Enfin pour que l’utilisateur utilisant ce contrôle puisse définir le contenu sur lequel agir, ajoutons un ContentPresenter.

 <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:Expander">
                    <Grid>
                        <Grid >
                            <Grid.RowDefinitions>
                                <RowDefinition />
                                <RowDefinition Height="2" />
                                <RowDefinition x:Name="row"  Height="*" />
                            </Grid.RowDefinitions>
                            <TextBlock Text="{TemplateBinding HeaderText}"/>
                            <Rectangle
                                 HorizontalAlignment="Stretch"
                                Grid.Row="1"
                                x:Name="Hr"
                                VerticalAlignment="Top"
                                />
                            <Grid Grid.Row="2"
                                x:Name="ContentGrid"
                                HorizontalAlignment="Stretch"
                                RenderTransformOrigin="0.5,0.0">
                                <Grid.RenderTransform>
                                    <TransformGroup>
                                        <ScaleTransform ScaleY="1"/>
                                    </TransformGroup>
                                </Grid.RenderTransform>
                                <ContentPresenter Margin="0,20,0,0"/>
                            </Grid>
                        </Grid>
                        <ToggleButton
                            Grid.RowSpan="2"
                            IsThreeState="False"
                            x:Name="ToggleButton_Part"
                            Cursor="Hand"
                            Grid.Row="1"
                            VerticalAlignment="Top"
                            Margin="0,0,-25,0"
                            HorizontalAlignment="Right"
                            />
                    </Grid>
                </ControlTemplate>
            </Setter.Value>
        </Setter>

Comme vous l’aurez compris en voyant le ContentPresenter, notre contrôle expander hérite de ContentControl.

Maintenant, ouvrez le fichier cs, nous allons y ajouter quelques propriétés de type DependencyProperty et méthodes pour modifier son comportement de base.

La première propriété sera IsOpen de type boolean. Sa valeur par défaut sera à true, pour indiquer que lors du premier affichage le contenu doit être visible. Lors de la création d’une DependencyProperty, on a également la possibilité d’ajouter un callback, afin que lors du changement de la valeur on puisse effectuer une opération supplémentaire. Dans notre cas nous allons simplement appeler la méthode GoToState du VisualStateManager.  Cette méthode prend notamment en paramètre le nom du nouvel état visuel dans lequel le contrôle doit se trouver.

public bool IsOpen
{
  get { return (bool)GetValue(IsOpenProperty); }
  set { SetValue(IsOpenProperty, value); }
}

public static readonly DependencyProperty IsOpenProperty =
    DependencyProperty.Register(
    "IsOpen",
    typeof(bool),
    typeof(Expander),
    new PropertyMetadata(true,
    new PropertyChangedCallback(IsOpenChangedCallback)));

static void IsOpenChangedCallback(DependencyObject d,
      DependencyPropertyChangedEventArgs e)
{
  Expander exp = d as Expander;
  if (exp != null)
       exp.IsOpenChanged(e);
}

public virtual void IsOpenChanged(DependencyPropertyChangedEventArgs e)
{
   if (IsOpen)
       VisualStateManager.GoToState(this, Expander.ExpandedState, false);
    else
       VisualStateManager.GoToState(this, Expander.CollapsedState, false);
}

ExpandedState et CollpasedState sont deux constantes de type string contenant le nom de l’état que nous allons déclarer dans le generic.xaml.

private const string ExpandedState = "Expanded";
private const string CollapsedState = "Collapsed";

Avant d’ajouter de nouvelles propriétés, modifions le generic.xaml pour ajouter les VisualStates correspondant à ExpandedState et CollpasedState. Un VisualState c’est ni plus ni moins qu’une Storyboard permettant de définir une animation sur notre contrôle.

<VisualStateManager.VisualStateGroups>
  <VisualStateGroup x:Name="OpenStates">
    <VisualState x:Name="Expanded">
      <Storyboard>
         <DoubleAnimation Storyboard.TargetName="ContentGrid"
            Storyboard.TargetProperty="(UIElement.RenderTransform)
                   .(TransformGroup.Children)[0].(ScaleTransform.ScaleY)"
            To="1" Duration="0:0:0.3">
              <DoubleAnimation.EasingFunction>
                  <ExponentialEase EasingMode="EaseOut"
                      Exponent="4" />
              </DoubleAnimation.EasingFunction>
          </DoubleAnimation>
      </Storyboard>
  </VisualState>
  <VisualState x:Name="Collapsed">
      <Storyboard>
        <DoubleAnimation Storyboard.TargetName="ContentGrid"
           Storyboard.TargetProperty="(UIElement.RenderTransform)
             .(TransformGroup.Children)[0].(ScaleTransform.ScaleY)"
           To="0" Duration="0:0:0.3">
        </DoubleAnimation>
        <ObjectAnimationUsingKeyFrames
               BeginTime="0:0:0.3"
               Duration="0"
               Storyboard.TargetName="row"
               Storyboard.TargetProperty="Height">
               <DiscreteObjectKeyFrame KeyTime="0" Value="0"/>
        </ObjectAnimationUsingKeyFrames>
     </Storyboard>
  </VisualState>
 </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

Reprenons les deux VisualStates:

• Dans Expanded, notre storyboard agit sur le contrôle avec le name ContentGrid. Comme son nom l’indique il s’agit du conteneur dans lequel se trouve le ContentPresenter. Nous passons à 1 sa propriété ScaleTransform.ScaleY. Si vous regardez dans le code xaml ajouté plus haut, vous aurez certainement observé qu’on avait initialisé le grid avec une transformation. La valeur était à 1. Ici nous remettons l’élément à la même échelle qu’au départ.

<Grid Grid.Row="2"
   x:Name="ContentGrid"
   HorizontalAlignment="Stretch"
   RenderTransformOrigin="0.5,0.0">
   <Grid.RenderTransform>
     <TransformGroup>
          <ScaleTransform ScaleY="1"/>
     </TransformGroup>
   </Grid.RenderTransform>
   <ContentPresenter Margin="0,20,0,0"/>
</Grid>

• Au même titre dans le VisualState Collapsed, nous avons une storyboard pour assigner la valeur 0 à la propriété ScaleY.

Sauf que cette fois ci, nous avons également une seconde storyboard qui va nous permettre de réduire la hauteur de la ligne contenant le ContentPresenter jusqu’à une hauteur de 0.

A la vue de ces deux animations, on est en droit de se demander, pourquoi je n’ai pas jouer directement sur la hauteur de la row. Les Row qui sont des éléments de RowDefinition ont une propriété Height, mais dans ce cas précis, le type de la propriété est un GridLength. La DoubleAnimation est donc incompatible et le seul le moyen que je vois serait de créer une animation personnalisée juste pour traiter les hauteurs et largeurs de Grid.

Un peu plus haut dans ce billet, nous avions dit que nous placerions un élément au niveau du header pour masquer / afficher le contenu et que cet élément était un ToggleButton. Un ToggleButton possède plusieurs états dont Checked et Unchecked. Au même titre que ce que nous venons de faire, nous pouvons redéfinir les VisualStates correspondants de manière à pouvoir animer ce ToggleButton. Pour y parvenir, redéfinissons son Template.

  <ControlTemplate TargetType="ToggleButton">
     <Grid>
       <Path x:Name="arrow" Stroke="#000"
                 StrokeThickness="2"
                 Height="Auto"
                 HorizontalAlignment="Center"
                 Margin="0,10,30,0"
                 VerticalAlignment="Center"
                 Width="Auto"
                 RenderTransformOrigin="0.5,0.5"
                 Data="M 1,1.5 L 4.5,5 L 8,1.5">
                <Path.RenderTransform>
                  <TransformGroup>
                    <ScaleTransform/>
                    <SkewTransform/>
                    <RotateTransform CenterX="0.5" CenterY="0.5"
                                Angle="0"/>
                    <TranslateTransform/>
                   </TransformGroup>
                  </Path.RenderTransform>
                 </Path>
       </Grid>
  </ControlTemplate>

Nous avons un objet Path qui a été créé avec Blend et auquel nous appliquons une transformation de type RotateTransform. Le centre de rotation correspond au centre de l’objet Path. Visuellement on obtient une petite flèche comme celle-ci.

Maintenant nous pouvons ajouter, les deux VisualStates:

• Checked

 <VisualState x:Name="Checked">
   <Storyboard>
       <DoubleAnimation Storyboard.TargetName="arrow"
            Storyboard.TargetProperty="(UIElement.RenderTransform)
                     .(TransformGroup.Children)[2].(RotateTransform.Angle)"
            To="0" Duration="0:0:0.3"/>
   </Storyboard>
</VisualState>

• Unchecked

 <VisualState x:Name="Unchecked">
   <Storyboard>
       <DoubleAnimation Storyboard.TargetName="arrow"
          Storyboard.TargetProperty="(UIElement.RenderTransform)
           .(TransformGroup.Children)[2].(RotateTransform.Angle)"
          To="180" Duration="0:0:0.3"/>
   </Storyboard>
</VisualState>

Quand le ToggleButton est dans un état Unchecked, nous réalisons une rotation de 180°. L’état initial étant un angle de 0, nous pourrions ne pas mettre de storyboard dans le VisualState Checked, l’élément reviendrait tout seul à sa position initiale car deux VisualStates d’un même VisualStateGroup ne peuvent être appliqués en même temps. Cependant elle est présente afin que cette opération se fasse sur une durée donnée.

Si nous devions arrêter le développement de notre contrôle à ce stade, il serait totalement exploitable.

Dans le code joint à ce billet, vous pourrez également trouver quelques propriétés supplémentaires permettant de simplifier sa personnalisation:

• HeaderStyle appliquée à la propriété Style du TextBlock
• ToggleButtonStyle appliquée à la propriété Style du ToggleButton
• SeparatorStyle appliquée à la propriété Style du Rectangle servant de séparateur entre le header et la contenu.
• SeparatorVisibility appliquée à la propriété Visibility du rectangle.

Dans le generic.xaml, nous nous sommes appuyés sur ces propriétés pour fournir des styles par défaut à notre contrôle.

Maintenant, vous pouvez soit redéfinir  un / chacun de ces styles, ou bien modifier complètement son template.

Pour l’utiliser, ajoutez une référence vers l’assembly du contrôle, et insérez le code suivant

<Grid x:Name="LayoutRoot" Background="White">
        <StackPanel>
            <local:Expander
            VerticalAlignment="Top"
            HeaderText="Header" Background="LightSkyBlue" >
                <local:Expander.Content>
                    <StackPanel>
                        <TextBlock Text="Content" />
                        <Rectangle Width="150" Height="150" Fill="Black"/>
                    </StackPanel>
                </local:Expander.Content>
            </local:Expander>
            <local:Expander
            VerticalAlignment="Top"
            HeaderText="Header" Background="LightSkyBlue" >
                <local:Expander.Content>
                    <StackPanel>
                        <TextBlock Text="Content" />
                        <Rectangle Width="150" Height="150" Fill="Black"/>
                    </StackPanel>
                </local:Expander.Content>
            </local:Expander>
        </StackPanel>
    </Grid>

Démo

Télécharger le code

Regardons d’un peu plus près de quelles propriétés / méthodes est constituée cette interface.

public interface ICommand
{
   event EventHandler CanExecuteChanged;
   bool CanExecute(object parameter);
   void Execute(object parameter);
}

• CanExecute permet de dire si la commande peut être exécutée.
• Execute comme son nom l’indique exécute la commande
• CanExecuteChanged est un event que l’on va utiliser pour déclencher l’appel de la méthode CanExecute et changer notamment l’état de la source liée à la commande. Il peut s’agir par exemple d’un bouton et de son état IsEnabled.

Avant d’allez plus loin, créons un petit projet pour continuer ce billet.

Ouvrez votre visual studio et créez une application silverlight v4. Puis ajoutez-y une classe User avec deux propriétés LastName,FirstName et implémentez l’interface INotifyPropertyChanged pour notifier tout changement de valeur d’une des propriétés.

public class User : EntityBase
   {
       private string lastName;
       public string LastName
       {
           get { return lastName; }
           set
           {
               if (value != lastName)
               {
                   lastName = value;
                   RaisePropertyChanged(() => LastName);
               }
           }
       }

       private string firstName;
       public string FirstName
       {
           get { return firstName; }
           set
           {
               if (value != firstName)
               {
                   firstName = value;
                   RaisePropertyChanged(() => FirstName);
               }
           }
       }

   }

Maintenant, nous allons créer une classe MainViewModel et la faire hériter de ViewModelBase. ViewModelBase est une classe que j’ai ajouté au projet et que j’utilise dans tous mes projets Silverlight et WPF notamment pour fournir INotifyPropertyChanged.

On va y ajouter une propriété User sur laquelle notre UI va se binder, et une propriété SaveCommand de type ICommand sur laquelle va se binder un bouton pour lancer la validation de l’utilisateur.

A cet instant notre classe MainViewModel est constituée du code suivant:

public class MainViewModel : ViewModelBase
    {
        private ICommand saveCommand;

        public MainViewModel()
        {
            User = new User();
        }

        private User user;
        public User User
        {
            get { return user; }
            set
            {
                if (value != user)
                {
                    user = value;
                    RaisePropertyChanged(() => User);
                }
            }
        }

        public ICommand SaveCommand
        {
            get
            {
                if (saveCommand == null)
                    saveCommand
                        = new RelayCommand<string>(param => SaveUser(),
                            param => CanSaveUser());
                return saveCommand;
            }
        }

        private bool CanSaveUser()
        {
            return User != null && !string.IsNullOrEmpty(User.FirstName)
                && !string.IsNullOrEmpty(User.LastName);
        }

        private void SaveUser()
        {
            //TODO: ajouter le code pour sauvergarder l'utilisateur
        }
    }

Il nous reste plus qu’à créer l’UI en xaml, avec deux TextBox, un bouton et le Binding nécessaire pour associer ces contrôles avec les propriétés de User et la Commande SaveCommand.

<Grid x:Name="LayoutRoot" Background="White">
        <Grid.RowDefinitions>
            <RowDefinition Height="25" />
            <RowDefinition Height="25" />
            <RowDefinition Height="25" />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
        <TextBlock Text="LastName: " HorizontalAlignment="Right"/>
        <TextBlock Grid.Row="1"
                   Text="FirstName: "
                   HorizontalAlignment="Right" />
        <TextBox Grid.Column="1"
                 Width="150"
                 Text="{Binding User.LastName,Mode=TwoWay}"
                 HorizontalAlignment="Left" />
        <TextBox Grid.Column="1"
                 Grid.Row="1"
                 Width="150"
                 HorizontalAlignment="Left"
                 Text="{Binding User.FirstName,Mode=TwoWay}" />
        <Button Content="Validate"
                Command="{Binding SaveCommand}"
                Grid.Row="2"
                Grid.Column="1" />
    </Grid>

Et à associer View et ViewModel dans le code behind.

this.DataContext = new MainViewModel();

Lancez l’application. Normalement vous devriez avoir à l’écran vos deux textbox et le bouton validate. Mais vous constaterez que le bouton est désactivé.

En effet, si vous vous souvenez, au début du billet nous avons vu les membres de l’interface ICommand. Dans ce billet nous avons utilisé une implémentation de ICommand nommée  RelayCommand dont voici le code:

public class RelayCommand<T> : ICommand
  {
      readonly Action<T> _execute = null;
      readonly Predicate<T> _canExecute = null;

      public RelayCommand(Action<T> execute)
          : this(execute, null)
      {
      }

      public RelayCommand(Action<T> execute,
          Predicate<T> canExecute)
      {
          if (execute == null)
              throw new ArgumentNullException("execute");

          _execute = execute;
          _canExecute = canExecute;
      }

      public bool CanExecute(object parameter)
      {
          return _canExecute == null ? true :
              _canExecute((T)parameter);
      }

      public event EventHandler CanExecuteChanged;

       public void Execute(object parameter)
      {
          _execute((T)parameter);
      }

  }

Lorsque la target, ici le bouton appelle la méthode CanExecute de l’interface ICommand, le delegate _canExecute est également appelé. Ce delegate pointe tout simplement vers la méthode que nous avons ajouté dans le ViewModel: CanSaveUser et retourne une valeur de type boolean. Si la valeur est égale à false, le bouton est alors désactivé.

Si vous tentez de modifier le texte des textbox, l’objet User est bien modifié, cependant le bouton validate reste toujours désactivé, car la méthode CanSave n’est pas réévaluée.

Contrairement à WPF, où il existe un objet CommandManager chargé de relancer la méthode CanExecute lorsqu’un changement au niveau d’une propriété de l’UI est détecté, nous devons nous même appeler l’event CanExecuteChanged de ICommand avec Silverlight.

Ce que nous souhaitons dans notre cas, c’est que l’event soit déclenché à chaque fois que FistName ou LastName est modifiée. Pour cela nous allons étendre RelayCommand en implémentant une nouvelle interface que l’on nommera ICommandExntension avec une méthode RaiseCanExecuteChanged.

public void RaiseCanExecuteChanged()
       {
           EventHandler handler = this.CanExecuteChanged;
           if (handler != null)
               handler(this, EventArgs.Empty);
       }

User implémente INotifyPropertyChanged. Nous allons donc nous abonner à cet event dans le ViewModel, puis dans le handler correspondant, nous allons utiliser SaveCommand en tant que ICommandExtension et appeler la méthode RaiseCanExecuteChanged.

Et voilà, avec ce code, la méthode CanSave sera de nouveau appelée et le bouton sera automatiquement réactivé dès que les conditions nécessaires seront validées.

public MainViewModel()
       {
           User = new User();
           User.PropertyChanged +=
               new PropertyChangedEventHandler(User_PropertyChanged);
       }

       void User_PropertyChanged(object sender,
           System.ComponentModel.PropertyChangedEventArgs e)
       {
           ((ICommandExtension)SaveCommand).RaiseCanExecuteChanged();
       }

Code du billet: Télécharger

Au travers de ce billet, nous verrons une solution qu’il est possible d’implémenter pour modifier les styles des différents contrôles au Runtime.

Les styles peuvent être utilisés de deux manières différentes:

• Les styles que l’on appelle styles implicites. Lors de la déclaration du style, vous ne définissez pas de x:Key mais seulement un TargetType. Tous les contrôles de ce type utiliseront alors ce style
• Les styles que l’on peut nommer styles explicites. Contrairement au précédent, la déclaration du style contient un x:Key et un TargetType. Afin qu’un contrôle puisse utiliser ce type de style, il doit spécifier le style via la propriété Style du contrôle à l’aide de StaticResource.

Seulement contrairement à WPF, où il existe les DynamicResources, Silverlight ne propose que StaticResource.  Vous allez me dire, oui mais où se trouve la différence entre ces deux méthodes.

Globalement la grosse différence réside dans le fait que la résolution d’une StaticResource est réalisée lorsque le xaml de la page est parcouru. Cette opération arrive une fois et vous ne pouvez plus modifier aucune ressource après ça.

A contrario avec les DynamicResources, la ressource est évaluée au Runtime. Le gros avantage, c’est que vous allez notamment pouvoir mettre à jour la target / contrôle, dès qu’un changement est effectué dans un ResourceDictionary. Ceci est très pratique pour appliquer des thèmes à son application.

Heureusement depuis Silverlight 3 des améliorations ont été faites sur la gestion des styles et maintenant nous pouvons mettre à un jour le style d’un contrôle en lui assignant un nouveau style. A noté également la gestion des MergedDictionaries qui permet de composer les styles à partir de plusieurs sources.

Pour mettre en avant ce que nous venons de voir, je vous propose un exemple très simple, dans lequel nous allons simplement modifier la couleur d’un Border et la disposition des contrôles. Le xaml sera composé des éléments suivants:

<UserControl x:Class="SilverlightDynamicMergeDictionaries.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <StackPanel  VerticalAlignment="Center">
            <Border x:Name="MyBorder" Style="{StaticResource Test}"
                    Width="100"
                    Height="100">
            </Border>
            <Button Click="Button_Click"
                    Tag="Red" Width="150"
                    Height="25"
                    Content="Theme Red"/>
            <Button Click="Button_Click"
                    Tag="Blue" Width="150"
                    Height="25"
                    Content="Theme Blue"/>
        </StackPanel>
    </Grid>
</UserControl>

Nous souhaitons définir le style du StackPanel avec un style implicite et le style de l’élément Border avec un style explicite. Comme vous le remarquerez, nous associons le style avec le x:key Test à l’élément Border.

Ces deux styles, nous allons les définir dans un dictionnaire de ressources. Comme dit plus haut, nous souhaitons pouvoir modifier ces styles au runtime, pour cela nous allons ajouter non pas un, mais deux dictionnaires de ressources: blue.xaml et red.xaml

Dans le fichier xaml, j’ai également ajouté deux boutons, pour switcher entre les styles des deux dictionnaires de ressources que l’on peut considérer comme des thèmes.

Partons du principe que le thème par défaut est blue.xaml. Pour l’utiliser nous devons l’ajouter aux ressources de l’application, si l’on souhaite rendre disponible ces styles à l’ensemble des contrôles, quelque soit la page, le contrôle…:

App.xaml:

 <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary
   Source="/SilverlightDynamicMergeDictionaries;component/blue.xaml"/>
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

Une fois cette première étape faite, ajoutez un handler commun pour les deux boutons. Dans cet exemple, le thème à charger sera déterminé via le Tag que nous avons ajouté à chacun des boutons.

Comme nous allons avoir besoin d’ici peu des styles, ajoutons deux variables de type string contenant le chemin vers les ResourcesDictionary.

private const string blueSource
        = "/SilverlightDynamicMergeDictionaries;component/blue.xaml";
private const string redSource
        = "/SilverlightDynamicMergeDictionaries;component/red.xaml";

La nomenclature de nommage est la suivante: /NameSpace;component/Path.xaml

Maintenant dans le handler, commencez par faire un cast du sender en Button de manière à pouvoir récupérer la valeur correspondant au thème à charger.

Puis créez un nouveau ResourceDictionary en assignant à sa propriété Source, une Uri qui prend en paramètre soit blueSource, soit redSource. Le ResourceDictionary est créé, il ne nous reste plus qu’à l’ajouter au MergedDictionaries de App.Resources.

Button btn = sender as Button;
           if (btn != null)
           {
               ResourceDictionary resources =
                   App.Current.Resources as ResourceDictionary;

               ResourceDictionary rd = new ResourceDictionary();
               if (btn.Tag.Equals("Blue"))
                   rd.Source = new Uri(blueSource, UriKind.Relative);
               else
                   rd.Source = new Uri(redSource, UriKind.Relative);

               resources.MergedDictionaries.Add(rd);

A ce stade nous avons ajouté les nouveaux styles. Il nous reste une dernière étape, à savoir, faire en sorte que l’UI soit mise à jour.

Pour cela quelques explications supplémentaires sont nécessaires.

Si vous avez fait attention, entre le dictionnaire ajouté dans App.xaml et celui que nous venons d’ajouter après le click du bouton, MergedDictionaries contient deux dictionnaires avec exactement les mêmes styles.

D’après la msdn, voici ce qui se passe si j’essaie de récupérer un style dans ce cas de figure.

Merged Dictionary Behavior

---

Resources in a merged dictionary occupy a location in the resource lookup scope that is just after the scope of the main resource dictionary they are merged into. Although a resource key must be unique within any individual dictionary, a key can exist multiple times in a set of merged dictionaries. In this case, the resource that is returned will come from the last dictionary found sequentially in the MergedDictionaties collection. If the MergedDictionaties collection was defined in XAML, then the order of the merged dictionaries in the collection is the order of the elements as provided in the markup. If a key is defined in the primary dictionary and also in a dictionary that was merged, then the resource that is returned will come from the primary dictionary. These scoping rules apply equally for both static resource references and dynamic resource references.

Dans notre cas, seule la partie MergedDictionaries nous intéresse. Le Style que nous allons récupérer correspond donc bien au style présent dans le dernier Dictionnaire de ressources ajouté.

Pour assigner les nouveaux styles, nous allons parcourir l’arborescence XAML et pour chacun des contrôles regarder si un style est présent dans les ressources de l’application.

Pour parcourir le XAML voici une méthode d’extension.

public static IEnumerable<DependencyObject>
           Descendents(this DependencyObject root)
       {
           int count = VisualTreeHelper.GetChildrenCount(root);
           for (int i = 0; i < count; i++)
           {
               var child = VisualTreeHelper.GetChild(root, i);
               yield return child;
               foreach (var descendent in Descendents(child))
                   yield return descendent;
           }
       }

Pour l’utiliser, il nous suffit de choisir un DependencyObject correspondant à la partie de l’UI que nous souhaitons rafraichir et de parcourir les éléments dans une boucle foreach en appelant la méthode récursive Descendents.

this.Descendents().ToList().ForEach(c => ApplyNewStyle(c));

Dans l’expression lambda ci-dessus, vous pouvez voir que nous avons également ajouté une méthode ApplyNewStyle avec le contrôle sur lequel on doit l’appliquer. C’est dans cette méthode que nous allons parcourir les dictionnaires, pour trouver l’identifiant correspondant au style et ainsi le récupérer pour l’assigner.

private void ApplyNewStyle(DependencyObject ctrl)
{
 FrameworkElement element = ctrl as FrameworkElement;
 if (element != null)
 {
   foreach (ResourceDictionary dictionary
           in App.Current.Resources.MergedDictionaries)
   {
      foreach (object key in dictionary.Keys)
      {
       if ((element.Style != null && element.Style == dictionary[key]) ||
              (key.ToString() == element.GetType().FullName))
            element.Style = App.Current.Resources[key] as Style;
      }
   }
 }
}

Nous pourrions ne parcourir que le premier dictionnaire car nous savons que dans cet exemple, les deux seuls dictionnaires présents dans MergedDictionaries sont les dictionnaires correspondant à nos styles et que le premier contient les styles de départ. Cependant, dans une application réelle, rien ne vous empêche d’en avoir d’autres.

Pour joindre le bon style au bon contrôle, deux cas se présentent à nous.

• Le cas du StackPanel, où nous avions pas ajouté de x:key (style implicite). En réalité une clé est générée. Plus précisément il s’agit du type du contrôle que l’on a mis dans TargetType. Nous devons donc comparer avec le type de notre contrôle.
• La cas du Border sur lequel nous avons ajouté explicitement un style. Ici il nous suffit donc de comparer le style du contrôle avec le style du dictionnaire possédant la clé courante.

Dernier point. Comme maintenant les styles appliqués sont ceux du dernier dictionnaire ajouté, nous pouvons supprimer le dictionnaire qui se trouve ici à l’index 0.

Le même processus sera effectué à chaque fois que l’on clique sur un des deux boutons.

Comme d’habitude, voici les sources.

Avec Silverlight 4, il existe plusieurs méthodes pour procéder à la validation des données.

• Via des attributs que l’on peut trouver dans System.ComponentModel.DataAnnotations
• L’interface IDataErrorInfo
• L’interface INotifyDataErrorInfo

Dans ce billet je vous propose de voir plus en détail comment utiliser INotifyDataErrorInfo.

Par rapport à IDataErrorInfo, cette interface permet de mettre en place une validation asynchrone. Autre avantage, nous pouvons associer plusieurs erreurs à une propriété sans avoir besoin de concaténer les erreurs.

En effet avec IDataErrorInfo, la récupération de l’erreur se fait via une propriété indexée prenant en argument le nom de la propriété à valider et retournant juste une string correspondant à l’erreur.

Par exemple prenons une classe User dont une des propriétés est Name. User implémente l’interface IDataErrorInfo. Le Name ne doit pas être null ou une chaine vide.

public string this[string propertyName]
       {
           get
           {
               switch (propertyName)
               {
                   case "Name":
                       if (string.IsNullOrEmpty(Name))
                           return "Name cannot be null or empty";
                       break;
               }

               return null;
           }
       }

Maintenant dans le cas où le Name ne serait pas null, on pourrait par exemple vérifier que Name contient au moins 6 caractères  et que ce Name n’est pas déjà utilisé. Si les deux conditions ne sont pas respectées on veut alors retourner à l’utilisateur les deux erreurs. Le seul moyen que nous avons ici est de faire la concaténation des deux erreurs et de la retourner à l’utilisateur.

Venons en justement à la vérification de l’unicité du Name. Cette vérification ne peut être effectuée que du côté serveur. Comme toute opération serveur celle-ci peut prendre plus ou moins de temps avant de retourner une réponse au client.

Avec Silverlight tous les appels au serveur sont asynchrones et une fois le résultat récupéré il faut trouver un moyen de notifier l’utilisateur pour lui indiquer si il y a une erreur et plus précisément ici, si le Name est déjà utilisé par un autre User. C’est là qu’intervient l’interface INotifyDataErrorInfo.

Détaillons le contenu de cette interface:

public interface INotifyDataErrorInfo
{
    bool HasErrors { get; }
    event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;
    IEnumerable GetErrors(string propertyName);
}

• HasErrors: permet de savoir si l’entité contient des erreurs
• ErrorsChanged: est levé quand une erreur est ajoutée, supprimée ou modifiée
• GetErrors: permet de récupérer la collection des erreurs liées à une propriété.

Voyons maintenant comment l’implémenter avec notre classe User.

Commençons par créer une classe de base qui implémente l’interface INotifyDataErrorInfo. Vous pourrez ainsi appliquer ce comportement avec de nouvelles entités.

Nous allons appeler cette classe ModelBase.

Contenu de ModelBase:

private readonly Dictionary<string, List<string>> dataErrors =
    new Dictionary<string, List<string>>();

protected
  void AddError<T>(Expression<Func<T>> propertyExpression, string errorText)
{
    if (propertyExpression == null)
        throw new ArgumentNullException("propertyExpression");

    string propertyName = GetPropertyName(propertyExpression);

    if (!dataErrors.ContainsKey(propertyName))
    {
        dataErrors[propertyName] = new List<string>();
    }

    if (dataErrors[propertyName]
        .SingleOrDefault(e => e == errorText) == null)
        dataErrors[propertyName].Add(errorText);

    OnErrorsChanged(propertyName);
}

protected void ClearErrors<T>(Expression<Func<T>> propertyExpression)
{

    if (propertyExpression == null)
        throw new ArgumentNullException("propertyExpression");

    string propertyName = GetPropertyName(propertyExpression);

    if (dataErrors.ContainsKey(propertyName)
        && dataErrors[propertyName] != null)
        dataErrors.Remove(propertyName);

    OnErrorsChanged(propertyName);
}

protected void OnErrorsChanged<T>(Expression<Func<T>> propertyExpression)
{
    if (propertyExpression == null)
        throw new ArgumentNullException("propertyExpression");

    string propertyName = GetPropertyName(propertyExpression);

    OnErrorsChanged(propertyName);
}

private void OnErrorsChanged(string propertyName)
{
    if (string.IsNullOrEmpty(propertyName))
        throw new ArgumentNullException("propertyName");

    if (ErrorsChanged != null)
    {
        ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));
    }

}

public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

public IEnumerable GetErrors(string propertyName)
{
    if (dataErrors.ContainsKey(propertyName))
    {
        return dataErrors[propertyName];
    }
    return dataErrors.Values;
}

public bool HasErrors
{
    get
    {
        return (from e in dataErrors
                where e.Value.Count > 0
                select e).Count() > 0;
    }
}

Dans cette implémentation on retrouve bien les trois membres de l’interface à savoir: l’event ErrorsChanged, la méthode GetErrors et la propriété HasErrors.

Pour stocker les erreurs nous nous appuyons sur un dictionnaire. Chaque élément de ce dictionnaire est composé d’une clé correspondant au nom de la propriété en erreur et d’une valeur représentée par une liste de string pour y mettre les erreurs relatives  à la propriété.

Maintenant, comme vous  l’aurez certainement remarqué, on a également ajouté plusieurs méthodes:

Une première pour notifier un changement  sur une erreur d’une propriété avec la méthode OnErrorsChanged. Cette méthode prend en paramètre une expression LINQ, nous évitant ainsi de passer le nom de la propriété sous forme de string. Cette technique permet d’éviter toute erreur dans le nommage de la propriété puisque l’erreur sera détectée à la compilation.

Une seconde méthode AddError pour ajouter une erreur relative à une propriété, dans le dictionnaire dataErrors. Cette méthode prend également une expression LINQ et une string représentant l’erreur.

Et enfin une dernière méthode pour supprimer les erreurs d’une propriété. Comme les deux dernières elle se base sur une expression LINQ.

OnErrorsChanged est appelée dans AddError et dans ClearErrors pour notifier les changements. Ces deux méthodes contiennent un appel à la méthode GetPropertyName. Vous pourrez trouver cette méthode dans le code lié au billet. Comme son nom l’indique elle permet d’extraire le nom de la propriété à partir de l’expression LINQ.

ModelBase implémente également INotifyPropertyChanged pour notifier le changement d’une propriété, mais le détail n’est pas présent dans le code ci-dessus.

Voilà cette classe est terminée. Voyons maintenant de plus près la classe User.

public class User : ModelBase
 {
     private string name;
     public string Name
     {
         get { return name; }
         set
         {
             if (value != name)
             {
                 ClearErrors(() => Name);

                 name = value;
                 ValidateUserName(value);
                 OnNotify(() => Name);
             }
         }
     }

     private string firstName;
     public string FirstName
     {
         get { return firstName; }
         set
         {
             if (value != firstName)
             {
                 firstName = value;
                 OnNotify(() => FirstName);
             }
         }
     }
 }

A première vue on observe que la classe User hérite donc de ModelBase. Elle contient trois propriétés mais seule Name nous intéresse ici. Dans le setter avant d’assigner la nouvelle valeur, nous commençons par supprimer les erreurs liées à cette propriété, puis on appelle la méthode ValidateUserName en lui passant la nouvelle valeur, et enfin on notifie que la propriété est modifiée avec OnNotify provenant également de ModelBase.

Comme vous allez le voir avec le code ci-dessous, la méthode ValidateUserName fait appel à un webservice WCF pour vérifier côté serveur que le nouveau Name n’existe pas déjà.

UserService.UserServiceClient proxy
    = new UserService.UserServiceClient();
proxy.ExistsCompleted += (s, e) =>
{
    if (e.Error != null)
    {
        if (e.Error is FaultException<UserStoreFault>)
        {
            FaultException<UserStoreFault> exp =
                e.Error as FaultException<UserStoreFault>;
            if (exp.Detail.Code == StoreFaultCodeEnum.FileNotFoundException)
                AddError(() => Name,
                    "Base de données non disponible
                      merci de réessayer plus tard");

        }

        if (e.Error is FaultException)
        {
            FaultException exp =
                e.Error as FaultException;
            AddError(() => Name,
                "La vérification du username est
                 impossible  pour le moment. Merci de réessayer plus tard");
        }
    }
    else
    {
        string message = "This name already exists";
        if (e.Result)
        {
            AddError(() => Name, message);
        }
        else
        {
            OnErrorsChanged(() => Name);
        }
    }
};
proxy.ExistsAsync(name);

Après avoir instancié le WebService, nous appelons la méthode Exists du service WCF de manière asynchrone. Côté serveur le service est chargé de vérifier que le name passé en paramètre n’existe pas déjà. Peu importe où les Users se trouvent: xml, base de données. Ce point n’est pas important pour le sujet de ce billet (Une implémentation du service est présente dans les sources liées au billet)

Une fois que le service a terminé son traitement le callback ExistCompleted est appelé. C’est dans cette méthode que nous allons faire la gestion d’erreur. Dans le cas où le webservice n’a pas levé d’erreur ie que e.Error est null, on vérifie la valeur retournée par la méthode Exists qui se trouve dans la propriété Result. Si Result à la valeur true, alors le Name existe déjà. Dans ce cas on appelle la méthode AddError détaillée plus haut, qui va se charger d’ajouter l’erreur dans le dictionnaire, puis de notifier le changement. Et voilà !!

Au passage, vous noterez la gestion d’erreur avec les FaultException si le WebService a levé une exception. Pour plus de détail, je vous invite à consulter ce billet.

Dernier point qui nous reste à voir, l’UI. Pour tester tout ce code, nous allons simplement créer une instance de User puis l’ajouter au DataContext de MainPage. Enfin dans  MainPage, nous allons ajouter une TextBox et nous binder sur la propriété Name. Pour que les erreurs puissent s’afficher, il ne faut pas oublier d’assigner la valeur true à la propriété ValidatesOnNotifyDataErrors de l’élément Binding et le tour est joué.

User newUser = new User();
this.DataContext = newUser;

<TextBox Text="{Binding Name,ValidatesOnNotifyDataErrors=True,Mode=TwoWay}" Width="125" Height="25" />

Sur le serveur les Users se trouvent actuellement dans un fichier xml. Si vous entrez une valeur Name différente de celles  existantes, aucune erreur ne s’affichera. Dans le cas contraire, vous verrez apparaître un tooltip rouge avec le détail de l’erreur.

<Users>
  <User>
    <UserName>alex</UserName>
    <FirstName>Alexandre</FirstName>
    <LastName>Arnaudet</LastName>
  </User>
  <User>
    <UserName>al</UserName>
    <FirstName>Alexandre</FirstName>
    <LastName>Arnaudet</LastName>
  </User>
</Users>

Retrouvez l’intégralité du code ici.

Lors de la phase de développement, une pratique commune est de modifier la behavior associée au service en ajoutant l’élément serviceDebugincludeExceptionDetailInFaults à true pour que les erreurs puissent remonter jusqu’au client. Bien entendu, n’oubliez pas de désactiver cette option lors de la livraison de votre service en production.

Si vous avez fait attention, vous aurez remarqué que le dernier mot de l’élément cité ci-dessus est Fault.  Une Fault est une classe sérialisable permettant de faire transiter entre le serveur et le client des informations structurées concernant l’erreur qui est arrivée.

Pour utiliser les Faults, il vous suffit d’ajouter l’attribut FaultContract sur une opération identifiée par l’attribut OperationContract et d’y passer le type de fault gérée. A noter qu’on peut renvoyer des Faults aussi bien technique que métier.

Codons un exemple pour illustrer ce que nous venons de dire.

Commencez par créer une solution et ajoutez-y une librairie WCF. Dans cette exemple nous allons considérer que notre service a une seule opération permettant de retourner un customer.

L’élément doit être sérialisable et est représenté par les trois propriétés suivantes:

[DataContract]
   public class Customer
   {
       [DataMember]
       public int Id { get; set; }
       [DataMember]
       public string LastName { get; set; }
       [DataMember]
       public string FirstName { get; set; }
   }

Pour définir le service, nous allons dans un premier temps créer le contrat et y ajouter l’opération GetCustomer

[ServiceContract]
   public interface ICustomerService
   {
       [OperationContract]
       [FaultContract(typeof(CustomerNotFoundFault))]
       Customer GetCustomer(int projectId);
   }

Ensuite ajoutez une implémentation pour ce service

public class CustomerService : ICustomerService
   {
       private List<Customer> Customers = new List<Customer>();

       public CustomerService()
       {
           Customers.Add(
               new Customer
               {
                   Id = 1,
                   FirstName = "FirstName1",
                   LastName = "LastName1"
               });
           Customers.Add(
               new Customer
               {
                   Id = 2,
                   FirstName = "FirstName2",
                   LastName = "LastName2"
               });
       }

       public Customer GetCustomer(int projectId)
       {
           throw new Exception("test exception");
       }
   }

Le service contient une collection de customer dont nous nous servirons plus tard. Bien entendu dans un projet réel, vous aurez une DAL. J’ai tout codé dans le service pour des raisons de simplicité pour la démo.

Afin de tester que par défaut aucune information sur le contenu de l’exception est envoyée au client, j’ai ajouté un throw new Exception.

Ajoutez une application console pour tester le service, puis créez le proxy et appelez l’opération GetCustomer

static void Main(string[] args)
        {
            CustomerServiceClient client = new CustomerServiceClient();
            client.GetCustomer(-1);
        }

Vous devriez obtenir l’écran suivant:

On se rend compte qu’une FaultException générique a été créée par WCF pour nous suite à une exception sur le serveur. Cependant nous n’avons aucune information détaillée sur la raison réelle de l’exception.

En effet, si vous jetez une petit coup d’œil dans le fichier de configuration serveur, vous remarquerez que includeExceptionDetailInFault est à false.

 <serviceDebug includeExceptionDetailInFaults="False" />

Pour aller jusqu’au bout de ce test, changez la valeur en la passant à true et exécutez à nouveau l’application console.

Cette fois, le contenu de l’exception a bien été envoyé au client. Bien entendu pour une application destinée à être utilisée en production nous allons laisser cette valeur à false et utiliser des Faults dites déclarées.

Mettons à jour le code pour refléter l’utilisation des Faults. Pour cela posons-nous la question suivante :

Quelles sont les erreurs pouvant être levées lors de l’appel de la méthode GetCustomer ? Pour ne pas compliquer les choses nous allons nous limiter à:

• Id customer non valide
• customer non trouvé.

Pour matérialiser ces deux points nous allons utiliser les classes FaultException pour l’Id non valide, et une FaultException personnalisée que nous nommerons CustomerNotFoundFault pour l’utilisateur non trouvé.

FaultException est nativement gérée par WCF. Pour indiquer qu’une CustomerNotFoundFault peut être levée dans l’opération, nous devons ajouter l’attribut FaultContract au niveau de la déclaration de l’opération.

    [OperationContract]
    [FaultContract(typeof(CustomerNotFoundFault))]
    Customer GetCustomer(int projectId);

[DataContract]
   public class CustomerNotFoundFault
   {
       [DataMember]
       public string ErrorMessage { get; set; }

       [DataMember]
       public int Id { get; set; }
   }

Si vous omettez cet attribut, ce type de FaultException ne sera tout simplement pas exploitable par le client du service.

Pour résumer ces quelques lignes voici le code correspondant:

public Customer GetCustomer(int Id)
 {
    FaultCode faultCode;
    FaultReason faultReason;

    Customer cust = null;

    if (Id < 1)
    {
       faultReason = new FaultReason("Invalid Customer Id");
       faultCode = FaultCode
          .CreateSenderFaultCode("InvalidRequest", this.GetType().FullName);
           throw new FaultException(faultReason, faultCode);
    }

    cust = Customers.FirstOrDefault(c => c.Id == Id);
    if (cust == null)
    {
     CustomerNotFoundFault fault = new CustomerNotFoundFault
     {
       Id = Id,
       ErrorMessage = string.Format("No Customer with id {0}", Id)
     };
         throw new
          FaultException<CustomerNotFoundFault>(fault, fault.ErrorMessage);
    }

    return cust;
 }

Vous constaterez également l’utilisation de FaultReason permettant de décrire l’erreur et FaultCode plus utilisé pour identifier la source, le type de l’erreur.

Pour voir maintenant ce qui arrive côté client, effectuons de nouveaux tests, avec pour commencer, une valeur inférieure à 0.

On voit que cette fois-ci le client reçoit une FaultException. Au niveau du contenu, on retrouve la FaultReason ainsi que le Fault Code qui ont été spécifiés côté serveur.

Dans le code ci-dessous, on voit que la propriété IsSenderFault est à true. En effet le serveur a précisé qu’il s’agissait d’une erreur due au client. En l’occurrence, il s’agit ici de l’id customer qui n’est pas valide.

Pour la seconde erreur, à savoir un customer non trouvé, nous venons de voir qu’une exception FaultException<CustomerNotFoundFault> était levée.

Coté client il vous suffit de mettre un try / catch englobant l’appel au service avec une gestion d’erreur du plus spécifique au plus général, c’est à dire d’abord  FaultException<CustomerNotFoundFault> puis  FaultException. Une fois l’erreur attrapée vous pourrez prendre  une décision sur le comportement que le client doit avoir.

Nous venons de voir globalement comment fonctionnaient les FaultException avec WCF et une application cliente de type console.

Dans le cadre d’un client comme silverlight, quelques développements supplémentaires sont nécessaires.

En effet par défaut lorsqu’une erreur arrive côté serveur une erreur 500 est envoyée au client. Il sait qu’il y  a eu une erreur mais sans plus de détail.

Le message exacte est :" The remote server returned an error: NotFound"

Une solution possible est donc d’intercepter côté serveur toute Fault et de modifier le code 500 renvoyé au client par un code 200 qui dans le cadre d’une réponse HTTP signifie que tout s’est bien passé. Le client Silverlight pourra ainsi accéder à la Fault.

Pour y parvenir, nous allons créer une behavior qui sera associée au EndPoint. Cette behavior doit hériter de BehaviorExtensionElement et implémenter l’interface IEndPointBehavior.

• BehaviorExtensionElement représente un élément de configuration pour paramétrer une extension
• IEndPointBehavior apporte des méthodes pour modifier le comportement du EndPoint

Parmi les méthodes disponibles via l’interface IEndPointBehavior, une nous intéresse plus particulièrement ici. Il s’agit de la méthode ApplyDispatcherBehavior qui va nous permettre d’étendre la manière dont réagit le service.

public class FaultBehaviour : BehaviorExtensionElement, IEndpointBehavior
   {
       public void ApplyDispatchBehavior
           (ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
       {
           SilverlightFaultMessageInspector inspector =
               new SilverlightFaultMessageInspector();
           endpointDispatcher
               .DispatchRuntime.MessageInspectors.Add(inspector);
       }

Dans cette méthode on retrouve la création d’une classe implémentant l’interface IDispatchMessageInspector dont le but est comme son nom le laisse entendre, d’intercepter le message transitant pour l’analyser et / ou le modifier.

Rappelons que nous souhaitons modifier le code http renvoyé au client. Pour cela implémentons la méthode BeforeSendReply de IDispatchMessageInspector.

public void BeforeSendReply(ref Message reply, object correlationState)
 {
  if (reply.IsFault)
  {
   HttpResponseMessageProperty property = new HttpResponseMessageProperty();

                   // Change response code to 200 (default: 500)
      property.StatusCode = System.Net.HttpStatusCode.OK;

      reply.Properties[HttpResponseMessageProperty.Name] = property;
   }
  }

Dans ce code, nous voyons clairement, que si la réponse est une FaultException, nous passons le code de status à Ok: HTTP 200.

Afin que cette extension puisse être utilisée, il nous reste un dernier point à voir. Mettre à jour le fichier de configuration, en ajoutant l’extension et en l’assignant au endpoint correspondant.

Pour cela dans la section ServiceModel du web.config, commencez par déclarer l’extension.

<extensions>
      <behaviorExtensions>
        <add name="silverlightFaults"
             type="SilverlightApplicationFault.Web.FaultBehaviour,
                  SilverlightApplicationFault.Web,
                  Version=1.0.0.0,
                  Culture=neutral,
                  PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensions>

Ajoutez ensuite la behavior dans la section behaviors:

 <endpointBehaviors>
        <behavior name="SilverlightFaultBehavior">
          <silverlightFaults/>
        </behavior>
      </endpointBehaviors>

Enfin reconfigurez le endpoint pour utiliser la behavior que l’on vient d’ajouter.

  <endpoint address="" binding="customBinding"
    bindingConfiguration="SilverlightApplicationFault.Web
      .CustomerService.customBinding0"
    contract="SilverlightApplicationFault.Web.ICustomerService"
    behaviorConfiguration="SilverlightFaultBehavior" />

La configuration est à présent terminée.

Relancez l’application, vous devriez voir la Fault remontée côté client.

Vous pouvez télécharger les sources ici.

Nous avons réalisé les premiers développements sans encombre et ces derniers jours nous avons décidé de déployer l’application sur un serveur, afin que le client puisse tester et prendre en main l’application tout au long de son développement.

Le serveur sur lequel l’application est déployée est Windows Server 2008, le tout tournant sous IIS 7.

Pour des raisons de sécurité, nous avons également configuré le SSL sur l’intégralité des pages de l’application.

Le déploiement étant terminé, la phase de teste pointe le bout de son nez. Le client utilise encore IE 6. Nous démarrons donc ce navigateur, entrons l’url de l’application en question et là une erreur apparaît à l’écran. L’erreur n’est absolument pas explicite. La seule information que nous ayons étant le code suivant: 0×80020101, sans plus de détail.

Après quelques recherches sur le net, je ne comprends toujours pas ce qui provoque cette erreur. Depuis un autre ordinateur que le mien, je lance l’application sous IE 7 et là aucun soucis. Idem avec la dernière version de Firefox.

Ne sachant toujours pas où se situe le problème, j’essaie de désactiver le SSL et là oh miracle je n’ai plus d’erreur. Suite à de nouvelles recherches sur le web, je remarque que plusieurs développeurs indiquent de faire attention à bien préciser la balise src sur les éléments HTML possédant cette propriété. 

Sachant que l’intégralité de l’application est en silverlight, la seule page pouvant contenir un élément HTML est donc la page hôte qui contient justement notre application. Et là que vois-je: une Iframe. J’ajoute donc la propriété src et la fait pointer faire une page html ne contenant strictement rien -> <iframe src="./page.html" …./>

Après cette modification, je relance l’application, toujours sans SSL pour vérifier le bon fonctionnement et tout est Ok. Je réactive donc le SSL sur IIS et là super tout fonctionne sans erreur.

Pendant la phase de développement d’un projet cela ne pose aucun problème, puisque ces outils sont nécessaires pour le développement, mais comment procéder pour le déploiement  sur un serveur.

Deux possibilités existent:

• La première consiste simplement à passer la propriété Copy Local des références RIA Services à true. Ainsi au moment de la compilation les binaires seront copiés dans le dossier bin. Il ne sera donc pas nécessaire d’utiliser un setup quelconque pour les installer dans le GAC.
• La deuxième solution est d’utiliser le même MSI que pour l’installation sur la machine de développement mais en ligne de commande avec les paramètres suivants: msiexec /i RIAServices.msi SERVER=true. En procédant ainsi, les binaires sont déployés dans le GAC et le MSI ne fait plus attention aux pré requis.

Prenons un exemple simple.

Commençons par créer une classe basique User avec trois propriétés:

• UserId
• LastName
• FirstName

Une fois ceci fait, ajoutez une référence sur System.CompoenentModel.DataAnnotations et placez l’attribut Display sur chacune des propriétés. Cet attribut contient un certain nombre de propriétés, mais seulement deux nous intéressent ici: Name et ResourceType.

Comme vous l’aurez certainement compris, le nom que l’on veut affecter à chacune de nos propriétés peut être stocké dans un fichier de ressources dont l’extension est .resx

public class User :   INotifyPropertyChanged
    {
        [Key]
        [Display(Name = "UserId",
            ResourceType = typeof(Resources.ResourcesApplication))]
        public int UserId { get; set; }

        [Display(Name="FirstName",
            ResourceType=typeof(Resources.ResourcesApplication))]
        public string FirstName { get; set; }

         [Display(Name="LastName",
             ResourceType = typeof(Resources.ResourcesApplication))]
        public string LastName { get; set; }

        public event PropertyChangedEventHandler PropertyChanged;

        public void Notify(string propertyName)
        {
            if (string.IsNullOrEmpty(propertyName))
                throw new ArgumentNullException("propertyName");

            if (PropertyChanged != null)
                PropertyChanged(this,
                    new PropertyChangedEventArgs(propertyName));
        }
    }

A l’aide d’un DomainService, nous allons maintenant exposer côté client l’entité User. Je vous propose ici d’ajouter une méthode GetUsers qui comme son nom l’indique, permettra de récupérer une collection de User.

[EnableClientAccess()]
    public class UserDomainService : DomainService
    {
        private static List<User> users;

        public UserDomainService()
        {
            users = new List<User>();
            users.Add(new User
            {
                UserId = 1,
                LastName = "Arnaudet",
                FirstName = "Alexandre"
            });
            users.Add(new User
            {
                UserId = 2,
                LastName = "Vanheren",
                FirstName = "Anne-Sophie"
            });
        }

        public IEnumerable<User> GetUsers()
        {
            return users;
        }

    }

Si à cet instant vous compilez l’application, vous allez obtenir une erreur provenant du fichier auto généré côté client qui contient le Model et donc notre entité User. Ce fichier est facilement identifiable de part son extension “.g.cs”, uniquement visible dans la solution si vous sélectionnez le bouton Show All Files.

Pourquoi cette erreur ? Tout simplement parce que les RIA Services ne propagent pas automatiquement les fichiers de ressources du serveur vers le client.

Quelle solution avons-nous pour palier à ce manque ?

Vous pourriez créer un fichier de ressource côté serveur et un fichier de ressource côté client, mais dans ce cas là, vous aurez deux fichiers à maintenir. Cette solution n’est donc pas envisageable.

Une solution possible est d’ajouter le fichier de ressource en tant que fichier lié.

Pour cela créez un dossier dans votre application Silverlight, puis ajoutez les ressources en procédant de la manière suivante:

• �
  • Sélectionnez le dossier où vous souhaitez ajouter le fichier de ressource
  • Faites “Ajouter un item existant”
  • Une fois la fenêtre ouverte, parcourez les dossiers jusqu’à localiser la ressource serveur
  • Sélectionnez le fichier resx et le le fichier designer.cs
  • Cliquez sur la flèche du bouton “Add” et choisissez “Add as link”

Reprenons notre exemple avec la classe User et son DomainService associé. Dans le projet Silverlight, nous pouvons ajouter une vue avec un contrôle DataForm. Enfin via le UserDomainContext, nous récupérons et associons les données au DataForm.

<form:DataForm x:Name="DataForm" AutoGenerateFields="True"/>

UserDomainContext ctx = new UserDomainContext();
ctx.Load(ctx.GetUsersQuery(),(u)=>DataForm.ItemsSource = u.AllEntities,null);

Lancez l’application et vous devriez maintenant voir les données, avec les labels provenant du fichier de ressource.

Remarque: au runtime, le Framework génère un nom de fichier différent du nom avec le .resx. Par exemple pour notre fichier ResourcesApplication.resx, le nom généré sera “SilverlightApplicationTestResources.Web.Resources.ResourcesApplication.resources”, avec “SilverlightApplicationTestResources.Web” qui correspond au root namespace du projet et “Resources” au nom du sous dossier qui contient notre fichier resx.

Côté client, vous devez respecter, la même arborescence sous peine d’avoir une exception au runtime

Pour forcer le nom du fichier qui sera utilisé au runtime, une solution est d’éditer le csproj manuellement en ajoutant l’élément logicalName dans EmbededResource.

  <EmbeddedResource
      Include="..\SilverlightApplicationTestResources.Web
        \Resources\ResourcesApplication.resx">
      <Link>Links\ResourcesApplication.resx</Link>
      <LogicalName>SilverlightApplicationTestResources.Web
        .Resources.ResourcesApplication.resources</LogicalName>
    </EmbeddedResource>

Retrouvez les sources ici.

Par défaut, j’ai pour habitude d’interdire l’accès au site à toutes les personnes non authentifiées via quelques lignes dans le web.config.

  <authorization>
    <deny user="?" />
  </autorization>

L’application sur laquelle je travaille contient un fichier xap pour le module d’authentification et un second fichier xap pour le reste de l’application.

Afin que le client soit capable de télécharger le xap d’authentification au lancement de l’application, il faut ajouter dans le web.config une balise location pointant vers le xap et préciser qu’on autorise tous les utilisateurs authentifiés et non authentifiés à y accéder.

<location path="’ClientBin/Authentication.xap">
    <system.web>
      <authorization>
        <allow user="*"/>
      </authorization>
    </system.web>
  </location>

A présent le client arrive à charger le xap et à afficher la fenêtre d’authentification.

Mais il reste encore un problème à régler.

Il existe côté serveur un DomainService contenant notamment une méthode Login. Lors de la compilation un DomainContext est créé du côté client.

Après que l’utilisateur ait entré ses identifiants, on appelle la méthode login du DomainService, mais le serveur retourne une erreur indiquant que le service n’a pas été trouvé.

Pour qu’il soit accessible, il faut au même titre que pour le xap,  autoriser l’accès.

Derrière chaque  DomainService se cache un service WCF et donc un fichier avec une extension .svc.

En partant du principe que votre DomainDervice se trouve dans le dossier Service de l’application web, le nom final du svc sera le suivant:

http://host/service/lenomdemonapplicationweb-lenomdemondomainservice.svc

Le Framework fait la concaténation du nom de l’application web, avec le nom du DomainService, en remplaçant tous les points par des tirets.

Il ne vous reste plus qu’à ajouter une dernière balise Location dans le web.config afin que le DomainService soit accessible.

  <location path="service/lenomdemonapplicationweb-lenomdemondomainservice.svc">
    <system.web>
      <authorization>
        <allow user="*"/>
      </authorization>
    </system.web>
  </location>

Merci à Fiddler qui permet de voir les requêtes http.

Dans ce nouveau billet nous allons nous intéresser à deux points.

• Comment faire pour charger une page à la demande
• Comment charger un module pouvant contenir des ressources supplémentaires à la page.

Pour le code, nous allons repartir de celui que j’avais précédemment ajouté et que vous pouvez récupérer ici

Ouvrez le UserControl MainPage.xaml. Dans le code xaml de cette page, vous remarquerez la présence d’un élément nommé UriMapper chargé de faire le mapping entre une Uri et une page xaml.

En regardant d’un peu plus près pour voir comment tout cela fonctionne, on s’aperçoit que l’élément Frame via sa propriété ContentLoader met à disposition un objet chargé de fournir un contenu correspondant à l’Uri vers laquelle on navigue. Cette propriété est de type INavigationContentLoader. Dans version 4, Silverlight possède une implémentation par défaut nommée PageResourceContentLoader, permettant de réaliser le comportement vu ci-dessus, à savoir une Uri vers une page.

Il ne faut pas oublier que Silverlight est avant tout une technologie côté client et donc pour fonctionner correctement, l’api doit télécharger sur le client un fichier xap avec le contenu de l’application à exécuter.  Les pages peuvent faire appel à différentes ressources ( images, dlls …..), ce qui peut très vite faire prendre du poids au fichier xap de l’application principale et donc notamment allonger le temps de chargement de l’application.

Une solution possible est donc de faire en sorte qu’une page soit téléchargée uniquement lorsqu’on la demande.

Pour y parvenir je me suis reposé sur un ContentLoader créé par David Poll. Bien entendu ce content loader implémente l’interface INavigationContentLoader.  Il permet de mettre en relation une Uri et une page qui se trouve dans un fichier xap séparé du xap principal.

Voyons le code dont il est constitué et comment il fonctionne.

Nous avons un premier projet ContentLoader.Utils contenant les classes suivantes:

• ContentLoaderBase.cs
• ContentLoaderBaseAsyncResult.cs
• LoaderBase.cs

Comme son nom l’indique ContentLoaderBase simplifie la mise en place d’un ContentLoader en fournissant un comportement de base, notamment au travers de l’implémentation de l’interface de INavigationContentLoader:

public interface INavigationContentLoader
{
       IAsyncResult BeginLoad(Uri targetUri, Uri currentUri,
             AsyncCallback userCallback, object asyncState);
       void CancelLoad(IAsyncResult asyncResult);
       bool CanLoad(Uri targetUri, Uri currentUri);
       LoadResult EndLoad(IAsyncResult asyncResult);
}

• BeginLoad permet de démarrer le chargement d’un contenu correspondant à l’Uri de manière asynchrone.
• CancelLoad pour annuler une opération de chargement
• CanLoad pour indiquer si l’Uri peut être chargée
• EndLoad pour terminer l’opération asynchrone de chargement du contenu

Regardons plus en détail la méthode BeginLoad

Code de BeginLoad:

public IAsyncResult BeginLoad(Uri targetUri,
            Uri currentUri, AsyncCallback userCallback,
            object asyncState)
        {
            LoaderBase loader = CreateLoaderPrivate();
            ContentLoaderBaseAsyncResult result =
                new ContentLoaderBaseAsyncResult(asyncState,
                    loader, userCallback);
            result.BeginLoadCompleted = false;
            loader.Result = result;
            lock (result.Lock)
            {
                loader.Load(targetUri, currentUri);
                result.BeginLoadCompleted = true;
                return result;
            }
        }

Nous commençons par faire appel à la méthode CreateLoaderPrivate pour créer une instance de classe héritant de LoaderBase. En effet LoaderBase est également une classe abstraite.

protected abstract LoaderBase CreateLoader();

       private LoaderBase CreateLoaderPrivate()
       {
           LoaderBase loader = CreateLoader();
           loader.ContentLoader = this;
           return loader;
       }

Le ContentLoader personnalisé devra surcharger la méthode CreateLoader pour créer un LoaderBase et le retourner au ContentLoaderBase qui se chargera alors d’appeler la méthode Load du LoaderBase pour lancer le chargement du contenu. La création d’un loader héritant de LoaderBase permet de garder la logique de chargement, d’annulation.. séparée du ContentLoader lui même.

Vous pourrez voir plus de code concernant cette classe dans le fichier zip joint à la  fin du billet.

Dernier point que nous allons aborder par rapport à la méthode BeginLoad, le type de retour. On retourne ici un IAsyncResult qui représente le statut d’une opération asynchrone. Pour ce la David a également créé une classe nommée ContentLoaderBaseAsyncResult qui  implémente l’interface IAsyncResult.

internal class ContentLoaderBaseAsyncResult : IAsyncResult
   {
       public ContentLoaderBaseAsyncResult(object asyncState,
           LoaderBase loader, AsyncCallback callback)
       {
           this.AsyncState = asyncState;
           this.Loader = loader;
           this.Lock = new object();
           this.Callback = callback;
           AsyncWaitHandle = new AutoResetEvent(false);
       }

       internal LoaderBase Loader { get; private set; }
       internal AsyncCallback Callback { get; private set; }
       internal Exception Error { get; set; }
       internal object Page { get; set; }
       internal Uri RedirectUri { get; set; }
       internal object Lock { get; private set; }
       internal bool BeginLoadCompleted { get; set; }

       #region IAsyncResult Members

       public object AsyncState
       {
           get;
           private set;
       }

       public System.Threading.WaitHandle AsyncWaitHandle
       {
           get;
           private set;
       }

       public bool CompletedSynchronously
       {
           get;
           private set;
       }

       public bool IsCompleted
       {
           get;
           private set;
       }

       public void Complete()
       {
           this.CompletedSynchronously = !BeginLoadCompleted;
           this.IsCompleted = true;
           (this.AsyncWaitHandle as AutoResetEvent).Set();
       }

       #endregion
   }

Cette implémentation de IAsyncResult contient également des propriétés supplémentaires comme Error pour savoir si une erreur a été levée durant l’opération, ou Page qui va contenir la Page présente dans le xap téléchargé à la fin de l’opération.

L’instance créée dans BeginLoad est passée au loader, notamment avec un paramètre userCallback qui correspond à une méthode que le ContentLoaderBase pourra appeler une fois l’opération terminée.

if (Dispatcher.CheckAccess())
{
    ((ContentLoaderBaseAsyncResult)result).Callback(result);
}
else
{
    Dispatcher.BeginInvoke(() =>
             ((ContentLoaderBaseAsyncResult)result).Callback(result));
 }

Maintenant que nous avons fait une revue globale des classes nécessaires au bon fonctionnement d’un ContentLoader personnalisé, passons justement au code le concernant. Ce ContentLoader s’appuie sur MEF pour découvrir et faire la résolution des pages d’où son nom MEFContentLoader.

Afin d’utiliser ce ContentLoader, plusieurs modifications doivent être faites:

Mettre à jour l’élément navigation:Frame qui se trouve dans MainPage.

<navigation:Frame x:Name="ContentFrame"
                       Style="{StaticResource ContentFrameStyle}"
                       Source="/Home" Navigated="ContentFrame_Navigated"
                       NavigationFailed="ContentFrame_NavigationFailed">
                <navigation:Frame.ContentLoader>
                    <MefNav:MEFContentLoader />
                </navigation:Frame.ContentLoader>
            </navigation:Frame>

Comme vous l’aurez compris, en faisant cette modification dans le code xaml, on va désormais utiliser MEFContentLoader et non plus le ContentLoader par défaut.

Le contrôle utilisé pour faire un lien vers une page est généralement un HyperlinkButton. Dans le cas de la page Home qui restera dans le projet principale, rien ne change

<HyperlinkButton x:Name="Home" Style="{StaticResource LinkStyle}"
            NavigateUri="/Home" TargetName="ContentFrame" Content="home"/>

Par contre pour la page ListePersonnes que nous allons mettre dans un xap / une application différente, nous précisons au niveau de l’HyperlinkButton via une propriété attachée, le nom du fichier xap  qui contiendra la page.

 <HyperlinkButton x:Name="MyPage"
               Style="{StaticResource LinkStyle}"
               NavigateUri="/MyPage"
               MefNav:MEFContentLoader.Xap="Personnes.xap"
               TargetName="ContentFrame"
               Content="MyPage"/>

MefNav est un namespace que nous avons ajouté dans la déclaration du UserControl, pointant vers MEFContentLoader, la classe dans laquelle se trouve la propriété attachée.

    xmlns:MefNav="clr-namespace:SilverlightApp.ContentLoader.Mef
                    ;assembly=SilverlightApp.ContentLoader.Mef"

public static readonly DependencyProperty XapProperty =
    DependencyProperty.RegisterAttached("Xap",
    typeof(string), typeof(HyperlinkButton),
    new PropertyMetadata(null, XapPropertyChangedCallback));

public static string GetXap(DependencyObject obj)
{
    return (string)obj.GetValue(XapProperty);
}

public static void SetXap(DependencyObject obj, string value)
{
    obj.SetValue(XapProperty, value);
}

public static void
    XapPropertyChangedCallback(DependencyObject d,
    DependencyPropertyChangedEventArgs e)
{
    var button = (HyperlinkButton)d;
    _uriMap[button.NavigateUri] = (string)e.NewValue;
}

La propriété attachée possède une méthode callback appelée dès que sa valeur est modifiée.

Elle permet de stocker dans un dictionnaire nommé _uriMap une relation entre l’Uri ou l’on navigue et le fichier xap correspondant.

Comme nous avons vu plus haut, le ContentLoader se base sur le Framework MEF pour découvrir les pages. Mais avant de pouvoir utiliser MEF, il faut configurer un CompositionContainer et un ou plusieurs catalogues pour permette au conteneur de savoir où aller chercher les Pages / Parts. Pour cela, la classe MefContentLoader commence par créer un Loader héritant de LoaderBase qui va appeler une méthode Initialize. Cette méthode est appelée si c’est la première fois que la méthode Load du Loader est appelée. Regardons comment le conteneur est initialisé.

_catalog.Catalogs.Add(new DeploymentCatalog());
Container = new CompositionContainer(_catalog);

CompositionHost.Initialize(Container);
CompositionInitializer.SatisfyImports(this);
_initialized = true;

Nous commençons par créer un DeploymentCatalog, sans lui passer de paramètre, ce qui signifie qu’il permettra de découvrir les différentes Parts dans le xap courant à savoir le xap principal de l’application. Ce dernier est ensuite ajouté dans un AggregateCatalog qui peut également contenir d’autres catalogues en fonction du besoin, qui lui même est passé en paramètre du conteneur créé.

Comme nous appelons ici la méthode Initialize de CompositionHost et qu’elle ne peut être appelée qu’une seule fois, il faut vérifier si le conteneur a déjà été initialisé, d’où l’utilisation de la variable de type boolean _initialized.

Notez également l’appel de la méthode SatisfyImports sur l’instance courante. Si on appelle cette méthode, cela signifie que MefContentLoader contient au moins un Import à satisfaire.

En effet c’est bien le cas. L’élément Import est représenté via la propriété PageFactories.

[ImportMany(AllowRecomposition = true)]
        public IEnumerable<ExportFactory<Page, IExportPageMetadata>>

Que pouvons nous dire de cette propriété:

• nous nous attendons à avoir une collection de Parts basées sur un contrat de type Page.
• des métadonnées sont accessibles via l’interface IExportPageMetadata, ce qui va permettre de filtrer en fonction de l’Uri courante.
• l’utilisation de AllowRecomposition = true, permettra à la propriété de se mettre à jour pour éventuellement fournir de nouvelles Parts suite à l’ajout ou à la suppression d’un catalogue dans le conteneur.

Comme vous le savez, avec MEF, tout est basé sur des Imports et des Exports. Passons donc aux exports.

Afin de ne pas avoir plusieurs attributs (export, metadata…) à créer sur les parts export, un seul attribut héritant d’ExportAttribute est ajouté.

[MetadataAttribute]
   [AttributeUsage(AttributeTargets.Class,
       AllowMultiple = false,
       Inherited = true)]
   public class ExportPageAttribute : ExportAttribute
   {
       public string NavigateUri { get; private set; }

       public ExportPageAttribute(string uri)
           : base(typeof(Page))
       {
           if (string.IsNullOrEmpty(uri))
               throw new ArgumentNullException("uri");

           this.NavigateUri = uri;
       }
   }

Notez MetadataAttribute, pour préciser que l’attribut ExportPageAttribute transporte des métadonnées qui seront accessibles aux travers de l’interface IExportPageMetadata.

Le contrat est basé sur le type Page, que l’on passe au constructeur de la classe de base.

Reprenons donc les deux pages ajoutées,  Home dans l’application hôte et ListePersonnes dans une seconde application silverlight, pour générer un deuxième fichier xap.

 [ExportPage("/Home")]
 public partial class Home : Page

 [ExportPage("/ListePersonnes")]
 public partial class ListePersonnes : Page

Que ce soit pour l’une ou pour l’autre rien ne diffère, nous avons utilisé l’attribut créé juste avant en lui passant comme métadonnée, l’Uri de navigation.

Ok, maintenant que les Imports et Exports sont créés que se passe il lorsqu’on navigue sur l’une des deux pages ?

On a vu plus haut que le MefContentLoader contenait un dictionnaire dans lequel, via la propriété attachée Xap, on avait ajouté des items dont la clé était l’Uri cible et la valeur le nom du fichier xap contenant la page à charger.

Dans la méthode Load, on commence par parcourir ce dictionnaire pour voir si l’on trouve un élément correspondant à l’Uri de destination. Deux cas sont alors possibles

• Aucun élément trouvé, ce qui signifie que soit la page n’existe pas, soit elle se trouve dans l’application hôte.
• Un élément trouvé. On vérifie alors que le xap correspondant n’a pas déjà été téléchargé. Si le xap n’a pas encore été téléchargé
  • on créé un DeploymentCatalog pour réaliser le téléchargement en lui passant en paramètre le nom du xap.
  • On démarre la procédure en appelant la méthode DownloadAsync.
  • Une fois le téléchargement terminé l’event DownloadCompleted du DeploymenyCatalog est appelé et on ajoute ce catalogue avec les autres catalogues créés dans la méthode Initialize. Comme la propriété Import a sa propriété AllowRecomposition à true, la Part présente dans le xap est disponible. Elle n’est pas encore instanciée, mais on peut à présent le faire.

if (_uriMap.TryGetValue(saveTargetUri, out xap)
                       && xap != null && !_loadedXaps.Contains(xap))
                   {
                       var dc = new DeploymentCatalog(xap);
                       dc.DownloadCompleted += (s, e) =>
                           {
                               if (e.Error != null)
                               {
                                   this.Error(e.Error);
                                   return;
                               }

                               _catalog.Catalogs.Add(dc);
                               _loadedXaps.Add(xap);
                               NavigateToPage(targetUri);
                           };
                       dc.DownloadAsync();
                   }

Maintenant que les parts sont disponibles via la propriété PageFactories (sur laquelle se trouve l’attribut Import), on peut appliquer un filtre en les parcourant et en comparant les métadonnées avec l’Uri de destination, jusqu’à trouver la bonne.

var pageFactory = parent.PageFactories
              .SingleOrDefault((factory) => CompareUri(factory, targetUri));

private bool
               CompareUri(ExportFactory<Page, IExportPageMetadata> factory,
               Uri targetUri)
           {
               Uri uri = GetTrimmedUri(factory.Metadata.NavigateUri);
               if (!uri.IsAbsoluteUri)
                   uri = new Uri("dummy:///" + uri.OriginalString);
               return targetUri.Equals(uri);
           }

Enfin pour terminer, on instancie la propriété Value de pageFactory pour obtenir la Page. Le résultat est passé au ContentLoaderBaseAsync, via lequel on peut appeler le callback et retourner la Page.

Vous voilà sur la page demandée.

Après avoir vu, une partie du code de David Poll, nous allons voir comment faire évoluer tout ca pour charger non pas une page, mais un module complet. Un module peut notamment contenir un ViewModel dans le cas où vous appliquez le pattern MVVVM, des parts supplémentaires…

Dans l’exemple de David, le contrat MEF était basé sur le type Page. Dans le cas d’un module, nous allons créer une classe de base ModuleBase qui nous servira de contrat, c’est à dire Import(typeof(ModuleBase)) et Export(typeof(ModuleBase)).

Comme pour l’attribut d’export de page, nous allons créer un attribut personnalisé héritant de ExportAttribute et dans lequel nous allons spécifier qu’il peut embarquer des métadonnées. Cela nous permet notamment de simplifier l’écriture des exports.

[MetadataAttribute]
   [AttributeUsage(AttributeTargets.Class,
       AllowMultiple = false, Inherited = true)]
   public class ExportModuleAttribute : ExportAttribute
   {
       public string NavigateUri { get; private set; }
       public ExportModuleAttribute(string navigateUri)
           : base(typeof(ModuleBase))
       {
           if (string.IsNullOrEmpty(navigateUri))
               throw new ArgumentNullException(navigateUri);

           this.NavigateUri = navigateUri;
       }
   }

Vous constaterez que nous nous appuyons toujours sur la NavigateUri. Enfin pour que côté client on puisse parcourir les métadonnées sur une base typée et non au travers d’un dictionnaire, nous ajoutons une interface IExportModuleMetadata dans laquelle on peut ajouter une partie ou la totalité des propriétés présentes dans ExportModuleAttribute selon le besoin. Ces propriétés doivent être des propriétés readonly, i.e. seulement avec un getter.

Comment fonctionne la classe abstraite ModuleBase?

public ModuleBase(CompositionContainer rootContainer)
{
    if (rootContainer == null)
        throw new ArgumentNullException("rootContainer");

    AggregateCatalog aggregateCatalog = new AggregateCatalog();

    FilteredCatalog filteredCatalog =
        new FilteredCatalog(rootContainer.Catalog,
            p => p.Metadata
                .ContainsKey(
                CompositionConstants.PartCreationPolicyMetadataName)
                &&
          ((CreationPolicy)
          p.Metadata[CompositionConstants
            .PartCreationPolicyMetadataName])
          == CreationPolicy.Shared);

    //Pour permettre la découverte des parts composants l'assembly courante;
    AssemblyCatalog assCatalog =
        new AssemblyCatalog(this.GetType().Assembly);

    aggregateCatalog
        .Catalogs.Add(filteredCatalog);
    aggregateCatalog
        .Catalogs.Add(assCatalog);

    ChildContainer =
        new CompositionContainer(aggregateCatalog, rootContainer);

    Initialize();
}

ModuleBase prend en argument de son constructeur un CompositionContainer. Ce conteneur correspond à un conteneur global. Il permet de fournir des parts qui se trouve pas dans le module mais à un niveau plus haut.

Comme vous pouvez le voir, nous créons un conteneur enfant. Pour la création de ce conteneur, nous nous servons de deux catalogues.

• Le premier, AssemblyCatalog, que l’on voit souvent permettra de découvrir les parts présentes uniquement dans le module.
• Quant au second il s’agit d’un catalogue filtré. En effet ce catalogue permettra de découvrir toutes les parts mises à disposition par le catalogue du root container ayant pour Policy: Shared.

Finalement, nous appelons la méthode Initialize qui est une méthode abstraite et qui doit par conséquent être obligatoirement surchargée par toute classe héritant de ModuleBase.

ModuleBase possède également une méthode GetPage qui sera appelée par le MEFContentLoader pour récupérer la page correspondant à ce module, une fois le module initialisé.

protected abstract void Initialize();
public abstract Page GetPage();

Reprenons le cas de la page ListePersonnes et adaptons le pour fonctionner dans le cadre d’un module.

Première chose à faire, créer une classe Module et la définir comme étant un Export ModuleBase.

 [ExportModule("/MyPage")]
 public class Module : ModuleBase

ModuleBase a un constructeur prenant un CompositionContainer, nous devons donc lui ajouter un constructeur avec un conteneur qui ensuite va appeler le constructeur de la classe de base

[ImportingConstructor]
       public Module([Import("RootContainer")]
               CompositionContainer rootContainer)
           : base(rootContainer)
       {
       }

ImportingContructor permet de dire au conteneur chargé de faire la résolution de cette part, qu’il doit utiliser ce constructeur. Si on n’ajoute pas cet attribut et qu’il n’y a pas de constructeur par défaut, MEF ne saura pas quoi faire.

L’argument rootContainer est également une part dans notre exemple, puisqu’il possède un attribut Import avec un contrat portant sur la string “RootContainer”. Si le conteneur qui fait la résolution de ce module a bien un export avec ce contrat, le CompositionContainer sera passé au constructeur.

On a vu que ModuleBase avait deux méthodes abstraites.

• Initialize, dans laquelle nous créons et ajoutons une nouvelle part nécessaire au ViewModel de ce module. Notez l’utilisation du ChildContainer qui est créé par la classe de base et mis à disposition via une propriété.

protected override void Initialize()
{
       var ctx = new PersonneDomainContext();
       ChildContainer
        .ComposeExportedValue<PersonneDomainContext>(ctx);
 }

• GetPage, dans laquelle on demande au conteneur enfant de faire la résolution de la page.

public override Page GetPage()
{
           return ChildContainer
               .GetExport<ListePersonnes>().Value;
}

Comme la page ListePersonnes contient elle aussi un Import correspondant à un ViewModel, le conteneur enfant se chargera d’en faire également la résolution et Idem pour toute part nécessaire au ViewModel.

[Export]
   public partial class ListePersonnes : Page,
       IPartImportsSatisfiedNotification,
       IDisposable
   {
      Import(typeof(IPersonnesViewModel))]
      public IPersonnesViewModel PersonnesViewModel { get; set; }

       public ListePersonnes()
       {
           InitializeComponent();
       }

       // Executes when the user navigates to this page.
       protected override void
           OnNavigatedTo(NavigationEventArgs e)
       {
       }

       public void OnImportsSatisfied()
       {
           this.DataContext = PersonnesViewModel;
       }

       public void Dispose()
       {
 //Disposer les ressources créées dans cette classe
//Cette méthode sera appelée par MEF, quand la part sera détruite
       }
   }

Dernier point qu’il nous reste à voir avant de terminer ce billet, MefContentLoader, qui nécessite quelques changements pour supporter les modules.

Au même titre que nous avions une propriété PageFactories, nous allons ajouter une propriété ModuleFactories pour mettre à disposition l’ensemble des modules.

[ImportMany(AllowRecomposition = true)]
       public IEnumerable<ExportFactory<ModuleBase, IExportModuleMetadata>>
           ModuleFactories { get; set; }

Toute la partie téléchargement de fichier xap ne change pas.

Pour terminer, on filtre les modules pour trouver celui correspondant à l’Uri de navigation, puis on l’instancie si il s’agit de la première fois, ou on le récupère depuis un dictionnaire chargé de stocker les modules une fois créés. Enfin on appelle la méthode GetPage qui retourne la page et la passe au ContentLoaderBase qui va utiliser IAsyncResult pour appeler le callback et fournir le résultat.

var moduleFactory =
   parent.ModuleFactories
      .SingleOrDefault((factory) => CompareModuleUri(factory, targetUri));
if (moduleFactory != null)
{
   ModuleBase module = null;

   if (!loadedModule.ContainsKey(targetUri))
   {
          var mod = moduleFactory.CreateExport();
           module = mod.Value;
           loadedModule.Add(targetUri, module);
   }
   else
   {
          module = loadedModule[targetUri];
   }
   Complete(module.GetPage());
}

Vous trouverez l’intégralité des sources de ce billet ici

Comment gérer l’utilisation d’une ObservableCollection<T>, lors du développement d’un ItemsControl personnalisé.

Créez un “Custom control WPF” et faites le hériter de ItemsControl. Une fois cette étape réalisée , vous devriez pouvoir surcharger la méthode OnItemsChanged:

protected override void
          OnItemsChanged(NotifyCollectionChangedEventArgs e)
      {
          base.OnItemsChanged(e);
      }

Comme vous le remarquerez cette méthode prend en paramètre un élément de type NotifyCollectionChangedEventArgs. Ce type contient les propriétés suivantes.

Parmi celles-ci, une en particulier nous intéresse ici. Il s’agit de Action. En effet cette propriété permet de savoir quelle est l’action à l’origine de la modification de la collection source bindée au ItemsSource de notre ItemsControl. La propriété Action peut avoir une valeur différente pendant la durée de vie du contrôle.

• Add
• Move
• Remove
• Replace
• Reset

A partir de là vous pouvez choisir du traitement à effectuer.

Prenons pour l’exemple les actions Reset et Add

• Reset: on se trouve dans cet état, notamment lorsque l’ItemsControl est chargé pour la première fois. Pour initialiser correctement notre contrôle, nous devons donc travailler sur l’ensemble des Items disponibles via la propriété “Items” d’un ItemsControl
• Add: on a ce niveau d’action lorsque un ou plusieurs Items sont ajoutés à la collection source. Cette fois nous souhaitons travailler seulement avec les nouveaux items. Ceux-ci sont disponibles via la propriété NewItems de NotifyCollectionChangedEventArgs.

En résumant les deux cas que nous venons de voir on pourrait créer une méthode commune prenant une collection d’Items permettant de les initialiser:

protected override void
    OnItemsChanged(NotifyCollectionChangedEventArgs e)
{
   switch(e.Action)
   {
       case NotifyCollectionChangedAction.Add:
           ProcessItems(e.NewItems);
           break;
       case NotifyCollectionChangedAction.Reset:
           ProcessItems(Items);
           break;
   }
}

private void ProcessItems(IEnumerable items)
{ 

}

Pour commencer, créons une librairie que l’on nommera “Styles” pour l’exemple et dans laquelle on ajoute un premier dictionnaire de ressource, “Brush.xaml”.

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

</ResourceDictionary>

Ajoutons lui un Brush par exemple pour définir le rouge par défaut à utiliser, en indiquant le code couleur ainsi qu’une “Key” pour identifier la ressource.

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<SolidColorBrush x:Key="DefaultRedColor" Color="Red" />
</ResourceDictionary>

Maintenant que ce brush est créé, nous souhaitons l’utiliser. Pour cela nous allons prendre deux exemples d’utilisation.

• 1- Dans une application WPF
• 2- Dans une librairie de UserControls

1- Application WPF

Comme vous le savez les styles peuvent être créés en tant que ressources utilisables à un niveau donné: UserControl, Application… Nous avons fait le choix de les créer dans une librairie externe et nous voulons maintenant les mettre à disposition au niveau de l’application. Pour ce faire, ouvrez le fichier App.xaml, puis référencez “Brush.xaml”

<Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/Styles;component/Brush.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

ResourceDictionary.MergedDictionaries vous permet de spécifier un ensemble de dictionnaires, internes ou externes à  l’application hôte.

Si maintenant vous ajoutez un élément TextBlock dans le UserControl principale avec comme Style la Ressource “DefaultRedColor”, vous devriez voir votre la font devenir rouge, dans l’éditeur comme au Runtime.

<TextBlock Text="Exemple de texte rouge"
                   Foreground="{StaticResource DefaultRedColor}"
                   HorizontalAlignment="Center"/>

Au même titre que ce que nous venons de faire, ajoutons un deuxième dictionnaire de ressources, mais cette fois pour y définir le style par défaut de l’ensemble des boutons de l’application.

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Style TargetType="{x:Type Button}">
        <Setter Property="Width" Value="150"/>
        <Setter Property="Height" Value="25" />
        <Setter Property="Content" Value="This is my content"/>
    </Style>
</ResourceDictionary>

Comme vous pourrez le remarquer, l’élément style n’a pas de Key, ce qui indique que les boutons se trouvant dans le champs d’application auront ce style par défaut.

Comme pour “Brush.xaml”, vous avez juste à référencer Button.xaml dans le App.xaml et le tour est joué.

 <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/Styles;component/Brush.xaml" />
                <ResourceDictionary Source="/Styles;component/Button.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

Ajoutez un bouton et vous devriez maintenant avoir le visuel suivant dans votre éditeur:

<StackPanel Orientation="Vertical">
        <TextBlock Text="Exemple de texte rouge"
                   Foreground="{StaticResource DefaultRedColor}"
                   HorizontalAlignment="Center"/>
        <Button Content="Button - App2" />
    </StackPanel>

2- Librairie de UserControls

Ajoutons dans ce projet un UserControl complètement inutile, contenant deux “Button” et un “TextBlock” en précisant comme on l’a fait dans l’application hôte un foreground pour le “TextBlock”, le texte par défaut pour le premier bouton et un texte personnalisé pour le second.

 <StackPanel Orientation="Vertical" Grid.Column="1">
        <TextBlock   Text="Mon UserControl" FontSize="24"
                   HorizontalAlignment="Center"
                   Foreground="{StaticResource DefaultRedColor}"/>
        <Button  />
        <Button Content="Button 2"/>
    </StackPanel>

Alors à juste titre, vous allez me dire: oui mais la police reste noire.

C’est là que la petite astuce entre en jeu.

Ouvrez la solution sous Blend 4, puis votre fichier xaml correspondant au UserControl. Vous devriez voir apparaître une popup comme la suivante:

Blend vous propose une liste des Dictionnaires de ressources qu’il a trouvé dans la solution. En sélectionnant par exemple “Brush.xaml”, Blend va ajouter au dossier “Properties” du projet un fichier par défaut caché sous VS2010, nommé “DesignTimeResources.xaml”. Comme son nom le laisse présager, il est maintenant possible d’éditer votre UserControls avec les Styles créés dans la librairie “Styles”.

DesignTimeResources.xaml:

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source="/Styles;component/Brush.xaml"/>
        <ResourceDictionary Source="/Styles;component/Button.xaml"/>
    </ResourceDictionary.MergedDictionaries>
    <!-- Les entrées du dictionnaire de ressources sont définies ici. -->
</ResourceDictionary>

Pour tester votre UserControl, ajoutez une référence dans l’application hôte vers le projet “UserControls”, puis insérez le UserControl.

<Window x:Class="SharedStyles_App2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:uc="clr-namespace:UserControls;assembly=UserControls"
        Title="MainWindow" Height="350" Width="525">
    <StackPanel Orientation="Vertical">
        <TextBlock Text="Exemple de texte rouge"
                   Foreground="{StaticResource DefaultRedColor}"
                   HorizontalAlignment="Center"/>
        <Button Content="Button - App2" />
        <uc:MyUserControl />
    </StackPanel>
</Window>

Téléchargez les sources ici

Dans cette première partie, nous resterons simple à savoir pas de xap chargés à la demande…, juste deux pages:

• La première affichera “Runtime Home View” si l’application est en cours d’exécution ou “DesignTime Home View” si nous sommes dans l’éditeur VS 2010 ou sous Blend.
• La seconde listera des entités “Personne” avec un Id, un Nom et un Prénom, via un DataGrid.

A noter également, que pour l’exemple, nous partirons du principe que l’application silverlight est capable de récupérer la liste des Personnes via les RIA Services. Nous ne verrons pas la partie serveur ici, cela serait hors sujet.

C’est parti !!

Dans le projet Silverlight, vous devriez avoir un dossier “Views”. Ajoutez-y deux pages silverlight. Nommez la première Home.xaml et la seconde ListePersonnes.xaml. Pour vérifier qu’il s’agit bien d’une Page, vous pouvez regarder dans le code-behind que nos deux contrôles héritent bien de Page.

Normalement, vous devriez avoir également un UserControl déjà créé avec pour nom “MainPage.xaml”. Dans le code xaml de ce fichier vous trouverez l’élément Navigation:Frame, ainsi que l’UriMapper qui avec son IContentLoader par défaut permet de faire correspondre une Uri à une page xaml.

<navigation:Frame x:Name="ContentFrame"
       Style="{StaticResource ContentFrameStyle}"
       Source="/Home"
       Navigated="ContentFrame_Navigated"
       NavigationFailed="ContentFrame_NavigationFailed">
 <navigation:Frame.UriMapper>
  <uriMapper:UriMapper>
   <uriMapper:UriMapping Uri="" MappedUri="/Views/Home.xaml"/>
   <uriMapper:UriMapping Uri="/{pageName}" MappedUri="/Views/{pageName}.xaml"/>
  </uriMapper:UriMapper>
 </navigation:Frame.UriMapper>
</navigation:Frame>

Comme vous pouvez le voir, au lancement de l’application nous pointerons vers la page Home. Nous naviguerons également vers cette page, si aucune Uri n’est précisée. Pour toutes les autres Uri, on part du principe qu’elles se trouvent là où l’on vient de les créer, à savoir dans le dossier Views.

Toujours dans l’application Silverlight, ajoutez un autre répertoire que l’on va appeler ViewModel, puis ajoutez-y simplement deux classes que l’on nommera HomeViewModel et ListePersonnesViewModel. Comme dans tous nos projets utilisant un ViewModel, nous allons nous appuyer sur une classe de base “ViewModelBase*”, pour pouvoir notifier l’UI lors de la modification d’une propriété du ViewModel.

*ViewModelBase sera présente dans les sources.

public class HomeViewModel : ViewModelBase
{
    public HomeViewModel()
    {

    }
}

Avant de modifier le contenu de HomeViewModel et de ListePersonnesViewModel, nous allons également ajouter un contrat via une interface à ces deux ViewModels.

L’interface va nous permettre :

• de créer deux implémentations de chaque ViewModel. Une fonctionnant au runtime et la seconde au designtime.
• de définir nos ViewModels en tant  qu’export. Avec MEF, un élément ayant un attribut Export est une Part fournissant un service. Nous verrons un peu plus loin, comment consommer ce service et faire la résolution du ViewModel en question.

[Export(typeof(IHomeViewModel))]
public class HomeViewModel: ViewModelBase, IHomeViewModel

[Export(typeof(IPersonnesViewModel))]
public class PersonnesViewModel : ViewModelBase, IPersonnesViewModel

Dans le code de nos interfaces, nous allons ajouter les propriétés et méthodes qu’on aura en commun dans les deux ViewModels.

Par exemple pour IPersonnesViewModel on a:

public interface IPersonnesViewModel
    {
        void LoadData();
        ObservableCollection<Personne> Personnes { get; set; }
    }

Pour les ViewModels utilisés lors du DesignTime, préfixez vos ViewModels par Design pour faciliter la compréhension.

Le Framework MEF contient une interface IPartImportsSatisfiedNotification avec une méthode OnImportsSatisfied appelée dès que tous les Imports de la Part qui l’implémente sont satisfaites. Il peut s’agir d’un Import lié à une propriété ou encore d’un service injecté via le constructeur avec l’attribut ImportingConstructor.

De manière à ce que nos ViewModels puissent faire appel à tout service une fois l’importation terminée, nous allons donc les faire implémenter cette interface.

HomeViewModel:

[Export(typeof(IHomeViewModel))]
    public class HomeViewModel: ViewModelBase, IHomeViewModel,
        IPartImportsSatisfiedNotification
    {
        public HomeViewModel()
        {
        }

        public void OnImportsSatisfied()
        {
            LoadData();
        }

        public void LoadData()
        {
            Message = "Runtime Home View";
        }

        private string message;
        public string Message
        {
            get { return message; }
            set
            {
                message = value;
                RaisePropertyChanged(() => Message);
            }
        }
    }

PersonnesViewModel:

[Export(typeof(IPersonnesViewModel))]
   public class PersonnesViewModel : ViewModelBase, IPersonnesViewModel,
       IPartImportsSatisfiedNotification
   {
       private readonly PersonneDomainContext ctx;

       //Dependency Injection
       [ImportingConstructor]
       public PersonnesViewModel(PersonneDomainContext ctx)
       {
           if (ctx == null)
               throw new ArgumentNullException("ctx");

           this.ctx = ctx;
           Personnes = new ObservableCollection<Personne>();
       }

       public void OnImportsSatisfied()
       {
           LoadData();
       }

       public void LoadData()
       {
           ctx.Load(ctx.GetPersonnesQuery(), (op) =>
               {

                   if (op.Error == null)
                   {
                       foreach (var p in op.Entities)
                           personnes.Add(p);

                   }
               }, false);
       }

       private ObservableCollection<Personne> personnes;
       public ObservableCollection<Personne> Personnes
       {
           get { return personnes; }
           set
           {
               personnes = value;
               RaisePropertyChanged(() => Personnes);
           }
       }
   }

Vous remarquerez que dans le cas de PersonnesViewModel, on fait appel au DomainContext PersonneDomainContext injecté via le constructeur pour récupérer les données à fournir à la vue.

Comme nous venons de le faire avec les ViewModels, nous allons ouvrir le code-behind de nos Vues Home.xaml et ListePersonnes.xaml et leur faire implémenter également l’interface IPartImportSatisfiedNotification.

Comme nous souhaitons associer à chacune de ces vues, un ViewModel pour qu’elles aient des données à afficher. Nous allons donc ajouter un Import basé sur IHomeViewModel dans Home.xaml.cs et un Import basé sur IPersonnesViewModel dans ListePersonnes.xaml.cs. Une fois ceux-ci satisfaits, la méthode OnImportSatisfied sera appelée et l’association avec le DataContext pourra se faire.

Comment demander à MEF de satisfaire tous ces imports que nous venons de voir.

Avec silverlight 4, la demande de chargement d’une page est faite par le ContentLoader par défaut, PageResourceContentLoader qui fait le mapping entre une Uri et une page.

De manière à satisfaire les Imports, nous allons utiliser dans ce premier billet la classe CompositionInitializer et sa méthode SatisfyImports au niveau du constructeur de nos pages.

public partial class Home : Page,
       IPartImportsSatisfiedNotification
   {
       [Import(typeof(IHomeViewModel))]
       public IHomeViewModel HomeViewModel { get; set; }

       public Home()
       {
           InitializeComponent();

           CompositionInitializer.SatisfyImports(this);

       }

       // Executes when the user navigates to this page.
       protected override void OnNavigatedTo(NavigationEventArgs e)
       {
       }

       public void OnImportsSatisfied()
       {
           this.DataContext = HomeViewModel;
       }
   }

Attention cependant il y a quelques contraintes:

• CompositionInitializer utilise par défaut un conteneur qu’il créé lui même et seuls les assemblages présents dans le xap courant seront découverts
• Toutes les Parts créées via CompositionInitializer sont gardées jusqu’à ce que l’application soit fermée.
• Vous ne pouvez pas appliquer la méthode SatisfyImports sur des Parts utilisant l’attribut ExportAttribute.

On peut déjà palier au premier problème en combinant l’utilisation du CompositionInitializer avec la classe CompositionHost et sa méthode SatisfyImports et ainsi avoir le contrôle total sur MEF.

Pour cela nous allons ajouter quelques lignes de code dans le handler Application_Startup du fichier App.xaml.cs.

AggregateCatalog catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DeploymentCatalog());
container = new CompositionContainer(catalog);
CompositionHost.Initialize(container);
CompositionInitializer.SatisfyImports(this);

Application.Current.RootVisual = MainPage;

Ici nous créons notre propre conteneur et nous lui passons en paramètre un catalogue de type AggregateCatalog. Ce type de catalogue peut contenir des catalogues différents dont le DeploymentCatalog utilisé dans notre exemple avec son constructeur par défaut pour indiquer que MEF peut découvrir les parts du xap courant.

Ensuite, nous appelons la méthode Initialize de CompositionHost en lui passant le conteneur tout juste créé. Comme cette méthode ne peut être appelée qu’une seule fois, il est préférable de l’utiliser dans l’application hôte comme nous venons de le faire ici.

Dernier point à voir, l’édition des vues. L’utilisation des éditeurs VS ou Blend n’est pas incompatible avec la mise en place du pattern MVVM. Pour cela nous avions créés des ViewModels pouvant être utilisés au moment du design.

Pour les utiliser vous avez juste à initialiser le DataContext  spécifique au mode design et le tour est joué.

d:DataContext="{d:DesignInstance local:DesignPersonnesViewModel,
                IsDesignTimeCreatable=True}"

Dans le prochain billet, nous verrons comment adapter ce code dans une situation on l’on voudrait que chaque page soit stockée dans un fichier xap différent téléchargé à la demande.

Vous pouvez télécharger l’exemple complet ici

Lors de la création de votre DomainService, celui-ci peut être généré automatiquement notamment si votre model s’appuie sur EntityFramework.

Une fois la génération faite, si vous ouvrez le DomainService où se trouve le code , vous remarquerez que le nom des méthodes suit une règle à savoir: le nom de l’action, puis le nom de l’entité concernée.

En admettant que vous développez un DomainService pour la gestion des Clients, vous aurez les méthodes suivantes:

• InsertClient(Client client)
• UpdateClient(Client client)
• DeleteClient(Client client)

Bien que cette règle ne soit pas compliquée à retenir, vous pouvez choisir de nommer vos méthodes comme vous le souhaitez et utiliser un des attributs suivants:

• [delete]
• [insert]
• [update]

Si vous compilez votre application maintenant, vous aurez côté client un fichier auto généré contenant le DomainContext chargé de communiquer avec le DomainService coté serveur. Mais attention petite surprise, ce fichier ne contient pas les méthodes Insert / Update et Delete Client. Vous n’avez donc pas la possibilité de les appeler directement depuis le code client.

Comment procéder ?

Les RiaServices utilisent un système pour traquer les changements. Dès lors, il ne vous reste plus qu’à utiliser les méthodes Add / Remove ou à modifier tout simplement les propriétés de votre objet, pour enfin appeler la méthode SubmitChanges qui se chargera d’appeler la méthode adéquate coté serveur.

Ex d’insertion: MonDomainContext.Clients.Add(new Client {….});

Ex de suppression: MonDomainContext.Clients.Remove(client);

Ex de modification: client.Prenom = “Alexandre”

Ex de sauvegarde: MonDomainContext.SubmitChanges(….);

Dans votre DomainService, vous pouvez toujours ajouter les méthodes que vous souhaitez sans les attributs cités ci-dessus afin de les appeler directement côté client, mais vous  si vous tentez de faire un SubmitChanges après un Add ou un Remove, vous obtiendrez une exception vous disant que cette entité ne gère pas l’opération.

Nous avons la possibilité de redéfinir ce Template par défaut. Imaginons que nous souhaitions modifier le Template d’un bouton et lui ajouter un border. Ce border doit avoir un background bleu quand il contient le mot garçon et un background rouge quand il s’agit d’une fille. Oui je sais l’exemple est très simple, mais c’est juste pour mettre en avant notre DataTrigger.

La première fois que j’ai créé le Template correspondant à ce scénario, je l’ai écris comme le code suivant:

<ControlTemplate x:Key="MyButtonTemplate" TargetType="{x:Type Button}">
 <Border
    Name="Border"
    CornerRadius="5" Background="LightBlue"
    Width="{TemplateBinding Width}"
    Height="{TemplateBinding Height}">
 <ContentPresenter HorizontalAlignment="Center" VerticalAlignment="Center"/>
 </Border>
 <ControlTemplate.Triggers>
  <DataTrigger Binding="{Binding Path=Content,
       RelativeSource={RelativeSource Mode=TemplatedParent}}" Value="fille”>
   <Setter TargetName="Border" Property="Background" Value="Red"/>
  </DataTrigger>
 </ControlTemplate.Triggers>
</ControlTemplate>

La partie qui nous intéresse dans le code, c’est le DataTrigger.

L’élément DataTrigger se trouvant, dans le ControlTemplate, je pensais pouvoir utiliser comme RelativeSource Mode, TemplatedParent. Après l’ajout de deux boutons et l’exécution de l’application, vous remarquerez par vous même que cela ne fonctionne pas.

En réalité pour que cela puisse fonctionner, il vous faudra passer par un autre Mode de RelativeSource, le RelativeSource = Self. TemplatedParent est seulement utilisable dans la section principale, mais pas dans la section triggers.

<ControlTemplate.Triggers>
  <DataTrigger Binding="{Binding Path=Content,
     RelativeSource={RelativeSource Mode=Self}}" Value="fille">
   <Setter TargetName="Border" Property="Background" Value="Red"/>
  </DataTrigger>
</ControlTemplate.Triggers>

Le code est disponible ici.

Lorsqu’on parle de résolution du couple View / ViewModel, on pense de suite à deux approches: ViewModel First et View First.

Pour continuer à utiliser l’ensemble des fonctionnalités de Blend 4 ou du designer VS 2010, il faut nous tourner vers la seconde approche. Nous aurons donc la vue créée dans un premier temps, puis le ViewModel.

Pour  y parvenir la plus simple manière est d’ajouter le ViewModel en tant que Static Ressource dans le code XAML. En faisant ainsi, vous aurez une application fonctionnelle.

Cependant, on peut faire plusieurs reproches avec ce modèle.

• La View et le ViewModel sont fortement liés
• Vous ne pouvez pas injecter de service via le constructeur du ViewModel.
• Vos données ne sont pas spécifiques au mode design et vous devez utiliser celles qu’apporte le ViewModel via un service quelconque avec les contraintes existantes, comme par exemple un service non disponible.

Pour contourner ces problèmes, une solution possible est de passer par un ViewModel Locator et de faire appel à un conteneur comme Unity ou MEF pour faire la résolution de notre ViewModel. 

Il  existe également une seconde approche que j’ai pu voir sur le Blog de Shawn Wildermuth, dans laquelle il utilise MEF dans le code behind de sa vue. La seule contrainte que je vois ici est le fait qu’il utilise MEF, mais sans donner la possibilité de changer facilement de conteneur

Mais revenons  à la première solution, le ViewModel Locator. Son but est de faire la résolution de nos ViewModels. Afin qu’il soit le plus générique possible, nous allons faire en sorte que le ViewModel Locator, puisse utiliser potentiellement un resolver quelconque. Dans ce billet il est représenté par son interface IViewModelResolver. Elle possède une méthode Resolv prenant en paramètre un nom de ViewModel pour la résolution et retourne un ViewModelBase dont tous les ViewModels de ce projet héritent.

public interface IViewModelResolver
   {
       ViewModelBase Resolve(string viewModelName);
   }

Afin de préciser au locator le ViewModel que l’on souhaite associer à la vue, nous allons également nous appuyer sur une propriété indexée qui prendra en paramètre le nom du ViewModel à résoudre.

public class ViewModelLocator
    {
        public ViewModelLocator()
        {
        }

        public IViewModelResolver Resolver { get; set; }

        public object this[string viewModelName]
        {
            get
            {
                return Resolver.Resolve(viewModelName);
            }
        }
    }

Le ViewModel Locator étant terminé, passons au développement d’un resolver et plus particulièrement ici d’un MEFResolver. Comme vu ci-dessous notre resolver doit implémenter l’interface IViewModelResolver qui contient je le rappelle une méthode Resolv.

 public class MEFResolver : IViewModelResolver

Dans la solution jointe à ce billet, vous pourrez voir dans les propriétés du projet MVVMTemplate.ViewModel qu’une fois la compilation terminée, la dll est copiée dans un répertoire nommé MVVM_Bin. Pour cela, notre MEFResolver va créer un DirectoryCatalog pointant sur ce répertoire. 

var catalog = new AggregateCatalog();
           catalog.Catalogs.Add(new DirectoryCatalog(DirectoryPath));
           var mefContainer = new CompositionContainer(catalog);

Enfin avant d’appeler la méthode SatisfyImports, nous devons également ajouter une propriété, décorée de l’attribut ImportMany.

[ImportMany(typeof(ViewModelBase),
    RequiredCreationPolicy = CreationPolicy.NonShared)]
public IEnumerable<Lazy<ViewModelBase, IViewModelMetadata>>
    LazyViewModels { get; set; }

En y regardant d’un peu plus près, plusieurs points sont à mettre en avant ici.

• L’attribut ImportMany sert à spécifier au conteneur MEF qu’il doit remplir la collection avec tous les Exports basés sur le type ViewModelBase
• L’interface IViewModelMetadata qui a une propriété Name indique que nos Export ont des métadonnées associées.
• Le type Lazy signifie que l’on diffère l’instanciation des ViewModels. Cependant les métadonnées, sont accessibles.
• La propriété RequiredCreationPolicy = CreationPolicy.NonShared dit qu’à chaque nouvel appel à une part, une nouvelle instance sera créée.

Une fois ces étapes réalisées, nous pouvons appeler la méthode SatisfyImportOnce du conteneur pour charger les différentes Parts

mefContainer.SatisfyImportsOnce(this);

Dernière étape pour que notre resolver soit complet, implémenter la méthode Resolv que contient l’interface IViewModelResolver. Comme les métadonnées sont accessibles, nous allons nous aider de linq pour les parcourir et récupérer le viewModel correspondant.

public ViewModelBase Resolve(string viewModelName)
       {
          var lazyVM = LazyViewModels
               .Where(p => p.Metadata.Name == viewModelName)
               .FirstOrDefault();
           if (lazyVM != null)
               return lazyVM.Value;

           return null;
       }

Afin de pouvoir utiliser le ViewModel Locator, nous allons l’ajouter en tant que ressource dans App.xaml, ainsi il sera disponible à partir de l’ensemble des vues de l’application. Nous allons également en profiter pour spécifier au Locator que l’on souhaite utiliser le resolver MEFResolver que l’on vient tout juste de créer.

 <Application.Resources>
        <locator:ViewModelLocator x:Key="MEFLocator">
            <locator:ViewModelLocator.Resolver>
                <resolver:MEFResolver
                    DirectoryPath="MyPath"   />
            </locator:ViewModelLocator.Resolver>
        </locator:ViewModelLocator>
    </Application.Resources>

Pour associer un viewModel à une vue, il vous reste juste à renseigner sa propriété DataContext. Prenons pour exemple la fenêtre principale de notre application.

<Window x:Class="MVVMTemplate.MainView"
             DataContext="{Binding Source={StaticResource MEFLocator},
                            Path=[MainViewModel]}">

Comme vous pouvez le remarquer, on indique “MainViewModel” au niveau de la propriété Path. Alors vous allez me dire et la classe ViewModel où est-elle ? Justement j’allais y venir !

De manière à fournir au designer VS 2010 et à Blend des données, nous allons créer deux ViewModels distincts.  On pourrait en utiliser qu’un seul et s’appuyer sur les méthodes permettant de détecter si on  est en mode design ou pas, mais personnellement, je trouve que le ViewModel devient illisible.

Pour définir nos deux ViewModels, nous allons donc:

• définir une interface IMainViewModel sur laquelle ils vont s’appuyer pour connaître les opérations qu’ils doivent implémenter. Dans notre cas ca va être très simple puisqu’elle contient une seule propriété nommée Name.

public interface IMainViewModel
   {
       string Name { get; set; }
   }

• Les faire hériter d’une classe de base nommée ViewModelBase qui implémente notamment l’interface INotifyPropertyChanged.
• Ajouter deux attributs, en rapport avec le fait que l’on souhaite passer par un resolver MEF.
  • PartCreationPolicy, pour préciser qu’il ne s’agit pas d’un ViewModel partagé, mais qu’une nouvelle instance devra être créée.

    [PartCreationPolicy(CreationPolicy.NonShared)

  • ViewModelExport qui correspond à un attribut d’export personnalisé, qui englobe les métadonnées. Pour plus d’informations sur ce point, je vous redirige sur un des derniers billets que j’ai écris.

    [ViewModelExport(Name = "MainViewModel")]

    [MetadataAttribute]
       [AttributeUsage(AttributeTargets.Class,
           AllowMultiple = false, Inherited = true)]
       public class ViewModelExport : ExportAttribute
       {
           public string Name { get; set; }
    
           public ViewModelExport()
               : base(typeof(ViewModelBase))
           {
           }
       }

Au niveau de la métadonnée, vous pouvez voir que l’on retrouve le nom “MainViewModel”.

Voici le ViewModel complet.

[PartCreationPolicy(CreationPolicy.NonShared)]
    [ViewModelExport(Name = "MainViewModel")]
    public class MainViewModel : ViewModelBase, IMainViewModel
    {
        //[ImportingConstructor]
        public MainViewModel()
        {
            this.Name = "MainViewModel Template";
        }

        private string name;
        public string Name
        {
            get { return this.name; }
            set
            {
                if (value != name)
                {
                    this.name = value;
                    base.RaisePropertyChanged<MainViewModel,
                         string>(m => m.Name);
                }
            }
        }
    }

Sur le constructeur, vous noterez  aussi la présence d’un attribut [ImportingConstructor] que j’ai mis en commentaire ici. Mais vous pouvez l’utiliser pour injecter dans le ViewModel différents services.

Le ViewModel utilisé en mode design est exactement le même excepté le texte assigné à la propriété Name et les différents attributs ici présents qu’il n’utilise pas.

Si vous lancez l’application maintenant vous devriez voir un écran comme celui-ci.

Dernier point, pour terminer ce billet, nous devons référencer le ViewModel design qui se trouve dans une autre assembly et l’ajouter en tant que type devant être utilisé pour le design avec la propriété d:DataContext

  d:DataContext="{d:DesignInstance design:DesignMainViewModel, IsDesignTimeCreatable=True}"

En procédant ainsi, vous pourrez notamment utiliser les dernières améliorations faites dans le designer de la version VS 2010 pour créer vos Binding.

Et voilà les données sont également accessibles dans VS et Blend.

Télécharger les sources.

Pour arriver à mettre en place cette petite application de démo, le DirectoryCatalog avait notamment été utilisé. 

Ce que je vous propose de voir aujourd’hui est la mise en place d’un moyen de détection pour tout ajout d’une nouvelle dll dans le répertoire extensions. Le but final étant de notifier l’utilisateur lors de cet ajout, ainsi que la mise à jour de l’interface. Pour cela, nous partons du principe que seule la dll d’export XML est présente dans le dossier. Nous ajouterons ensuite la dll d’export Excel, de manière à voir si le résultat obtenu est correcte.

Au lieu d’instancier la classe DirectoryCatalog dans le BootStrapper, je vous propose de créer une nouvelle classe que l’on appellera AutoRefreshDirectoryCatalog et qui hérite de DirectoryCatalog. Ensuite ajoutez lui la propriété NotifyOnDirectoryChanged de type bool pour indiquer si l’on souhaite activer ou désactiver la mise à jour du catalogue. Enfin mettez en place la surveillance grâce à la classe FileSystemWatcher

public class AutoRefreshDirectoryCatalog : DirectoryCatalog
   {

       public bool NotifyOnDirectoryChanged { get; private set; }

       public AutoRefreshDirectoryCatalog(string path)
           : this(path, false)
       { }

       public AutoRefreshDirectoryCatalog(string path,
           bool notifyOnDirectoryChanged)
           : base(path)
       {
           this.NotifyOnDirectoryChanged = notifyOnDirectoryChanged;

           if (notifyOnDirectoryChanged)
           {
               FileSystemWatcher fsw = new FileSystemWatcher(path, "*.dll");
               fsw.EnableRaisingEvents = true;
               fsw.Created += (s, e) =>
               {
                   MessageBox.Show("Nouvelle dll ajoutée");
                   Refresh();
               };
           }

       }

   }

Comme vous pouvez le remarquer, après avoir créé le FileSystemWatcher et avoir activé la notification , nous nous abonnons à l’event Created, qui va nous permettre de savoir dès qu’une nouvelle dll est ajoutée. Notez au passage, l’application d’un filtre “*.dll”.

Lorsque le handler lié à l’event Created est appelé, nous demandons simplement au catalogue de parcourir de nouveau le répertoire extensions et de se mettre à jour via la méthode Refresh.

Maintenant que cette classe est terminée, nous allons nous tourner à nouveau vers la classe BootStrapper où se trouve le CompositionContainer. Il possède un event Changed qui est appelé dès lors qu’un rafraichissement d’un de ses catalogues a été fait. Quel utilité me direz-vous ? Cela nous permet tout simplement de savoir quand est ce que le container est à jour et à partir de là nous pouvons mettre à jour l’interface en recréant la collection de plugins disponibles via la méthode RefreshPluginList du viewModel principal de l’application.

arCatalog.Changed += (s, e) =>
                {
                    MainViewModel.RefreshPluginList();
                };

public void RefreshPluginList()
       {
           PluginsName = new ObservableCollection<string>();

           foreach (var plugin in
               this.saveService.AvailablePlugins)
           {
               PluginsName.Add(plugin.Metadata.Name);
           }
       }

Vous pouvez maintenant lancer l’application et ajouter la dll d’export Excel dans le répertoire extensions. La première chose que vous allez voir est une message box de notification. Ensuite déroulez la liste en bas de l’application. En plus d’XML, vous devriez voir maintenant Excel.

Vous pouvez télécharger les sources  ici.

MEF est un Framework permettant de développer des applications modulaires, composées de Parts. Vous trouverez d’un côté les Parts “Export” qui fournissent des services et de l’autre les Parts “Import” qui utilisent ces services. Dans l’utilisation de MEF que j’ai pu faire jusqu’à maintenant, j’ai tendance à dire qu’on a d’un côté l’application Core et de l’autre un ensemble de plugins respectant un contrat pour chaque service attendu.

Dans ce billet, je vous propose de voir le développement de l’application core, et d’un plugin. Le second sera présent dans les sources disponibles à la fin du billet. Pour y parvenir considérons les points suivants:

• Notre application est une application de type client lourd
• Au niveau de l’UI nous affichons une liste d’objet Employee et proposons à l’utilisateur plusieurs possibilités pour exporter ses données
  • La première se fera via un fichier XML
  • La seconde quant à elle se fera vers un fichier Excel.
• L’application utilise le pattern MVVM
• Le model est constitué d’une seule entité nommée Employee.

Le but de ce billet n’est pas de voir comment implémenter MVVM avec WPF, je considère que vous savez déjà le faire. A ce titre, nous allons partir d’un projet de base avec le ViewModel principal déjà créé. Pour cela, vous pouvez utiliser le Template de création de projet suivant.

1- Création du model

Comme dit plus haut, notre model va rester simple pour la démonstration. Il sera uniquement constitué d’une entité Employee ainsi que de quatre propriétés: LastName, FirstName, Age et Job. Vous remarquerez au passage que la classe hérite de NotifiableObjectBase qui donne la possibilité de notifier le changement d’une des propriétés. (Son code sera dans le zip à la fin du billet).

Code classe Employee:

public class Employee : NotifiableObjectBase
  {
      private string lastName;
      public string LastName
      {
          get { return lastName; }
          set
          {
              if (value != lastName)
              {
                  lastName = value;
                  base.RaisePropertyChanged<string>(() => LastName);
              }
          }
      }

      private string firstname;
      public string FirstName
      {
          get { return firstname; }
          set
          {
              if (value != firstname)
              {
                  firstname = value;
                  base.RaisePropertyChanged<string>(() => FirstName);
              }
          }
      }

      private int age;
      public int Age
      {
          get { return age; }
          set
          {
              if (value != age)
              {
                  age = value;
                  base.RaisePropertyChanged<int>(() => Age);
              }
          }
      }

      private string job;
      public string Job
      {
          get { return job; }
          set
          {
              if (value != job)
              {
                  job = value;
                  base.RaisePropertyChanged<string>(() => Job);
              }
          }
      }

  }

2- MEF – Création du contrat pour les plugins.

De manière à ce qu’un plugin soit accepté par l’application, il doit respecter un contrat. En code ce contrat est représenté par une interface, qui impose donc au plugin d’implémenter les méthodes et propriétés qui y sont spécifiées.

Dans notre cas, comme nous voulons donner la possibilité à l’utilisateur d’exporter une liste de données vers un fichier Excel et XML, nous allons juste ajouter une méthode Save à notre interface.

public interface ISave
{
    void Save<T>(List<T> listToExport);
}

La méthode prend en paramètre une liste de données générique, ainsi nous pourrons par la suite, passer autre chose que des entités Employee si nécessaire.

3 – Création d’un plugin

Maintenant que le contrat est créé, nous pouvons passer à la création du plugin. Dans un premier temps, nous allons créer un seul plugin correspondant à l’export vers un fichier XML.

Pour la création du plugin, commencez par créer une nouvelle librairie. Cette librairie ne sera pas ajoutée en tant que référence dans un projet de la solution. Toutefois, nous allons spécifier une ligne de commande Post Build Event sur le projet pour que la dll finale soit copiée dans un répertoire spécifique aux plugins que nous allons nommer Extensions.

Allez dans les propriétés du projet et après avoir sélectionné l’onglet “Build Events”, ajoutez la ligne suivante:

copy “$(OurDir)”* “$(SolutionDir)MEFDemo\bin\$(ConfigurationName)\Extensions\”

Une fois cette étape réalisée, ajoutons une classe que l’on appellera SaveToXml. Faites lui ensuite implémenter l’interface ISave. Dans la méthode générique Save nous allons utiliser une librairie que j’ai développé pour la sérialisation des données.

public class SaveToXml : ISave
    {
        public void Save<T>(List<T> listToExport)
        {
            if (listToExport == null)
                throw new ArgumentNullException("listToExport");

            string currentPath = Directory.GetCurrentDirectory();
            XmlHelper.SaveDataToXml<List<T>>(
                Path.Combine(currentPath,"export.xml"),
                listToExport,
                null);
        }
    }

Encore une fois pour rester concentré sur le sujet, je ne montrerai pas ici le code de la librairie de sérialisation, mais sachez qu’il sera disponible à la fin du billet.

En plus du fait que nous ayons besoin d’utiliser un contrat pour notre plugin, le Framework MEF à besoin qu’on ajoute un attribut ExportAttribute sur notre classe pour spécifier qu’il participe en tant qu’élément dans la composition de l’application dans le cadre du contrat ISave.

 [Export(typeof(ISave))]
 public class SaveToXml : ISave

Enfin, nous allons ajouter une dernier attribut ExportMetadataAttribute qui comme son nom l’indique permet de définir des métadonnées sur notre classe. Ces métadonnées permettent d’ajouter des informations concernant le plugin également appelé Part dans le langage MEF. 

Dans notre cas nous allons juste ajouter une méta pour donner un nom et identifier facilement le plugin auquel on à faire.

[ExportMetadata("Name","xml")]
[Export(typeof(ISave))]
public class SaveToXml : ISave

Nous pourrions nous arrêter là en ce qui concerne cette Part, mais nous allons développer notre propre attribut d’export pour les raisons suivantes.

• Spécifier un seul attribut pour le contrat de l’export et les métadonnées.
• Utiliser des métadonnées fortement typées.

Pour cela notre attribut doit hériter de ExportAttribute se trouvant dans System.ComponentModel.Composition. Pour indiquer qu’il agit également comme un attribut de métadonnées, il nous faut ajouter sur notre attribut l’attribut MetadataAttribute. Enfin nous avons vu que la seule méta nécessaire ici est Name, nous allons donc ajouter une propriété Name de type string.

[MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class,
        AllowMultiple = false,
        Inherited = false)]
    public sealed class SaveExportAttribute : ExportAttribute
    {

        public SaveExportAttribute()
            : base(typeof(ISave))
        {
        }

        public string Name { get; set; }

    }

Maintenant que cela est fait, nous allons développer un service permettant d’accéder aux plugins ajoutés dans le répertoire Extensions et faire en sorte qu’il soit injecté via Unity dans le ViewModel nommé MainViewModel.

Pour que ce service soit par la suite facilement mockable, nous allons passer par une interface.

Ce que nous voulons avec ce service, c’est avoir:

• une liste des plugins existant pour l’export.
• une méthode d’export

public interface ISaveService
   {
       IEnumerable<Lazy<ISave,ISaveMetadata>> AvailablePlugins { get; set; }
       void Save<T>(string pluginName, List<T> list);
   }

Regardez la propriété AvailablePlugins.

Vous remarquerez l’utilisation du type Lazy en tant qu’élément du IEnumerable<T>.  Ce type, nouveau dans le Framework 4, permet de différer la création d’un objet.

En regardant d’un peu plus près la définition du type Lazy, on voit qu’on lui spécifie ici un deuxième type ISaveMetadata.

Mef apporte une surcharge du type Lazy, avec lequel on peut également passer des métadonnées, et c’est là tout l’intérêt de la chose. Vous pouvez parcourir les métadonnées en quête d’informations avant même que l’objet soit instancié.

Mais revenons au type ISaveMetadata. Dans notre exemple, il s’agit d’une interface dans laquelle on ajoute les données / métadonnées que l’on veut accessibles au client, ici le Name. En interne MEF, va se charger de créer un classe proxy implémentant cette interface et faire le mapping avec les métadonnées ajoutées avec ExportMetadata ou le custom attribute  SaveExportAttribute dans notre cas.

public interface ISaveMetadata
{
    string Name { get; }
}

A présent, après avoir vu la propriété AvailablePlugins, il nous reste la méthode Save à inspecter. Rien de bien compliqué en ce qui la concerne. On voit qu’il s’agit d’une méthode générique ce qui permet éventuellement de faire des exports basés sur un autre type que Employee, et qu’on lui passe en paramètre le nom du plugin qu’elle doit utiliser pour effectuer cet export.

Du côté de l’implémentation réalisée dans ce projet, on retrouve ce que l’on vient d’expliquer.

Notez quand même la présence de l’attribut ImportMany sur la propriété AvailablesPlugins pour indiquer à MEF qu’il doit découvrir toutes les Parts Export implémentant l’interface ISave

Dans la méthode Save, nous récupérons simplement le bon plugin grâce à une petite requête linq. A cet instant précis, le plugin n’est pas encore instancié. Un peu plus loin l’instance de type ISave est enfin créée via l’appel à la propriété Value. Il ne reste plus qu’à appeler la méthode qui je le rappelle se trouve au  niveau de l’interface ISave.

public class SaveService : ISaveService
   {
       [ImportMany(typeof(ISave))]
       public IEnumerable<Lazy<ISave,ISaveMetadata>>
           AvailablePlugins { get; set; }

       public void Save<T>(string pluginName, List<T> list)
       {
           var lazyPlugin = AvailablePlugins
               .FirstOrDefault(p => p.Metadata.Name == pluginName);
           if (lazyPlugin == null)
               throw new Exception("Invalid plugin name");

           //plugin instanciation
           var plugin = lazyPlugin.Value;
           if (plugin == null)
               throw new Exception("Plugin is not available");

           plugin.Save<T>(list);
       }
   }

Au début de ce billet, j’avais précisé que la démo utilisait le pattern MVVM. Pour rendre ce service accessible au ViewModel, nous allons l’injecter via Unity dans son constructeur.

public MainViewModel(IMainView mainView, ISaveService saveService)

Dans notre ViewModel, nous allons ajouter une collection de type string qui va contenir les noms des plugins disponibles. Cette liste est construite à partir des informations que le service SaveService nous fait parvenir. La vue n’aura plus qu’à se binder pour afficher une liste de ces valeurs.

foreach (var plugin in this.saveService.AvailablePlugins)
{
    PluginsName.Add(plugin.Metadata.Name);
}

<ComboBox   ItemsSource="{Binding PluginsName}" />

Enfin pour avoir quelques données à exporter, on créé également une ObservableCollection de type Employee, que la vue va afficher dans un DataGrid, et on lui ajoute des Employee, tous les même ici pour simplifier la démo.

public ObservableCollection<Employee> Employees { get; set; }

<DataGrid Grid.Row="1" ItemsSource="{Binding Employees}" />

for (int i = 0; i < 20; i++)
               Employees.Add(new Employee
               {
                   Age = 25,
                   FirstName = "Alexandre",
                   LastName = "Arnaudet",
                   Job = "Ingénieur d'études" });

Dernier  point à régler pour terminer l’UI et le ViewModel, déclencher l’appel à la méthode Save du service. Pour cela, ajoutons une ICommand dans le ViewModel que l’on va nommer SelectExportTypeCommand. Comme nous utilisons une ICommand de type RelayCommand, il nous faut également préciser le handler appelé lors de l’exécution de la commande, ainsi qu’une méthode indiquant si l’appel de la commande peut avoir lieu.

public ICommand SelectExportTypeCommand
       {
           get
           {
               if (selectExportTypeCommand == null)
                   selectExportTypeCommand =
                       new RelayCommand(
                           param => Export(param),
                           param => CanExport());

               return selectExportTypeCommand;
           }
       }

       private void Export(object param)
       {

           this.saveService
               .Save<Employee>(selectedExportPlugin,
               new List<Employee>(Employees));
       }

       private bool CanExport()
       {
           return !string.IsNullOrEmpty(SelectedExportPlugin);
       }

Au niveau de l’UI, un simple contrôle de type button utilisant sa propriété Command pour se binder sur la ICommand d’export. Voici un résumé du code XAML représentant l’UI.

<Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="30" />
            <RowDefinition Height="*" />
            <RowDefinition Height="40" />
        </Grid.RowDefinitions>
        <TextBlock Text="Demo MEF" FontSize="24"  />
        <DataGrid Grid.Row="1"
                  ItemsSource="{Binding Employees}" />
        <StackPanel Grid.Row="2"
                    Orientation="Horizontal">
            <TextBlock Text="Mode d'export:"
                       VerticalAlignment="Center" />
            <ComboBox   ItemsSource="{Binding PluginsName}"
                        Margin="5"
                        SelectedItem="{Binding SelectedExportPlugin}"
                        Width="150"/>
            <Button Content="Exporter" Margin="5"
                    Command="{Binding SelectExportTypeCommand}"/>

        </StackPanel>
    </Grid>

Avant de lancer l’application, nous allons jeter un coup d’œil à un dernier fichier nommé bootstrapper. Ce fichier est une simple classe appelée depuis App.xaml.cs au démarrage de l’application. On y configure le container unity dans le constructeur.

public BootStrapper()
       {
           container = new UnityContainer();
           UnityConfigurationSection section =
               (UnityConfigurationSection)ConfigurationManager
               .GetSection(ConfigurationManager.AppSettings["UnitySection"]);
           section.Configure(container);
       }

Dans un second temps, elle s’occupe également dans la méthode Load de faire la résolution du ViewModel principal et d’afficher la vue liée.

L’utilisation de MEF implique la création d’un CompositionContainer, dans lequel on ajoute les Parts qui vont composer l’application. Ici on s’aperçoit que le CompositionContainer est construit à partir d’un catalogue de type DirectoryCatalog qui correspond au répertoire Extensions dans lequel se trouve les dlls avec les Export. Le service SaveService qui contient une propriété AvailablePlugins avec un Attribut Import est également une Part. On utilise donc la méthode ComposePart pour le signaler au container et lui dire de satisfaire les imports présents.

internal void Load()
        {
            string directoryPath = Directory.GetCurrentDirectory();
            string fullPath =
                Path.Combine(directoryPath,
                ConfigurationManager.AppSettings["ExtensionsPath"]);

            var catalog = new AggregateCatalog();
            catalog.Catalogs
                .Add(new DirectoryCatalog(fullPath));

            var mefContainer = new CompositionContainer(catalog);
            var service = container.Resolve<ISaveService>();
            mefContainer.ComposeParts(service);

            IMainViewModel mainViewModel =
                container.Resolve<IMainViewModel>();
            mainViewModel.View.ShowView();
        }
    }

Le développement de l’application est terminé. Si vous la démarrez, vous devriez obtenir le résultat suivant avec juste un option pour l’export: xml. Vous pourrez trouver ce fichier xml dans le répertoire où l’application s’exécute.

Nous venons juste de voir que la résolution du ViewModel,  de la View et du Service était faite via Unity, mais après tout on peut très bien utiliser MEF pour réaliser cette opération.

Pour cella il suffit comme on l’a fait avec l’export xml de placer les attributs Export et Import.

• Placez l’attribut export sur le ViewModel:

[Export(typeof(IMainViewModel))]

• Placez l’attribut ImportingConstructor sur le constructor du ViewModel pour dire à MEF que ses paramètres deviennent des Import.

[ImportingConstructor]
       public MainViewModel(IMainView mainView,
           ISaveService saveService)

• Placez l’attribut Export sur la View

[Export(typeof(IMainView))]

• Placez l’attribut Export sur le SaveService

[Export(typeof(ISaveService))]

• Modifiez le bootstrapper de manière à ajouter une propriété IMainViewModel avec un Import.

[Import]
     public IMainViewModel MainViewModel { get; set; }

• Faites un ComposePart du bootStrapper pour satisfaire l’import

mefContainer.ComposeParts(this);

• Affichez la vue

if (MainViewModel != null)
                MainViewModel.View.ShowView();

Enfin avant de lancer l’application, supprimez les références vers MVVM.ViewModel, MVVM.View et MEFDemo.SaveService, et modifiez les post build event comme pour le plugin xml afin que les dlls soient déposées dans le répertoire Extensions.

Vous pouvez télécharger l’ensemble des sources ci-dessous. Vous y trouverez notamment un deuxième plugin pour l’export de la même liste de données, mais cette fois ci vers excel.

Sources et autres librairies: Télécharger.

Ce Template permet la création automatique de quatre projets:

• L’application WPF dans laquelle se trouve, un bootstrapper chargé de créer un conteneur Unity pour la résolution des différents services enregistrés dans le fichier de configuration, et la résolution du couple ViewModel / View principal.
• Un projet contenant les interfaces IMainViewModel et IMainView
• Un projet contenant le ViewModel
• Et un dernier avec la vue principale

Vous pouvez télécharger ce Template ici. Son contenu n’est réalisé qu’à titre d’exemple. Libre à vous de le modifier comme vous le souhaitez. Pour l’installer, modifiez l’extension en vsix après l’avoir téléchargé et exécutez le.

Ouvrez une ligne de commande puis:

• Allez dans un des répertoires (GAC, GAC_MSIL…) selon  l’archi
  • ex: cd windows\assembly\GAC_MSIL
• Ensuite allez dans le répertoire de l’assembly souhaitée
  • ex: cd Microsoft.VisualStudio.Zip.9.0
• Et enfin  parcourez l’arborescence jusqu’à trouver la dll recherchée
• Pour la copier faites juste un copy source destination
  • ex: copy Microsoft.VisualStudio.Zip.9.0.dll c:\

Si vous parcourez de temps en temps ce blog vous aurez peut être remarqué qu’un des derniers billets portait sur la synchronisation de listbox lors du déplacement d’une scrollbar. Dans ce billet je vous propose de voir comment atteindre le même objectif mais en utilisant cette fois une behavior, le gros avantage étant que celle-ci soit utilisable directement sous Blend par un designer.

Premier point avant de commencer à coder, si vous n’avez pas une version de Blend au moins équivalente à la version 3 installée, veuillez télécharger le sdk suivant, de manière à pouvoir ajouter une référence sur System.Windows.Interactivity.

Ensuite reprenez le projet lié au billet ci-dessus nommé et ajoutez une classe qu’on appellera ScrollSyncBehavior. Pour indiquer qu’il s’agit de la création d’une behavior, nous allons faire hériter notre classe de la classe de base Behavior<T>, T étant un DependencyObject. Dans notre cas ce DependencyObject correspond à un contrôle de type ListBox.

Une fois cette opération effectuée, surchargez les deux méthodes OnAttached et OnDetaching.

protected override void OnAttached()
{
    base.OnAttached();
}

protected override void OnDetaching()
{
    base.OnDetaching();
}

Pour cet exemple la behavior est toujours associée à un élément de type Listbox. Vous pouvez le récupérer via la propriété AssociatedObject de la classe de base.

L’élément qui permet  de faire défiler les différents items dans une ListBox est un ScrollViewer. Pour récupérer ce ScrollViewer, nous pouvons parcourir l’arborescence visuelle via la classe helper VisualTreeHelper. Comme au départ, nous ne savons pas qu’elle est la position exacte du ScrollViewer, nous allons utiliser la méthode suivante pour parcourir l’arbre de manière récursive jusqu’à ce que nous tombions dessus. Notez au passage que cette méthode pourrait être transformée pour être utilisée comme une méthode d’extension d’un DependencyObject, mais ce n’est pas le sujet ici.

public static childItem FindVisualChild<childItem>(DependencyObject obj)
           where childItem : DependencyObject
       {
           for (int i = 0; i < VisualTreeHelper.GetChildrenCount(obj); i++)
           {
               DependencyObject child = VisualTreeHelper.GetChild(obj, i);
               if (child is childItem)
                   return (childItem)child;
               else
               {
                   childItem childOfChild = FindVisualChild<childItem>(child);
                   if (childOfChild != null)
                       return childOfChild;
               }
           }
           return null;
       }

Dans la méthode OnAttached récupérez donc le ScrollViewer de l’objet associé.

this.AssociatedObject.Loaded += (s, e) =>
               {
                   ScrollViewer scrollViewer =
                       FindVisualChild<ScrollViewer>(this.AssociatedObject);

Pour la suite du code nous nous rapprochons de ce qui avait été fait dans ScrollSync. Ajoutez une DependencyProperty GroupName pour spécifier le groupe de synchronisation auquel participe la ListBox. Reprenez ensuite le code qu’on avait dans OnScrollGroupChanged et modifiez le de manière à refléter le fait qu’on ne s’appuie pas ici sur une propriété attachée pour le nom du groupe.

if (scrollViewer != null)
 {
   if (!string.IsNullOrEmpty(GroupName))
   {
     if (horizontalScrollOffsets.Keys.Contains(GroupName))
     {
        scrollViewer.ScrollToHorizontalOffset
                     (horizontalScrollOffsets[GroupName]);
     }
     else
           horizontalScrollOffsets
                 .Add(GroupName, scrollViewer.HorizontalOffset);

    if (verticalScrollOffsets.Keys.Contains(GroupName))
    {
       scrollViewer.ScrollToVerticalOffset
                   (verticalScrollOffsets[GroupName]);
    }
    else
       verticalScrollOffsets.Add(GroupName, scrollViewer.VerticalOffset);

     if (!scrollViewers.ContainsKey(scrollViewer))
     {
        scrollViewers.Add(scrollViewer, GroupName);
           scrollViewer.ScrollChanged
              += new   ScrollChangedEventHandler(ScrollViewer_ScrollChanged);
     }
   }
}

 private static void
    ScrollViewer_ScrollChanged(object sender, ScrollChangedEventArgs e)
 {
     if (e.VerticalChange != 0 || e.HorizontalChange != 0)
     {
         var changedScrollViewer = sender as ScrollViewer;
         Scroll(changedScrollViewer);
     }
 }

  private static void Scroll(ScrollViewer changedScrollViewer)
 {
   var group = scrollViewers[changedScrollViewer];
   verticalScrollOffsets[group] =
       changedScrollViewer.VerticalOffset;
   horizontalScrollOffsets[group] =
       changedScrollViewer.HorizontalOffset;

   foreach (var scrollViewer
        in scrollViewers
           .Where((s) => s.Value == group && s.Key != changedScrollViewer))
   {
     if (scrollViewer.Key.VerticalOffset
            != changedScrollViewer.VerticalOffset)
     {
       scrollViewer.Key
          .ScrollToVerticalOffset(changedScrollViewer.VerticalOffset);
     }

     if (scrollViewer.Key
          .HorizontalOffset != changedScrollViewer.HorizontalOffset)
     {
       scrollViewer.Key.
           ScrollToHorizontalOffset(changedScrollViewer.HorizontalOffset);
     }
   }
  }

La seule différence réside ensuite dans l’ajout de la méthode OnDetaching. Dans cette méthode, nous allons tout simplement nous détacher de l’event ScrollChanged et supprimer le ScrollViewer correspondant de nos listes internes.

protected override void OnDetaching()
       {
           base.OnDetaching();

           ScrollViewer scrollViewer
               = FindVisualChild<ScrollViewer>(this.AssociatedObject);
           if (scrollViewers.ContainsKey(scrollViewer))
           {
             scrollViewer.ScrollChanged
               -= new ScrollChangedEventHandler(ScrollViewer_ScrollChanged);
               scrollViewers.Remove(scrollViewer);
           }

           if (!scrollViewers.ContainsValue(GroupName))
           {
               if (horizontalScrollOffsets.ContainsKey(GroupName))
                   horizontalScrollOffsets.Remove(GroupName);

               if (verticalScrollOffsets.ContainsKey(GroupName))
                   verticalScrollOffsets.Remove(GroupName);
           }
       }

Au niveau du code xaml, supprimez la propriété attachée ajoutée au niveau des styles car elle n’a plus de raison d’exister, et ajoutez la behavior dans l’élément ListBox comme ceci.

 <ListBox Height="50">

                <i:Interaction.Behaviors>
                    <local:ScrollSyncBehavior GroupName="GroupTest"/>
                </i:Interaction.Behaviors>

i pointant sur System.Windows.Interactivity

        xmlns:i="clr-namespace:System.Windows.Interactivity;
        assembly=System.Windows.Interactivity"

Retrouvez les sources ici.

De l’autre MEF (Managed Extensibility Framework), est un Framework pour construire des applications extensibles. Il est capable de charger des plugins / DLL, depuis un endroit spécifique (assembly, répertoire …)  sans que ces derniers ne soient référencés dans le projet pour autant qu’ils respectent un contrat.

Dans sa version 4 alpha, Prism continue d’évoluer pour proposer:

• Une aide à l’implémentation du pattern MVVM
• Navigation
• Template / Code generation
• Et une Gestion de la modularité avec MEF

Pour plus d’informations voici le lien vers le blog de Blaine Wastell

Pour faire simple, notre exemple va s’appuyer sur une ListBox.

Créez une application WPF et ouvrez le code xaml de la fenêtre principale. Ajoutez ensuite deux ListBox avec dans chacune des données. Peu importe le type des données que vous choisissez.  Dans cette démo, nous allons ajouter des string en tant qu’item. Le type string est présent dans l’assembly mscorlib, il vous faut donc ajouter le namespace:

xmlns:sys="clr-namespace:System;assembly=mscorlib"

        <StackPanel Orientation="Horizontal" VerticalAlignment="Center" HorizontalAlignment="Center">
            <ListBox Height="50">
                <ListBox.Items>
                    <sys:String>Alexandre</sys:String>
                    <sys:String>Greg</sys:String>
                    <sys:String>Patrice</sys:String>
                    <sys:String>Amandine</sys:String>
                    <sys:String>Alexandre</sys:String>
                    <sys:String>Greg</sys:String>
                    <sys:String>Patrice</sys:String>
                    <sys:String>Amandine</sys:String>
                </ListBox.Items>
            </ListBox>
            <ListBox Height="50" Margin="10">
                <ListBox.Items>
                    <sys:String>Appartement</sys:String>
                    <sys:String>Appartement</sys:String>
                    <sys:String>Maison</sys:String>
                    <sys:String>Appartement</sys:String>
                    <sys:String>Maison</sys:String>
                    <sys:String>Appartement</sys:String>
                    <sys:String>Appartement</sys:String>
                    <sys:String>Maison</sys:String>
                </ListBox.Items>
            </ListBox>
        </StackPanel>

public class ScrollSync : DependencyObject
  {

      public static string GetGroupName(DependencyObject obj)
      {
          return (string)obj.GetValue(GroupNameProperty);
      }

      public static void SetGroupName(DependencyObject obj, string value)
      {
          obj.SetValue(GroupNameProperty, value);
      }

      public static readonly DependencyProperty GroupNameProperty =
          DependencyProperty.RegisterAttached("GroupName",
          typeof(string), typeof(ScrollSync),
          new UIPropertyMetadata(null,
              new PropertyChangedCallback(OnGroupNameChanged)));

      private static void
          OnGroupNameChanged(DependencyObject d,
          DependencyPropertyChangedEventArgs e)
      { }

  }

Notez la présence d’une méthode Callback OnGroupNameChanged que nous allons modifier dans quelques instants après avoir créé:

• un dictionnaire pour stocker le ScrollViewer de nos Listbox participant à la synchonisation.
• un dictionnaire pour stocker la Scroll Position horizontale d’un groupe
• un dictionnaire pour stocker la Scroll Position verticale d’un groupe.

private static Dictionary<ScrollViewer, string> scrollViewers = new Dictionary<ScrollViewer, string>();
        private static Dictionary<string, double> horizontalScrollOffsets = new Dictionary<string, double>();
        private static Dictionary<string, double> verticalScrollOffsets = new Dictionary<string, double>();

La première chose que nous allons faire dans le callback est de vérifier que la propriété attachée a bien été assignée à un élément de type ScrollViewer.

var scrollViewer = d as ScrollViewer;
if (scrollViewer != null)

Ensuite, via le paramètre DependencyPropertyChangedEventArgs  et sa propriété NewValue, nous allons récupérer le nom de groupe qui a été attribué. On commence par vérifier que cette dernière ne vaut pas null, ce qui signifierait qu’on a pas de nom de groupe associé, puis on cherche si dans les dictionnaires HorizontalScrollOffset et VerticalScrollOffset, on a déjà ce nom engistré. Deux cas se présentent à nous.

1- Le nom est effectivement déjà enregistré, donc on utilise la méthode ScrollToHorizontalOffset ou ScrollToVerticalOffset pour placer la ScrollBar au même niveau que les autres du même groupe.

if (horizontalScrollOffsets.Keys.Contains((string)e.NewValue))
{
   scrollViewer.ScrollToHorizontalOffset(horizontalScrollOffsets[(string)e.NewValue]);
}

 

2- Le groupe n’est pas encore identifié, on l’ajoute dans les deux dictionnaires précédents.

horizontalScrollOffsets.Add((string)e.NewValue, scrollViewer.HorizontalOffset);

verticalScrollOffsets.Add((string)e.NewValue, scrollViewer.VerticalOffset);

Afin de synchroniser les différentes ListBox dès qu’une ScrollBar est déplacée, nous allons maintenant nous abonner à l’évènement ScrollChanged du ScrollViewer et ajouter le ScrollViewer dans le Dictionnaire scrollViewers.

if (!scrollViewers.ContainsKey(scrollViewer))
                   {
                       scrollViewers.Add(scrollViewer, (string)e.NewValue);
                       scrollViewer.ScrollChanged += new ScrollChangedEventHandler(ScrollViewer_ScrollChanged);
                   }

Le Handler ScrollViewer_ScrollChanged met à notre disposition l’EventArgs ScrollChangedEventArgs dans lequel on peut savoir si un changement sur la ScrollBar horizontale ou la ScrollBar verticale a été effectué. Il suffit de tester que le VerticalChange ou le HorizontalChange est différent de 0. Dans ce cas on récupère le ScrollViewer  via le sender et on appelle la méthode Scroll.

private static void ScrollViewer_ScrollChanged(object sender, ScrollChangedEventArgs e)
       {
           if (e.VerticalChange != 0 || e.HorizontalChange != 0)
           {
               var changedScrollViewer = sender as ScrollViewer;
               Scroll(changedScrollViewer);
           }
       }

Dans cette méthode

• on récupère le groupe du scrollviewer
• on met à jour le VerticalOffset et le HorizontalOffset
• on parcours l’ensemble des scrollViewers enregistrés pour ce groupe et on applique la nouvelle position verticale / horizontale via la méthode ScrollToVerticalOffset / ScrollToHorizontalOffset.

private static void Scroll(ScrollViewer changedScrollViewer)
       {
           var group = scrollViewers[changedScrollViewer];
           verticalScrollOffsets[group] = changedScrollViewer.VerticalOffset;
           horizontalScrollOffsets[group] = changedScrollViewer.HorizontalOffset;

           foreach (var scrollViewer in scrollViewers.Where((s) => s.Value == group && s.Key != changedScrollViewer))
           {
               if (scrollViewer.Key.VerticalOffset != changedScrollViewer.VerticalOffset)
               {
                   scrollViewer.Key.ScrollToVerticalOffset(changedScrollViewer.VerticalOffset);
               }

               if (scrollViewer.Key.HorizontalOffset != changedScrollViewer.HorizontalOffset)
               {
                   scrollViewer.Key.ScrollToHorizontalOffset(changedScrollViewer.HorizontalOffset);
               }
           }
       }

La dernière étape qu’il nous reste à voir est l’application de la propriété attachée pour chaque ScrollViewer des ListBox. Ouvrez le code xaml et définissez le style suivant:

 <ListBox.Style>
       <Style TargetType="{x:Type ListBox}">
            <Style.Resources>
              <Style TargetType="ScrollViewer">
                    <Setter Property="local:ScrollSync.ScrollGroupName" Value="ScrollGroup" />
              </Style>
            </Style.Resources>
        </Style>
 </ListBox.Style>

Téléchargez le code ici.

Pour y parvenir, commencez par ajouter un Custom Control WPF, vous devriez voir apparaître un fichier de code avec le nom que vous avez donné dans le wizard, ainsi qu’un fichier generic.xaml, contenant les styles de notre contrôle.

Un carrousel est un contrôle contenant un ensemble d’objets. Pour la suite de ce billet définissons les termes suivants:

• Carousel: représente notre Custom Control, avec sa collection d’objets.
• CarouselItem: représente un élément  de notre carrousel.

Comme nous souhaitons travailler avec une collection de données, nous allons faire hériter notre contrôle de la classe ItemsControl. De cette manière, nous bénéficierons  de propriétés et méthodes existantes.

Ouvrez le fichier de code, supprimez l’héritage existant sur Control et remplacez le par ItemsControl

public class Carousel : ItemsControl
{
    static Carousel()
    {
        DefaultStyleKeyProperty.
            OverrideMetadata(typeof(Carousel),
            new FrameworkPropertyMetadata(typeof(Carousel)));
    }
}

Avant d’aller plus loin dans le code de notre contrôle, voici quelques points importants

• Un ItemsControl est un type de contrôle pouvant prendre en entrée une collection de différents objets comme une string, un rectangle…
• Un UIElement ajouté en tant qu’Item du type ItemsControls est ajouté comme enfant du ItemsPanel représenté par un stackpanel par défaut.
• Tout élément qui n’est pas un UIElement est wrappé dans un ContentPresenter

Dans le cas de notre carrousel, nous allons devoir manipuler les différents éléments depuis le code. Afin de simplifier cette manipulation, nous allons demander au ItemContainerGenerator de nous créer un wrapper de type CarouselItem pour chaque Item

Commençons par ajouter une classe CarouselItem qui hérite de ContentControl. Le générateur de conteneur se chargera tout seul d’assigner le contrôle en tant que Content du CarouselItem.

public class CarouselItem : ContentControl
   {
        public CarouselItem()
       {
           this.DefaultStyleKey = typeof(CarouselItem);
       }

   }

Maintenant que nous pouvons manipuler le type CarouselItem, modifions le contrôle Carousel de manière à ce que le générateur fasse ce que l’on vient de voir.

La première modification consiste à surcharger la méthode IsItemItsOwnContainerOverride qui permet d’indiquer si le contrôle passé est son propre conteneur. Dans notre cas le carrousel contiendra des rectangles. Comme on vient tout juste de voir que le conteneur devait être un CarouselItem,  il nous suffit de faire un test de type.

protected override bool IsItemItsOwnContainerOverride(object item)
      {
          return item is CarouselItem;
      }

Comme avec des Rectangles cette méthode retournera false, une seconde méthode que nous allons également surcharger est appelée juste après. Il s’agit de la méthode GetContainerForItemOverride. Nous lui disons simplement de créer un conteneur de type CarouselItem.

protected override DependencyObject GetContainerForItemOverride()
       {
           return new CarouselItem();
       }

Dans un carrousel les éléments ont une position bien spécifique. Afin de les placer simplement où l’on veut, nous allons remplacer le panel par défaut qui contient les Items par un Canvas avec lequel on pourra spécifier les coordonnées Left et Top de l’item. Nous allons également modifier le Template par défaut et ajouter un Grid nommé “PART_RootLayout” qui va nous servir de conteneur principal notamment pour centrer le carrousel.

Dans le generic.xaml qui est le fichier contenant les styles de notre contrôle, modifions la propriété ItemsPanel.

<Style TargetType="local:Carousel">
        <Setter Property="Width" Value="800"/>
        <Setter Property="Height" Value="600"/>
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:Carousel">
                    <Grid
                        Background="Red"
                        Name="PART_RootLayout"
                        Width="{TemplateBinding Width}"
                        Height="{TemplateBinding Height}">
                        <ItemsPresenter/>
                    </Grid>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
        <Setter Property="ItemsPanel">
            <Setter.Value>
                <ItemsPanelTemplate>
                    <Canvas />
                </ItemsPanelTemplate>
            </Setter.Value>
        </Setter>
    </Style>

Notez au passage qu’on assigne une hauteur et largeur par défaut au contrôle. Si ces valeurs sont modifiées à partir des propriétés du contrôle, elles seront surchargées.

Retournons maintenant dans le code du contrôle. A présent faisons une surcharge de la méthode PrepareContainerForItemOverride, dont le but est comme le nom l’indique de préparer le conteneur pour afficher l’item correspondant.

protected override
         void PrepareContainerForItemOverride(DependencyObject element,
         object item)
     {

         base.PrepareContainerForItemOverride(element, item);
     }

Pour calculer la position d’un item, nous allons nous appuyer sur le cercle trigonométrique qui sera la base pour calculer la position d’un item à un instant t.

Considérons un cercle C de rayon 1 et de périmètre 2 PI. Pour notre exemple nous allons ajouter 4 éléments à notre ItemsControl.  Nous voulons également que nos éléments soient placés de manière à ce qu’entre deux points l’arc (mesure en radian) soit équivalent.

Avant de modifier PrepareContainerForItemOverride, ajoutez une DependencyProperty Angle de type double à l’objet CarouselItem.

public double Angle
        {
            get { return (double)GetValue(AngleProperty); }
            set { SetValue(AngleProperty, value); }
        }

        public static readonly DependencyProperty AngleProperty =
            DependencyProperty.Register("Angle",
            typeof(double), typeof(CarouselItem), new PropertyMetadata(0.0));

Maintenant dans la méthode PrepareContainer nous allons calculer l’angle de chaque item et insérer l’item dans une collection privée au contrôle pour le manipuler plus tard si besoin.

int preparedItem = 0;

       protected override
           void PrepareContainerForItemOverride(DependencyObject element,
           object item)
       {
           CarouselItem carouselItem = element as CarouselItem;
           if (carouselItem != null)
           {
               carouselItem.Angle = ((Math.PI * 2) * preparedItem) /
                   Items.Count;
               preparedItem++;
               items.Add(carouselItem);
           }
           base.PrepareContainerForItemOverride(element, item);
       }

Pour que la position des items soit recalculée régulièrement, nous avons à présent besoin d’un timer.  Nous pourrions utiliser un DispatcherTimer, mais d’après ce site (http://blogs.silverlight.net/blogs/msnow/archive/2008/07/09/storyboard-versus-dispatchertimer-for-animation-and-game-loops.aspx), l’utilisation d’une storyboard aurait quelques avantages.

Pour ajouter une storyboard, retournez dans le generic.xaml et au niveau du Part_RootLayout créez la en tant que ressource.

 <Grid  Background="Red"
        Name="PART_RootLayout"
        Width="{TemplateBinding Width}"
        Height="{TemplateBinding Height}">
        <Grid.Resources>
               <Storyboard x:Key="Timer" Duration="0"
                             x:Name="Timer" />
        </Grid.Resources>
        <ItemsPresenter/>
 </Grid>

Pour récupérer  et travailler avec cette ressource depuis le code de votre contrôle il vous suffit d’appeler la propriété ressource du PART_RootLayout et d’y passer en paramètre la Key de la storyboard. Pour cela deux choses à faire:

• Surcharger la méthode OnApplyTemplate
• Récupérer les contrôles PART_RootLayout et la storyboard liée.

private Storyboard timer;
public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    this.rootLayoutPart =
        GetTemplateChild(rootLayoutPartName)
            as FrameworkElement;
    if (this.rootLayoutPart == null)
        throw new Exception("RootLayout introuvable");

    this.timer = rootLayoutPart.Resources["Timer"]
        as Storyboard;
    if (timer == null)
        throw new Exception("Timer Storyboard est introuvable");

    this.timer.Completed -= new EventHandler(timer_Completed);
    this.timer.Completed += new EventHandler(timer_Completed);
    this.timer.Begin();
}

Une fois la storyboard récupérée, ajoutez un handler pour savoir quand elle se termine et démarrez la.

Avant de saisir le code dans la méthode timer_Completed, nous avons deux DependencyProperty à ajouter dans le code du contrôle Carrousel.

• Radius: en trigonométrie, les valeurs de Cosinus et Sinus sont comprises entre – 1 et 1. De manière à avoir un résultat plus visible, le Radius va nous permettre d’avoir un coefficient multiplicateur
• Speed: permet de spécifier la mesure de l’arc entre un point A à l’instant t et ce même point à l’instant t+ 1.

public double Radius
       {
           get { return (double)GetValue(RadiusProperty); }
           set { SetValue(RadiusProperty, value); }
       }

       public static readonly DependencyProperty RadiusProperty =
           DependencyProperty.Register("Radius",
           typeof(double), typeof(Carousel),
           new PropertyMetadata(200.0));

       public double Speed
       {
           get { return (double)GetValue(SpeedProperty); }
           set { SetValue(SpeedProperty, value); }
       }

       public static readonly DependencyProperty SpeedProperty =
           DependencyProperty.Register("Speed",
           typeof(double), typeof(Carousel),
           new PropertyMetadata(.0250));

La storyboard contient un timer qui ne tourne pas indéfiniment. La première chose que nous avons donc à faire est d’ajouter un timer.Begin() dans le handler timer_Completed. 

Maintenant il ne vous reste plus qu’à:

• parcourir la collection privée de CarouselItem
• ajouter / soustraire (selon le sens de rotation) à l’angle courant la propriété Speed
• calculer le cosinus pour l’axe des X et le sinus pour l’axe des Y de l’angle
• positionner l’item par rapport au centre de son conteneur

void timer_Completed(object sender, EventArgs e)
       {
           items.ForEach(c =>
               {
                   c.Angle += Speed;

                   Canvas.SetLeft(c,
                       Math.Cos(c.Angle) * Radius
                        + (rootLayoutPart.ActualWidth / 2
                         - c.ActualWidth / 2));
                   Canvas.SetTop(c,
                       Math.Sin(c.Angle) * Radius
                        + (rootLayoutPart.ActualHeight / 2
                         - c.ActualHeight / 2));
               });

           timer.Begin();
       }

Si vous lancez l’application vous constaterez que notre carrousel est pour l’instant vraiment plat.

Une modification simple à apporter pour donner un effet de rotation 3D est de différencier le RadiusX, du RadiusY. Pour cela supprimez la propriété Radius et ajoutez les deux suivantes:

public double RadiusX
{
    get { return (double)GetValue(RadiusXProperty); }
    set { SetValue(RadiusXProperty, value); }
}

public static readonly DependencyProperty RadiusXProperty =
    DependencyProperty.Register("RadiusX",
    typeof(double), typeof(Carousel),
    new PropertyMetadata(150.0));

public double RadiusY
{
    get { return (double)GetValue(RadiusYProperty); }
    set { SetValue(RadiusYProperty, value); }
}

public static readonly DependencyProperty RadiusYProperty =
    DependencyProperty.Register("RadiusY",
    typeof(double), typeof(Carousel),
    new PropertyMetadata(50.0));

Puis dans le handler timer_Completed, modifiez le code de manière à utiliser le RadiusX avec le cosinus et le RadiusY avec le Sinus.

Deuxième point sur le lequel on peut intervenir le ZIndex. Si on considère un carrousel 3D, les éléments qui sont plus loin de notre point de vue doivent apparaître derrière. Pour la valeur du ZIndex, on récupère la position selon l’axe Y en mettant une valeur positive ou négative sur le radiusY à l’instant t.

Point position = new Point();
                   position.X = Math.Cos(c.Angle) * RadiusX
                        + (rootLayoutPart.ActualWidth / 2
                         - c.ActualWidth / 2);
                   position.Y =  Math.Sin(c.Angle) * RadiusY
                        + (rootLayoutPart.ActualHeight / 2
                         - c.ActualHeight / 2);

                   Canvas.SetLeft(c, position.X);
                   Canvas.SetTop(c, position.Y);

                   if (this.RadiusY >= 0)
                       Canvas.SetZIndex(c, -(int)position.Y);
                   else
                       Canvas.SetZIndex(c, (int)position.Y);

Troisième et dernier point que nous allons traiter dans cet exemple, le ScaleTransform. Comme on vient de le faire avec le Zindex, nous allons pouvoir jouer sur la taille de l’item en fonction de sa position dans le carrousel

Ouvrez à nouveau le fichier generic.xaml pour y définir le template du type CarouselItem et par la même occasion lui associer une ScaleTransform.

<Style TargetType="local:CarouselItem">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:CarouselItem">
                    <Grid>
                        <ContentPresenter/>
                        <Grid.RenderTransform>
                                <ScaleTransform x:Name="ScaleTransform"
                                                ScaleX="1"
                                                ScaleY="1"/>
                        </Grid.RenderTransform>
                    </Grid>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>

Dans le Template nous ne faisons rien de particulier mise à part demander au Template de nous afficher le contenu via le ContentPresenter. Notez également la présence du ScaleTransform qui permet de dire que par défaut notre CarouselItem est à l’échelle 1 sur les deux axes.

Comme nous l’avions fait précédemment dans le contrôle Carousel pour récupérer le PART_RootLayout, nous surchargeons la méthode OnApplyTemplate de CarouselItem afin de récupérer le ScaleTransform, puis nous l’exposons via une propriété.

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    ScaleTransform = GetTemplateChild(ScaleTransformName) as ScaleTransform;
}

public ScaleTransform ScaleTransform
{
    get { return (ScaleTransform)GetValue(ScaleTransformProperty); }
    set { SetValue(ScaleTransformProperty, value); }
}

public static readonly DependencyProperty ScaleTransformProperty =
    DependencyProperty.Register("ScaleTransform",
    typeof(ScaleTransform), typeof(CarouselItem), null);

Le ScaleTransform est en place dans le CarouselItem, nous pouvons maintenant modifier sa valeur en fonction de la position de l’item sur l’axe des Y.

double sinus = Math.Sin(c.Angle);
                  if (sinus < 0.5)
                      sinus = 0.5;

                  c.ScaleTransform.ScaleX = c.ScaleTransform.ScaleY = sinus ;

Ce billet était une simple démo pour construire la base d’un carrousel. Vous pouvez facilement le faire évoluer avec les points suivants:

• Changer le sens de rotation (Speed) en fonction d’où se trouve la souris
• Faire varier  l’opacité
• Rendre sélectionnable un item
• ….

Sources de ce billet: sources.zip

Pourquoi vouloir créer ce type de propriété ?

Un cas que l’on rencontre souvent est de vouloir rendre accessible une information sur un état particulier du contrôle. Or cette information n’a pas besoin d’être modifiée depuis l’UI. Comme pour les DependencyProperty classiques, vous pouvez créer des Binding, ou bien encore les utiliser dans des triggers. La seule possibilité pour modifier sa valeur est de le faire depuis une méthode de la classe du contrôle.

Voyons maintenant comment l’écrire. Partons du principe que j’ai un contrôle nommé SlidingPanel qui veut donner comme information l’état de visibilité de la partie navigation.

D’habitude lorsque l’on créé une DependencyProperty, on utilise la méthode Register. Dans le cas présent la méthode à utiliser est la méthode RegisterReadOnly qui retourne un objet de type DependencyPropertyKey et non un DependencyProperty comme Register. Cet objet nous permet d’accéder à la donnée depuis notre classe.

private static readonly DependencyPropertyKey NavigationBarVisibilityKey =
    DependencyProperty.RegisterReadOnly("NavigationBarVisibility",
    typeof(Visibility),
    typeof(SlidingPanel),
    new FrameworkPropertyMetadata(Visibility.Collapsed));

Ensuite nous devons créer une DependencyProperty assignée depuis la propriété DependencyProperty de NavigationBarVisibilityKey. Il s’agit de la propriété readOnly accessible de l’extérieure de notre contrôle.

public static readonly DependencyProperty NavigationBarVisibilityProperty =
    NavigationBarVisibilityKey.DependencyProperty;

Enfin ajoutons une propriété wrapper avec pour seule différence à une DependencyProperty classique le setter auquel on ajoute le mot clé private pour spécifier que le SetValue ne sera appelé que depuis le contrôle.

public Visibility NavigationBarVisibility
      {
          get { return (Visibility)GetValue(NavigationBarVisibilityProperty); }
          private set { SetValue(NavigationBarVisibilityKey, value); }
      }

Et voilà le tour est joué.

Mais qu’est-ce que PRISM ?

Certains diront qu’il s’agit d’un Framework permettant d’appliquer le pattern MVVM, d’autres qu’il permet de découper son application en modules. En effet PRISM nous permet bien de réaliser ces deux opérations, mais c’est avant tout un ensemble d’outils qui  au travers de bonnes pratiques, donne la possibilité de construire des applications testables, maintenables et évolutives.

Si on s ‘en tient à quelques mots, avec PRISM vous pourrez:

• Créer une application modulaire: vous avez la possibilité de découper votre application en différents modules qui peuvent évoluer chacun de leur côté. PRISM met à votre disposition un catalogue qui référence, l’ensemble des modules que contient l’application. Dll ou xap que vous soyez avec WPF ou Silverlight.
• Appliquer des régions: une région est un élément qui contient une vue indépendante des autres. Ainsi, vous pouvez avoir un ensemble de vues constituant votre interface, mais chacune est libre d’évoluer comme bon lui semble dans son module.
• Appliquer le pattern MVVM: le pattern MVVM, comme vous le savez permet de séparer les rôles à savoir d’un côté la vue et de l’autre le ViewModel / Presenter qui va se charger de fournir / adapter les  données pour la vue. De plus votre application est plus facilement testable. Pour communiquer avec le ViewModel, le pattern MVVM utilise les commandes. Si vous utilisez notamment Silverlight dans une version antérieur à la 4, cela peut s’avérer très utile, d’utiliser les propriétés attachées mises à disposition par PRISM pour faciliter la communication
• Mettre en place des modules faiblement couplés:  pour faire la résolution des services, vous pouvez vous appuyer sur Unity intégré directement dans PRISM. Définissez vos interfaces avec les implémentations correspondantes et enregistrez les dans le conteneur unity. Enfin pour communiquer entre les modules qui ne sont pas sensés se connaitre, ils peuvent communiquer via  une infrastructure qui s’appuie sur le pattern Publish / Subscribe.

Chacune de ces fonctionnalités est utilisable indépendamment des autres, c’est ça également la force de ce Framework

Si ce billet vous a donné le désir d’en savoir plus (ce que j’espère ), voici quelques liens où vous pourrez trouver des informations complémentaires détaillées ainsi que des exemples.

• Patterns For Building Composite Applications With WPF
• Composite Application Guidance Pattern For Silverlight
• When To Use Guidance
• Learn Prism
• Prism Download

Avec Silverlight 3, nous avions la possibilité de faire fonctionner une application en mode out of browser. Cela signifie qu’elle était détachée de son hôte de base, le navigateur, pour fonctionner comme une application installée sur le desktop.

Pour y arriver, il suffisait de faire clique droit sur le projet, puis sur l’onglet application, de cocher la case “Enable running application out of the browser”.

Parmi les différentes options de configuration de ce mode d’utilisation, Silverlight ajoute notamment la possibilité de préciser que l’application nécessite des droits élevés.

Ces droits sont justement nécessaires pour interagir avec les Interop COM et donc notamment Office. Toutes ces informations de droits, de taille de fenêtre sont stockées dans le fichier de déploiement AppManifest.xaml du fichier xap créé à la compilation de l’application.

Maintenant que les bases sont posées, commençons par créer une popup “ChildWindow”, dans laquelle nous indiquons à l’utilisateur qu’il doit procéder à l’installation de l’application pour l’utiliser.

Code XAML correspondant:

<controls:ChildWindow x:Class="OutOfBrowserApp.SetupPage"
           xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
           xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
           xmlns:controls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls"
           Width="400" Height="300"
           Title="SetupPage">
    <Grid x:Name="LayoutRoot" Margin="2">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>

        <StackPanel Orientation="Vertical">
            <TextBlock
            VerticalAlignment="Center"
            HorizontalAlignment="Center"
            Margin="10"
            Text="Veuillez procéder à l'installation de l'application" />
            <Button Content="Installer" Width="150" Height="25" />
        </StackPanel>

Double cliquez sur le bouton pour ajouter un handler dans lequel on demande à l’application de s’installer.

private void Button_Click(object sender, RoutedEventArgs e)
{
    if (App.Current.InstallState != InstallState.Installing
        && App.Current.InstallState != InstallState.Installed)
    {
        App.Current.InstallStateChanged += (s, ev) =>
        {
            if (App.Current.InstallState == InstallState.Installed)
            {
                MessageBox.Show("Installation terminée");
            }
        };
        App.Current.Install();
    }
}

On commence par vérifier que l’application n’est pas déjà installée ou en cours d’installation, puis on lance la procédure. On s’abonne également à l’évènement InstallationStateChanged pour notifier l’utilisateur une fois l’installation terminée.

Comme nous souhaitons afficher cette fenêtre seulement lorsque  l’application n’est pas encore en mode out of browser, nous devons procéder à une vérification lors du chargement de la page principale.

if (!Application.Current.IsRunningOutOfBrowser
    && Application.Current.InstallState == InstallState.NotInstalled)
{
    SetupPage setup = new SetupPage();
    setup.Show();
}
else
{
    Application.Current.CheckAndDownloadUpdateCompleted += (s, ev) =>
        {
            if(ev.UpdateAvailable)
                MessageBox
                    .Show("Mise à jour de l'application effectuée,"
            +"veuillez redémarrer l'application");
        };
    Application.Current.CheckAndDownloadUpdateAsync();
}

Vous noterez au passage, la notification faite à l’utilisateur, si la présence d’une mise à jour est détectée puis installée.

Dans cette application démo, nous voulons exporter la liste des collaborateurs de l’entreprise vers un fichier Excel. Pour cela créons une classe Collaborateur avec trois propriétés Nom, Prénom et Age.

public class Collaborateur
{
    public string Nom { get; set; }
    public string Prenom { get; set; }
    public int Age { get; set; }
}

Du coté XAML, ajoutons, un DataGrid qui se trouve dans System.Windows.Controls.Data et un bouton pour réaliser l’export.

 <StackPanel Orientation="Vertical">
        <data:DataGrid AutoGenerateColumns="True"
                       Name="CollaborateursListe" />
        <Button  Content="Exporter vers Excel" Width="150"/>
    </StackPanel>

Dans le code behind, créez une liste de collaborateurs et assignez là au DataGrid.

List<Collaborateur> collaborateurs = new List<Collaborateur>() {
                new Collaborateur{Nom="Arnaudet",Prenom="Alexandre",Age=25},
                new Collaborateur{Nom="MonNom",Prenom="MonPrenom", Age=26}
            };

            this.CollaborateursListe.ItemsSource = collaborateurs;

Rappel: vous avez la possibilité d’utiliser le pattern MVVVM, afin de bien séparer l’UI et la logique business.

En démarrant l’application depuis votre bureau vous devriez maintenant avoir un écran avec la liste des collaborateurs qui s’affiche.

Afin de procéder à l’export, commencez par ajouter un handler lié au bouton d’export, puis mettez le code suivant que nous allons détailler.

if (AutomationFactory.IsAvailable)
          {
              dynamic excel = AutomationFactory
                  .CreateObject("Excel.Application");
              dynamic workbook = excel.workbooks;
              workbook.Add();
              dynamic sheet = excel.ActiveSheet;

              excel.Visible = true;

              dynamic cell = null;
              int i = 1;

              List<Collaborateur> collaborateurs =
                  new List<Collaborateur>
                  (CollaborateursListe.ItemsSource.OfType<Collaborateur>());
              collaborateurs.ForEach(c =>
                  {
                      cell = sheet.Cells[i, 1];
                      cell.Value = c.Nom;

                      cell = sheet.Cells[i, 2];
                      cell.Value = c.Prenom;

                      cell = sheet.Cells[i,3];
                      cell.Value = c.Age;

                      i++;
                  });

              MessageBox.Show("Export terminé");
          }

Première chose que l’on remarque, le mot Automation. L’automation permet à une application d’exposer des objets pour que ceux-ci soient utilisés par une application tierce, ou bien d’accéder à des objets mis à disposition par une autre application. Ils sont exposés via un serveur d’automation au travers d’interfaces COM.

AutomationFactory est l’entité permettant de savoir si le serveur est disponible. Cependant attention vous devez avoir des droits élevés pour y parvenir, d’où le début de ce billet.

Pour créer un objet, vous devez simplement via AutomationFactory, utiliser la méthode CreateObject qui prend en paramètre un progID. Ce progID est déterminé par l’application à laquelle on veut accéder. Il s’agit dans notre cas de “Excel.Application”. De la même manière vous avez “Outlook.Application” et “Word.Application” en ce qui concerne Office. Ensuite il ne vous reste plus qu’à créer un classeur et d’y récupérer la feuille active pour y insérer vos données.

Dernier point qu’il vous reste à faire. Parcourir le datagrid pour créer les cellules et y afficher vos données.

Vous noterez également l’utilisation du mot clé dynamic arrivé avec C# 4. Vous pourrez trouver plus d’informations concernant ce sujet à cette adresse.

Au même titre que vous faites de l’héritage graphique avec des css, la propriété BasedOn permet d’hériter d’un autre style créé en XAML dans votre application.

Prenons un exemple.

Je souhaite que tous les boutons de mon application soient noirs avec une police blanche. Comme je suis quelqu’un de fainéant, je ne veux pas passer après chacun de mes boutons pour leur attribuer ce style de base. Je ne vais donc pas renseigner la propriété Key.

 <Style TargetType="{x:Type Button}">
                <Setter Property="Foreground" Value="#FFFFFF"/>
                <Setter Property="Background" Value="#000000" />
            </Style>

Maintenant que ce style est créé, j’ai besoin d’un bouton nécessitant en plus du style précédent que la police soit en gras. C’est là qu’entre en jeu la propriété BasedOn.

  <Style x:Key="Gras" TargetType="{x:Type Button}"
           BasedOn="{StaticResource {x:Type Button}}">
       <Setter Property="FontWeight" Value="Bold"/>
  </Style>

Cette fois, on a la propriété Key sur notre style pour l’assigner à un bouton en particulier. Le TargetType est toujours identique puisque nous sommes toujours sur la définition d’un bouton et nous avons la fameuse propriété BasedOn qui indique ici que le bouton avec le style Gras hérite également du style de base donné à tous les bouttons.

Enfin créons un dernier style afin de montrer que l’on peut écraser le style d’une propriété sans pour autant altérer le reste.

 <Style x:Key="Rouge" TargetType="{x:Type Button}"
                   BasedOn="{StaticResource Gras}">
         <Setter Property="Background" Value="red"/>
 </Style>

Comme vous pouvez le constater, via la propriété BasedOn on voit clairement que le dernier style hérite du style Gras qui lui même hérite du style commun aux boutons. La seule différence vient de la propriété Background, que nous avons surchargée dans ce style pour passer du noir au rouge.

Il existe aujourd’hui différentes possibilités pour faire valider les données, selon que vous utilisez la version 3 ou 4 du Framework.

Cependant pour y parvenir il y a quelques étapes à suivre, car par défaut, l’UI ne vous affichera pas de message d’erreur si la donnée source n’est pas correcte. Quand je dis “correcte”, il peut aussi bien s’agir d’un format de la donnée, que d’une valeur non possible selon une règle business.

Pour mettre en avant les différents cas, commençons par créer une classe Collaborateur avec simplement trois propriétés Nom / Age / DateEmbauche

public class Collaborateur : INotifyPropertyChanged
       {
           private string nom;
           public string Nom
           {
               get { return nom; }
               set
               {
                   if (value != nom)
                   {
                       nom = value;
                       OnNotify("Nom");
                   }
               }
           }

           private int age;
           public int Age
           {
               get { return age; }
               set
               {
                   if (value != age)
                   {
                       age = value;
                       OnNotify("Age");
                   }
               }
           }

           private DateTime dateEmbauche;
           public DateTime DateEmbauche
           {
               get { return dateEmbauche; }
               set
               {
                   if (value != dateEmbauche)
                   {
                       dateEmbauche = value;
                       OnNotify("DateEmbauche");
                   }
               }
           }

           private void OnNotify(string name)
           {
               if (!string.IsNullOrEmpty(name) && PropertyChanged != null)
                   PropertyChanged(this, new PropertyChangedEventArgs(name));
           }

           public event PropertyChangedEventHandler PropertyChanged;
       }

Puis assignez au DataContext de la Vue une instance de cette classe.

this.DataContext = new Collaborateur
            {
                Nom = "Alexandre",
                Age = 25,
                DateEmbauche = new DateTime(2008, 4, 12)
            };

Maintenant du côté de la vue, ajoutons trois contrôles TextBox avec lesquels on fait le binding sur le DataContext et donc sur l’entité Collaborateur.

    <Grid x:Name="LayoutRoot" Background="White">
        <StackPanel Orientation="Vertical">
            <TextBox Width="200" Text="{Binding Nom,Mode=TwoWay}"/>
            <TextBox Width="200" Text="{Binding Age,Mode=TwoWay}"/>
            <TextBox Width="200" Text="{Binding DateEmbauche,Mode=TwoWay}"/>
        </StackPanel>
    </Grid>

Dans cet état, si vous démarrez l’application et tentez de changer par exemple la date d’embauche en une date non valide, vous n’aurez aucune erreur qui apparaît à l’écran.

La première méthode pour remonter l’information est apparue avec la version 3. Elle consiste à lever une exception dans le setter de la propriété concernée.

Pour dire à l’objet Binding d’afficher l’exception, il faut d’abord ajouter le ValidatesOnExceptions à true au niveau du Binding sur la date d’embauche dans le code XAML. Cette valeur est par défaut à false.

En interne si une erreur est détectée, le moteur de binding créé un objet ValidationError et l’ajoute à la collection Validation.Errors de l’objet bindé. La propriété HasError de l’objet validation passe alors à true.  Le contrôle textBox depuis son template, va s’appuyer sur cette propriété HasError pour afficher le message.

<TextBox Width=”200″Text=”{Binding Age,ValidatesOnExceptions=True}”/>

Vous devriez maintenant avoir le message suivant qui s’affiche

On voit clairement qu’on a ici une erreur remontée par le TypeConverter. De la même manière on peut lever une exception sur l’âge. Pour cela, rendons-nous dans la définition de l’entité et ajoutons une règle.

private int age;
         public int Age
         {
             get { return age; }
             set
             {
                 if (value != age)
                 {
                     if (value < 18)
                         throw new
                             Exception("Tu dois avoir au moins 18 ans");
                     age = value;
                     OnNotify("Age");
                 }
             }
         }

Si maintenant, vous mettez un âge inférieur à 18 ans,  un message pour l’âge doit également apparaître.

Notez au passage la présence d’un ValidationSummary qui a pour but de centraliser les différentes erreurs. Si vous souhaitez également l’utiliser, vous devez ajouter une référence sur System.Windows.Controls.Data.Input et également la propriété NotifyOnValidationError=true au niveau de la propriété bindée. Ceci aura pour effet de déclencher automatiquement l’évènement BindingValidationError auquel le ValidationSummary est attaché.

La deuxième solution qui est plus élégante que de lever une exception pour chaque validation, s’appuie sur l’interface IDataErrorInfo.  Cette interface nécessite l’’utilisation de Silverlight 4. Elle est constituée de deux propriétés et est particulièrement utile lorsque l’on a des règles business de validation.

• Error: qui permet de récupérer une erreur sur l’objet
• this[string columnName]: qui retourne un message d’erreur spécifique à une propriété de l’objet

public interface IDataErrorInfo
   {
       string Error { get; }
       string this[string columnName] { get; }
   }

Reprenons l’entité Collaborateur pour la mettre à jour avec cette interface.

public string Error
          {
              get { return "Erreur dans la validation
                  de l'objet collaborateur"; }
          }

          public string this[string columnName]
          {
              get
              {
                  string error = null;

                  switch (columnName)
                  {
                      case "Age":
                          if (Age < 18)
                          {
                              error = "Tu dois avoir au moin 18 ans";
                          }
                          break;
                  }
                  return (error);
              }
          }

Au niveau du code XAML, il vous faut ajouter la propriété ValidatesOnDataErrors et la mettre à true

   <TextBox Width="200" Text="{Binding Age,Mode=TwoWay,
        ValidatesOnDataErrors=True,NotifyOnValidationError=True}"/>

Comme pour la solution précédente, l’objet Binding sait que quand il y a un message d’erreur en retour de l’interface IDataErrorInfo, il doit créer un objet ValidationError.

A noter:

• Cette interface est déjà utilisée en WindowsForms et WPF, vous pouvez donc réutiliser les mêmes entités avec Silverlight 4.
• Il s’agit d’un modèle synchrone, donc attention de pas avoir de règles de validation trop lourdes, sinon utilisez la dernière solution que nous allons voir d’ici quelques lignes.
• L’interface ne retourne qu’un message par propriété de type string

Enfin la dernière solution consiste à utiliser INotifyDataErrorInfo. Préférez cette interface pour tout nouveau développement.

Avantages:

• Elle permet d’appliquer des règles de validation de manière asynchrone.
• Supporte des objets d’erreur personnalisés
• Peut retourner plusieurs erreurs pour une propriété
• Depuis une propriété vous pouvez vérifier la validation d’une seconde

Description de l’interface:

• HasError indique si une erreur existe dans l’entité
• ErrorsChanged est un évènement appelé dès qu’une modification est apportée pour une erreur liée à une propriété ou à l’objet directement.
• GetErrors récupère les erreurs pour une propriété.

public interface INotifyDataErrorInfo
   {
      bool HasErrors { get; }

      event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

      IEnumerable GetErrors(string propertyName);
   }

Encore une fois apportons quelques modifications à notre classe collaborateur pour implémenter cette nouvelle interface

public class Collaborateur : INotifyPropertyChanged, INotifyDataErrorInfo
       {
           const string DebutNomErreur = "Le nom doit commencer par un A";
           const string FinNomErreur = "Le nom doit se terminer par un E";

           private string nom;
           public string Nom
           {
               get { return nom; }
               set
               {
                   if (value != nom)
                   {

                       if (!value.ToLower().StartsWith("a"))
                           AddError("Nom", DebutNomErreur);
                       else
                           RemoveError("Nom", DebutNomErreur);

                       if (!value.ToLower().EndsWith("e"))
                           AddError("Nom", FinNomErreur);
                       else
                           RemoveError("Nom", FinNomErreur);

                       nom = value;
                       OnNotify("Nom");
                   }
               }
           }

           const string AgeError = "Tu dois avoir au moins 18 ans";

           private int age;
           public int Age
           {
               get { return age; }
               set
               {
                   if (value != age)
                   {
                       if (value < 18)
                           AddError("Age", AgeError);
                       else
                           RemoveError("Age", AgeError);

                       age = value;
                       OnNotify("Age");
                   }
               }
           }

           private DateTime dateEmbauche;
           public DateTime DateEmbauche
           {
               get { return dateEmbauche; }
               set
               {
                   if (value != dateEmbauche)
                   {
                       dateEmbauche = value;
                       OnNotify("DateEmbauche");
                   }
               }
           }

           private void OnNotify(string name)
           {
               if (!string.IsNullOrEmpty(name) && PropertyChanged != null)
                   PropertyChanged(this, new PropertyChangedEventArgs(name));
           }

           public event PropertyChangedEventHandler PropertyChanged;

           public event EventHandler<DataErrorsChangedEventArgs>
               ErrorsChanged;

           public System.Collections.IEnumerable
               GetErrors(string propertyName)
           {
               if (!errors.ContainsKey(propertyName))
                   return null;

               return errors[propertyName];
           }

           public bool HasErrors
           {
               get { return errors.Count > 0; }

           }

           private Dictionary<String, List<String>> errors
               = new Dictionary<string, List<string>>();

           public void AddError(string propertyName, string error)
           {
               if (!errors.ContainsKey(propertyName))
                   errors[propertyName] = new List<string>();

               if (!errors[propertyName].Contains(error))
               {
                   errors[propertyName].Add(error);
                   RaiseErrorsChanged(propertyName);
               }
           }

           public void RemoveError(string propertyName, string error)
           {
               if (errors.ContainsKey(propertyName) &&
                   errors[propertyName].Contains(error))
               {
                   errors[propertyName].Remove(error);
                   if (errors[propertyName].Count == 0)
                       errors.Remove(propertyName);
                   RaiseErrorsChanged(propertyName);
               }
           }

           public void RaiseErrorsChanged(string propertyName)
           {
               if (ErrorsChanged != null)
                   ErrorsChanged(this,
                       new DataErrorsChangedEventArgs(propertyName));
           }

       }

Comme vous pouvez le remarquer, nous avons ajouté une collection de type dictionnaire<string,List<string>> pour indiquer que pour une propriété nous pouvons avoir plusieurs messages, ainsi que deux méthodes AddError et RemoveError qui agissent sur cette collection et lèvent l’évènement indiquant qu’une modification a été apportée sur la propriété courante.

Du côté de l’interface INotifyDataErrorInfo, la propriété HasErrors regarde si le dictionnaire contient des erreurs et GetErrors s’appuie également sur le dictionnaire pour retourner tous les messages d’une propriété.

Enfin dernier point à modifier pour que cela puisse fonctionner. Remplacez dans le code XAML la propriété ValidatesOnDataErrors par  ValidatesOnNotifyDataErrors.

    <TextBox Width="200" Text="{Binding Nom,Mode=TwoWay,
        ValidatesOnNotifyDataErrors=True,NotifyOnValidationError=True}"/>

Et voilà, vous devriez obtenir un écran dans ce style, suivant les infos que vous entrez:

Je pense qu’à la suite de ce billet, vous avez les bases pour faire de la validation de données, donc à vos claviers.

Pour faire en sorte que votre application soit donc utilisable en mode OOB, il vous suffit juste d’aller dans les propriétés de  l’application Silverlight et de sélectionner la checkbox “Enable running  application out of browser” comme montré sur cette image.

Pour forcer l’utilisateur à installer l’application une fois lancée, mettons en place une interface avec un boutton chargé de l’installation, uniquement visible le temps que l’installation n’est pas faite., et un second bouton  “StartButton” visible une fois l’installation faite,chargé d’afficher une NotificationWindow. Le statut de l’installation est accessible via la propriété InstallState de l’application.

if (App.Current.InstallState == InstallState.Installed)
           {
               InstallBtn.Visibility = System.Windows.Visibility.Collapsed;
               StartBtn.Visibility = System.Windows.Visibility.Visible;
           }

Etant donné que les autres boutons ne seront visibles qu’une fois l’application installée, vous devriez obtenir le visuel suivant.

Au niveau du handler associé à ce bouton, nous retrouvons le code permettant de lancer l’installation.

App.Current.Install();

Cliquez sur le bouton pour démarrer la procédure. Silverlight vous demande de confirmer l’installation, en précisant les raccourcis à créer.

Cliquez sur ok, l’application est installée. Pour l’exécuter rendez-vous dans le menu Démarrer.

Il nous reste plus qu’à créer une NotificationWindow. Pour le faire, ajoutez un handler associé au click  du StartButton, puis dans le corps de la méthode, instanciez une NotificationWindow, précisez, sa largeur et sa hauteur ainsi qu’un contenu. Enfin appelez la méthode Show en lui passant un temps en millisecondes, pour montrer la fenêtre.

private void Button_Click(object sender, RoutedEventArgs e)
       {

           NotificationWindow nw = new NotificationWindow();
           nw.Width = 300;
           nw.Height=60;
           nw.Content = new TextBlock { Text = "Je fais une démo" };
           nw.Show(4000);
       }

Comme vous pouvez le voir, dans cet exemple très simple, nous passons à la propriété Content juste un élément TextBlock, histoire d’afficher un message. Comme cette propriété attend un type FrameworElement, vous pouvez  par exemple lui assigner  un custom contrôle.

Pour créer ce custom control, ajoutez juste un nouvel item et sélectionnez  Silverlight Templated Control dans le TemplateWizard. Vous devriez  en plus des fichiers précédents,  avoir un dossier thème contenant un generic.xaml pour définir l’aspect visuel du contrôle, plus un fichier cs à la racine du projet pour définir la logique du contrôle.

Ce que nous voulons faire, c’est afficher une NotificationWindows avec un titre et un contenu.

Dans le generic.xaml nous redéfinissons le template du contrôle avec un  border comme élément conteneur et un stackpanel contenant le champs texte du header et un autre du content.

<Style TargetType="local:NotificationContent">
        <Setter Property="Width" Value="400"/>
        <Setter Property="Height" Value="70"/>
        <Setter Property="Foreground" Value="White"/>
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:NotificationContent">
                    <Border
                        BorderBrush="Yellow"
                        BorderThickness="2"
                        Background="Black"
                        Height="{TemplateBinding Height}"
                        Width="{TemplateBinding Width}">
                        <StackPanel Orientation="Vertical">
                            <TextBlock Name="PART_HeaderText" Foreground="{TemplateBinding Foreground}" Text="{TemplateBinding HeaderText}"/>
                            <TextBlock Name="PARTContentText" Foreground="{TemplateBinding Foreground}" Text="{TemplateBinding ContentText}" />
                        </StackPanel>
                    </Border>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>

Vous noterez également au passage, la présence du Binding sur deux propriétés que l’on a ajouté  dans le code logique du contrôle.

public string HeaderText
{
    get { return (string)GetValue(HeaderTextProperty); }
    set { SetValue(HeaderTextProperty, value); }
}

public static readonly DependencyProperty HeaderTextProperty =
    DependencyProperty.Register("HeaderText", typeof(string), typeof(NotificationContent), null);

public string ContentText
{
    get { return (string)GetValue(ContentTextProperty); }
    set { SetValue(ContentTextProperty, value); }
}

public static readonly DependencyProperty ContentTextProperty =
    DependencyProperty.Register("ContentText", typeof(string), typeof(NotificationContent), null);

Pour utiliser ce contrôle, il ne vous reste plus qu’à l’instancier et à l’assigner à la propriété content de la NotificationWindow.

NotificationWindow nw = new NotificationWindow();
         nw.Width = 300;
         nw.Height = 60;

         content.HeaderText = "Mon Titre";
         content.ContentText = "Corps de la notification";
         content.Width = nw.Width;
         content.Height = nw.Height;
         nw.Content = content;

1- Soit notre liste contient des données homogènes, c’est à dire même type ou alors sans aucun critère de distinction, et on affiche un Template unique pour tous les Items via la propriété ItemTemplate

2- Soit notre liste contient différents types, ou des valeurs internes différentes nécessitant la mise en place d’un Selector pour écrire la logique permettant de faire le choix du bon Template à afficher dans notre application.

Nous traiterons ici la cas du ItemTemplateSelector, applicable pour les contrôles héritant de ItemsControl, mais sachez qu’il existe également un ContentTemplateSelector pour les Content contrôles, le ItemContainerStyleSelector… Attention, si vous saisissez un ItemTemplate, le Selector sera tout simplement ignoré

Exemple cas 1:

Imaginons un classe Salarie qui implémente l’interface IPersonnel. Cette interface spécifie simplement deux propriétés, à savoir Nom et Prenom. 

public interface IPersonnel
  {

      string Nom { get; set; }
      string Prenom { get; set; }

  }

  public class Salarie : IPersonnel
  {
      public string Nom { get; set; }
      public string Prenom { get; set; }

  }

Dans le code behind ou ViewModel si vous appliquez le pattern MVVM, ajoutez une collection de Salariés, puis dans le code xaml de votre vue, ajoutez une ListBox ou tout autre ItemControl, et faites le Binding sur la propriété ItemsSource et indiquez un ItemTemplate pour le visuel de chaque item de de la ListBox;

Ajout des données au DataContext (Code Behind)

this.DataContext = new List<IPersonnel> {
    new Salarie{ Nom="Arnaudet",Prenom="Alexandre"},
    new Salarie{Nom="CLT",Prenom="Services"}
};

Code XAML

        <ListBox ItemsSource="{Binding}">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <Border CornerRadius="5"
                        BorderBrush="Black"
                        BorderThickness="1"
                        Padding="10">
                        <StackPanel Orientation="Vertical">
                            <TextBlock Text="Salarie" FontWeight="Bold"/>
                            <TextBlock Text="{Binding Nom}" />
                        </StackPanel>
                    </Border>
                </DataTemplate>
        </ListBox.ItemTemplate>
        </ListBox>

Résultat

Exemple cas 2:

Dans cet exemple, nous allons garder la classe salarie, mais ajouter une seconde classe Directeur. Comme salarie elle implémente IPersonnel de manière à ce que Directeur fournisse les données minimum pour être un membre du personnel, mais ajoute la possibilité d’avoir des salariés sous ses ordres.

public class Directeur : IPersonnel
{
    #region IPersonnel Members

    public string Nom { get; set; }
    public string Prenom { get; set; }

    public List<IPersonnel> Salaries { get; set; }

    #endregion
}

Comme précédemment, nous allons ajouter dans le code behind, une liste de IPersonnel au DataContext, mais cette fois avec des salaries et des directeurs.

this.DataContext = new List<IPersonnel> {
               new Salarie{ Nom="Arnaudet",Prenom="Alexandre"},
               new Salarie{Nom="Greg",Prenom="Greg"},
               new Directeur{Nom="Damien",Prenom="Damien",
                Salaries= new List<IPersonnel>{
                   new Salarie{Nom="PL",Prenom="PL"},
                   new Salarie{Nom="Jérôme",Prenom="Jérôme"},
                   new Salarie{ Nom="Arnaudet",Prenom="Alexandre"},
                   new Salarie{Nom="Greg",Prenom="Greg"},
                }},
               new Directeur{Nom="Ludo",Prenom="Ludo",
                Salaries= new List<IPersonnel>{
                   new Salarie{Nom="Manu",Prenom="Manu"},
                   new Salarie{Nom="Celine",Prenom="Celine"}
                }}
           };

Si on ne va pas plus loin, on retrouve simplement à l’écran une liste de 4 salariés

Ce que nous voulons c’est créer un visuel différent lorsqu’on à faire à un simple salarié, ou bien à un directeur et ses salariés, c’est là qu’entre en jeu la propriété ItemTemplateSelector. Dès lors que vous aurez spécifié un DataTemplateSelector en tant que ressource sur cette propriété, la méthode SelectTemplate va être recherchée.

Le Selector doit hériter de la classe DataTemplateSelector, puis surcharger la méthode SelectTemplate qui retourne un DataTemplate, celui sélectionné suite à la logique appliquée. Alors ici, nous allons faire simple en ne regardant que le type de IPersonnel

Si c’est un Directeur on retourne le DataTemplate DirecteurDataTemplate, sinon SalarieDataTemplate.

public class PersonnelSelector : DataTemplateSelector {
        public override DataTemplate
            SelectTemplate(object item, DependencyObject container)
        {
            if (item != null && item is Directeur)
                return Application.Current
                    .TryFindResource("DirecteurDataTemplate") as DataTemplate;

            return Application.Current
                .TryFindResource("SalarieDataTemplate") as DataTemplate;
        }
    }

Les deux DataTemplate indiqués ci-dessus sont créés dans les ressources de l’application

   <Application.Resources>
        <DataTemplate x:Key="SalarieDataTemplate">
            <Border CornerRadius="5"
                        BorderBrush="Black"
                        BorderThickness="1"
                        Padding="10">
                <StackPanel Orientation="Vertical">
                    <TextBlock Text="Salarie" FontWeight="Bold"/>
                    <TextBlock Text="{Binding Nom}" />
                </StackPanel>
            </Border>
        </DataTemplate>
        <DataTemplate x:Key="DirecteurDataTemplate">
            <Border CornerRadius="5"
                        BorderBrush="Black"
                        BorderThickness="1"
                        Padding="10">
                <StackPanel Orientation="Vertical">
                    <TextBlock Text="Salarie" FontWeight="Bold"/>
                    <TextBlock Text="{Binding Nom}" />
                    <ListBox Margin="20,0,0,0"
                             ItemsSource="{Binding Salaries}"
                             ItemTemplate=
                             "{StaticResource SalarieDataTemplate}"/>
                </StackPanel>
            </Border>
        </DataTemplate>
    </Application.Resources>

Il nous reste plus qu’à modifier notre code xaml pour référencer le Selector et supprimer l’ItemTemplate actuel.

<Grid.Resources>
            <local:PersonnelSelector x:Key="Selector"/>
        </Grid.Resources>
        <ListBox ItemsSource="{Binding}"
                 ItemTemplateSelector="{StaticResource Selector}">
        </ListBox>

Ce qui nous donne comme résultat

Comme vous pouvez le voir dans le cas du Directeur, nous retrouvons bien ses salariés.Dans le cadre de notre exemple, vous pourriez très bien ajouter une nouvelle entité implémentant IPersonnel et crééer comme on vient de le faire son propre visuel (DataTemplate) en utilisant le Selector

BackgroundWorker worker = new BackgroundWorker();

//Handler appelé lors de l'exécution du thread
worker.DoWork += (s, ev) => { };

//Handler appelé une que l'opération dans le thread est terminée
worker.RunWorkerCompleted += (s, ev) => { };

worker.RunWorkerAsync();

Récemment je me suis retrouvé avec une application manipulant des objets COM. Afin de pouvoir faire du Binding sur ces objets et profiter de la notification avec l’interface INotifyPropertyChanged, j’ai créé un objet wrapper prenant en paramètre un interop qui se charge simplement de s’abonner à un event créé dans les objets COM et de propager la notification en déclenchant un event PropertyChanged.

Le seul problème c’est que ces objets COM sont enregistrés dans le registre avec un ThreadModel = “Apartment” ce qui signifie qu’ils ne peuvent être utilisés que sur un thread avec un ApartmentState STA (Single Threaded Apartment).

Un objet COM créé par un STAThread ne peut être manipulé que par ce même thread. Or comme indiqué plus haut la vue va se binder dessus et en éditant par exemple une textbox liée à une propriété, la propriété doit être mise à jour. Le thread mettant à jour la donnée est l’UI thread qui fonctionne en STA. Cela implique qu’on ne peut modifier ces objets sur un autre thread que celui de l’interface.

Inconvénient:

J’ai créé un contrôle Loader qui s’affiche normalement lorsqu’une opération longue est en cours  d’exécution dans un autre thread. Avec ce que l’on vient de dire quelques lignes ci-dessus, mon contrôle loader se retrouve figé.

Pour contourner ce problème et ayant dans mon viewModel une propriété indiquant si une opération est en cours, j’ai créé une classe avec une propriété attachée qui récupère le statut de l’opération et qui selon son état true / false, instancie le contrôle Loader qui hérite de Window dans un nouveau thread.

Lorsqu’on lance une application WPF, l’application démarre pour nous un dispatcher pour le thread UI. Ici on le fait  à la mano grâce à la méthode statique Dispatcher.Run. Ainsi la fenêtre principale et la fenêtre loader tournent chacune sur leur propre UI thread.

Je vous laisse regarder le code ci-dessous qui se charge de ça. Notez au passage l’appel de la méthode Dispatcher.InvokeShutdown une fois la fenêtre fermée pour terminer le dispatcher.

Avec quelques styles il est également facile de transformer le visage du loader et faire en sorte de le montrer comme étant totalement intégré à la fenêtre principale.

Panel rootLayout = d as Panel;

          if (rootLayout == null)
              return;

          bool active = e.NewValue != null ? (bool)e.NewValue : false;

          if (active)
          {
              Thread thread = new Thread((data) =>
              {
                  NotificationData nData = (NotificationData)data;
                  indicator = new
                      BusyIndicator(nData.ParentWidth, nData.ParentHeight);
                  indicator.Message = nData.Message;
                  indicator.Show();

                  indicator.Closed += (s, ev) =>
                  indicator.Dispatcher.InvokeShutdown();

                  System.Windows.Threading.Dispatcher.Run();
              });
              thread.SetApartmentState(ApartmentState.STA);
              thread.IsBackground = true;
              thread.Start(new NotificationData
              {
                  Message = d.GetValue(MessageProperty).ToString(),
                  ParentHeight = rootLayout.ActualHeight,
                  ParentWidth = rootLayout.ActualWidth
              });
          }
          else
          {
              if (indicator != null)
              {
                  indicator.Dispatcher.Invoke(new Action(() =>
                  {
                      indicator.Close();
                  }));
              }
          }

Avec le CollectionViewSource il est plutôt simple d’y parvenir, en ne faisant que du XAML. Si vous désirez utiliser la fonctionnalité du filtre vous devrez passer par le code behind.

Les fonctionnalités de tri, filtre et groupe ne sont pas nouvelles en WPF, comme en Silverlight, mais auparavant vous deviez obligatoirement passer par le code behind pour les implémenter ce qui ne facilitait pas leur utilisation avec des outils comme blend.

Dès que vous passez une collection de données à la propriété Source du CollectionViewSource, ce dernier va générer une vue accessible via sa propriété View.  C’est sur cette vue jouant le rôle de wrapper que l’on peut ajouter le tri par exemple.

Prenons un cas simple.

Imaginons une classe collaborateur avec les propriétés suivantes.

public class Collaborateur
{
    public string Nom { get; set; }
    public string Prenom { get; set; }
    public int Age { get; set; }
}

Une fois notre liste de collaborateurs créée nous l’assignons au DataContext de la fenêtre principale de l’application.

List<Collaborateur> collaborateurs = new List<Collaborateur> {
               new Collaborateur
               {
                   Nom = "Arnaudet",
                   Prenom = "Alexandre",
                   Age = 25
               },
               new Collaborateur{
                   Nom="Arnaudet",
                   Prenom="Julien",
                   Age=19
               },
               new Collaborateur{
                   Nom = "toto",
                   Prenom="Bernard",
                   Age=54
               },
               new Collaborateur{
                   Nom="titi",
                   Prenom="Stephane",
                   Age=25
               },
           };

           this.DataContext = collaborateurs;

Ensuite dans le code XAML ajoutez une ListBox et avec la propriété ItemsSource, faites le binding sur le DataContext.

<ListBox ItemsSource="{Binding}"/>

Afin de rendre l’interface un peu plus jolie, personnalisons le ItemTemplate.

      <ListBox ItemsSource="{Binding}">
         <ListBox.ItemTemplate>
          <DataTemplate>
           <Border CornerRadius="5" Padding="5" BorderBrush="Black"
                   BorderThickness="1">
             <StackPanel Orientation="Horizontal">
              <TextBlock Margin="15,0,0,0" Text="{Binding Nom}"/>
              <TextBlock Margin="15,0,0,0" Text="{Binding Prenom}"/>
              <TextBlock Margin="15,0,0,0" Text="{Binding Age}"/>
             </StackPanel>
            </Border>
           </DataTemplate>
         </ListBox.ItemTemplate>
        </ListBox>

Vous devriez maintenant voir quelque chose ressemblant à ceci:

Quand l’utilisateur voit cette interface, il dit: “oui mais je souhaiterais que ces données soit triées par âge”. Ok c’est là qu’entre en jeu le CollectionViewSource. Retournons dans le code xaml et ajoutons le dans les ressources  de notre élément root.

        <Grid.Resources>
            <CollectionViewSource x:Key="CollaborateursViewByAge"
                Source="{Binding}">
                <CollectionViewSource.SortDescriptions>
                    <scm:SortDescription
                        PropertyName="Age"
                        Direction="Ascending"/>
                </CollectionViewSource.SortDescriptions>
            </CollectionViewSource>
        </Grid.Resources>

Premièrement notez que la propriété Source pointe sur l’élément courant ajouté au dataContext de notre vue et que nous avons un élément SortDescription sur lequel on indique la propriété à trier et la direction Ascending ou Descending.

Deuxièmement, il faut modifier également la propriété ItemsSource de la ListeBox pour qu’elle fasse le Binding sur le CollectionViewSource et non plus sur le DataContext.

  <ListBox ItemsSource="{Binding Source={StaticResource CollaborateursViewByAge}}">

Maintenant, imaginez que vous vouliez grouper les données par Nom. De la même manière qu’on a ajouté un élément SortDescription, on va ajouter au CollectionViewSource un PropertyGroupDescription.

 <CollectionViewSource.GroupDescriptions>
                    <PropertyGroupDescription PropertyName="Nom"/>
                </CollectionViewSource.GroupDescriptions>

Ce qui nous donne comme résultat:

Enfin pour mettre en valeur les différents groupes, nous allons afficher en tête de chaque groupe le nom sur lequel on se base pour grouper, grâce à la modification de la propriété GroupStyle de la ListBox.

 <ListBox.GroupStyle>
            <GroupStyle>
             <GroupStyle.ContainerStyle>
              <Style TargetType="{x:Type GroupItem}">
               <Setter Property="Template">
                <Setter.Value>
                 <ControlTemplate TargetType="{x:Type GroupItem}">
                   <GroupBox Header="{Binding}"
                             BorderBrush="Transparent"
                             BorderThickness="0">
                    <ItemsPresenter/>
                    </GroupBox>
                  </ControlTemplate>
                 </Setter.Value>
                </Setter>
               </Style>
              </GroupStyle.ContainerStyle>
             </GroupStyle>
            </ListBox.GroupStyle>

Souhaitant ne pas la montrer, pour donner un style différent à la fenêtre, je me suis retrouvé avec une  fenêtre qui dans la forme ressemble à l’exemple suivant.

Le problème est le suivant. Ok j’ai une jolie fenêtre. Mais comment puis-je la déplacer si la toolbar ne s’affiche pas.

Rien de bien compliqué, il vous suffit juste de rajouter la ligne de code suivante dans le constructeur pour y arriver et le tour est joué.

this.MouseDown += (s, e) => {
               DragMove();
           };