[new:16/07/2010]Expression Blend 3 (et 4) fournit un certain nombre de ValueEditors personnalisés dans l'inspecteur de propriétés pour simplifier l’utilisation des Behaviors. Mais il y a un petit bonus : l’équipe de Blend a aussi introduit certaines extensions afin de permettre l’utilisation de ces éditeurs dans les Behaviors tiers.
Plus précisément, le ElementPicker, le StateNamePicker et le StoryboardPicker peuvent être réutilisés en plaçant le CustomPropertyValueEditorAttribute sur la propriété que vous souhaitez utiliser avec l'éditeur. L'énumération CustomPropertyValueEditor fournit les options disponibles :
Notez que le sélecteur de ElementPicker et de StateName s'attend à être utilisé sur les propriétés de type String, et que le StoryboardPicker s'attend à être utilisé sur une propriété de type storyboard. Il appartient à votre contrôle ou à votre Behavior de savoir quoi faire avec la valeur que vous obtiendrez en retour.
Voici un exemple d’implémentation utilisant ces attributs :
Un mot sur les métadonnées de conception
On voit ici que les attributs sont ajoutés directement aux propriétés et à la classe de runtime. C’est pratique, rapide, et cela fonctionne correctement.
Toutefois du point de vue conceptuel mais aussi purement pratique il ne s’agit pas d’une méthode à conseiller. En effet, les informations de design ne doivent pas être ajoutées aux classes de runtime. D’abord cela ajoute du code inutilisé au runtime et tout code mort doit être supprimé, ensuite cela entraine la liaison de certaines libs qui alourdissent inutilement l’application runtime. Conceptuellement la bonne séparation du fonctionnement design / runtime d’une classe s’impose raisonnablement comme la séparation du code d’interface de celui du code métier par exemple.
En réalité il faut donc absolument séparer le code design. Cela se pratique depuis l’existence des composants et les premiers EDI offrant un design visuel (Visual Basic ou Delphi) et cela doit toujours se pratiquer aujourd’hui. Il y a certaines choses que le temps qui passe et que les plus grands bouleversements laissent inchangées, en voici une…
Les méta données de design doivent ainsi être stockées dans une DLL à part, dont l’extension est “.Design”. Je traiterai certainement ce sujet d’ici quelques temps mais en attendant, et pour ceux que l’anglais ne rebute pas, vous pourrez trouver un article sur la question à cette adresse : Writing a design time experience for Silverlight control. L’article est même complété d’un template pour Blend créant un projet DLL + design experience. Il s’agit d’un article couvrant Blend 3, le contenu est toujours juste techniquement, le template, en revanche, peut ne pas fonctionner avec Blend 4 (je n’ai pas eu le temps de tester).
Vous trouverez aussi des informations intéressantes dans l’article suivant : A sample that shows the new Blend design surface extensibility. L’article traite l’exemple sous WPF mais cela est transposable à Silverlight car il s’agit là bien plus de Blend et de son EDI que de la cible Xaml choisie.
Conclusion
Ecrire des composants et des Behaviors n’est pas forcément très compliqué, mais les écrire bien, c’est à dire en fournissant un code propre et documenté, un fichier d’aide et des mécanismes en simplifiant l’utilisation au design demande plus de travail. Le résultat est plus “pro” aussi…
Stay Tuned !