Code is poetry

Toujours des différences de comportement entre WPF et Silverlight

Silverlight 2 (beta 1) ressemble maintenant beaucoup à ce que l'on a pu apprendre avec WPF. Et en voyant la version alpha, on sait que ce n'était pas gagné d'avance. Beaucoup de concepts de WPF sont maintenant communs à Silverlight. Par exemple le styling et templating, le layout (d'ailleurs extensible exactement de la même façon qu'avec WPF), le binding, de nombreux contrôles communs à WPF, et bien d'autres choses.

Par contre, lorsque l'on regarde un peu plus dans les détails, on commence a remarquer beaucoup de différences. Par exemple, je me trompe peut être mais les Triggers pour les ControlTemplates ne sont pas présents dans Silverlight 2 beta 1. Un autre détail m'a frappé.

Silverlight 2 dispose maintenant du système de Dependency Properties qui comme pour WPF, est au coeur du databinding (je vous renvoie à cet article pour plus de détails sur les Dependency Properties). J'ai noté différence dans le comportement entre ces deux APIs.

Supposons que vous définissiez une dependency property comme ceci, avec son wrappeur CLR :

public static readonly DependencyProperty MassProperty = DependencyProperty.Register("Mass", typeof(float), typeof(Planet));

public float Mass
{
    get { return (float)GetValue(MassProperty); }
    set { SetValue(MassProperty, value); }
}

Lorsque vous définissez la propriété Mass depuis le XAML, la dependency property nommée Mass est directement définie, sans passer par le setter de la propriété CLR Mass. En Silverlight par contre, c'est le setter de la propriété CLR qui est appelée. Dans le cas ci-dessus, le résultat est bien sûr le même, mais si on décide de faire des choses supplémentaires dans le setter (ou même le getter), celles-ci seront appelées dans la version Silverlight, mais pas dans la version WPF.

Une autre différence est que si vous nommez le wrappeur CLR avec un autre nom que celui de la dépendency property (disons PlanetMass), vous aurez une exception au lancement de votre application WPF puisque WPF va chercher une dependency property du nom de PlanetMass, et celle-ci n'existe pas (elle s'appelle Mass). Avec Silverlight par contre, vous ne pourrez pas avoir d'exception si le code a compilé, puisque si le code a compilé, c'est que la propriété CLR utilisée dans le XAML existe, et c'est toujours cette propriété CLR qui sera utilisée.

Je dirais presque que le comportement de Silverlight est le plus naturel, puisque lorsqu'on tape du XAML, l'intellisense se base sur la déclaration de la propriété CLR (et pas sur la déclaration de la dependency, puisque celle-ci est déclarée par un appel à DependencyProperty.Register, ce qui n'est pas détectable par une analyse statique du code).

Espérons que ces différences s'effaceront avec les prochaines versions de Silverlight, mais la similarité des deux API est déjà relativement impressionnate.