Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Caspol le casse-pieds, .Net Configuration manager absent : comment exécuter un code sur un partage réseau avec VS (site ASP.NET par exemple) ?

[new:12/10/2010]Exécuter et déboguer du code sur un réseau (un partage, un “share”) pose des tas de problèmes de sécurité. On peut bricoler les paramètres de Visual Studio mais pour un site Asp.net c’est le serveur de débogue lui-même qui ne veut pas fonctionner. Comment faire ?Plus...

SeedFucker, Hadopi et C#

Voici un beau cocktail ! Pouvoir à la fois parler de C#, donc en plein dans le sujet de ce blog, et de Hadopi, un système liberticide non pas dans son fondement (le respect de la propriété intellectuel est un sujet sérieux) mais dans sa forme. Vous commencerez à recevoir vos premiers emails le 21 juin, c’est décidé et c’est en route ! Plus...

Blocage IE avec écran multitouch sous Silverlight

Voici un cas intéressant dont je viens de trouver la solution et que je m’empresse de vous communiquer…

Les écrans multitouch ne sont pas encore légion, sauf chez quelques geeks, dont je suis. Ainsi, pour tester dans un mode proche de la réalité les applications Phone 7 en cours de développement (et faute de téléphones de ce type disponible sur le marché pour l’instant) j’ai acquis un écran 22 pouces IIYama multitouch T2250MTS. C’est très sympa, pas très cher et ça marche vraiment bien de base avec Windows 7 sans installer aucun driver (c’est à dire que Windows 7 possède déjà le fameux driver et que brancher l’USB de l’écran sur le PC suffit sans aucun pilote extérieur ni CD d’installation, c’est beau le progrès !).

L’écran est même fourni avec un stylet qui se cache dans le bas de son boitier, ce qui évite les traces de gros doigts graisseux sur l’écran ! :-)

Bref, tout cela fonctionne à merveille et du premier coup. Quand on arrive sur des zones de saisie et qu’on touche l’écran il y a même un petit symbole de clavier qui apparait pour permettre d’ouvrir un grand clavier virtuel, voire le module de reconnaissance d’écriture. On voit que Windows 7 a été conçu pour investir les Tablet PC… Vraiment cool. Seul bémol, sur un écran vertical manipuler les applis avec les doigts à bout de bras c’est vite crevant… Mais ce n’est pas pour cela que j’ai acheté l’écran, c’est pour utiliser l’émulateur de Phone 7 en mode multitouch (car tester une appli pour téléphone touch avec la souris c’est le meilleur moyen de foirer le design, les doigts sont plus gros et moins précis, il faut y penser à la conception !).

Vous allez me dire c’est quoi le rapport avec Silverlight et Internet Explorer ?

C’est tout simple.

Plantage avec Silverlight ?

Silverlight gère le multitouch. Au moment où internet exploreur se lance et affiche l’application quand je suis en  debug (sous VS ou Blend) je ne sais pas trop quel niveau de sécurité IE reconnaît (en tout cas pas Intranet local car j’ai abaisser toutes les sécurités à ce niveau et cela n’a rien changé) mais à l’activation du plugin Silverlight IE 8 s’arrête, comme planté.

Impossible de s’en sortir. Il faut aller le shooter depuis les processus de Windows ou bien stopper le debug sous VS ce qui a le même effet.

Sécurité cachée !

Et là, l’oeil averti du chasseur de bug voit passer à toute vitesse comme une petite fenêtre cachée sous IE qui, hélas puisqu’on vient de flinguer IE, disparait sans qu’on puisse la lire…

Il y a donc une question qui est posée, en modal, ce qui bloque IE 8. Il “suffit” donc d’accéder à ce dialogue.

Je n’ai pas réussi. Et si on minimise IE pour que ça ne soit plus qu’un petit carré minuscule, on ne voit pas derrière la fenêtre du dialogue… Elle ne vient donc que quand IE est shooté. Bug…

Problème numéro 1: Identifier cette fichue fenêtre.

Ca passe tellement vite que c’est illisible bien entendu.

Ruse : Utiliser l’enregistreur d’écran livré avec Expression Encoder 3 et enregistrer la vidéo du bug pour faire ensuite un arrêt sur image et lire le texte du dialogue…

Ca ne marche pas au premier essai car ça va vraiment vite. Il faut ruser encore plus en modifiant les réglages d’enregistrement de la vidéo, notamment en passant à 100 images secondes et un débit d’au moins 20.000/s.

Là, on finit par choper sur la vidéo un “fantôme” du dialogue plus ou moins opaque selon la chance qu’on a. Mais on l’a eu ! Et que lit-on ?

“Un site Web veut ouvrir un contenu Web en utilisant ce programme sur votre ordinateur” et en dessous : Nom: Composant de saisie tactile ou avec sty…, Editeur: Microsoft Windows.

Le nom du composant n’est pas complet mais on a compris de ce quoi il s’agit. Silverlight, le plugin, au moment du chargement (car la première instruction de l’appli n’est pas encore atteinte, ce que prouve le debugger) doit forcément inspecter la machine pour savoir s’il y a de la vidéo, du son, et tous les périphériques ou facilités utilisées par le plugin. Parmi celles-ci se trouve vraisemblablement le multitouch et la gestion du stylet.

C’est à ce moment que le fameux dialogue est activé pour me demander si je donne le droit ou non à ce module de s’activer. Normalement on dispose sur ce genre de dialogue d’une case à cocher permettant d’indiquer si on souhaite ne plus voir la question.

Hélas, comme IE 8 semble avoir un léger bug, ce fichu dialogue est totalement incessible, on le voit à peine quand on shoote l’application. Et encore faut-il la ruse de la vidéo pour lire de quoi il s’agit.

Comment autoriser l’application bloquante ?

Second problème alors : comment autoriser le programme en question (la gestion du stylet) alors même que le dialogue et sa case à cocher ne sont pas accessibles ?

Réponse : en plongeant dans les arcanes de la gestion de sécurité de IE 8…

Et là, ce n’est pas de la tarte… J’aime bien IE, mais ce n’est pas d’une grande limpidité dès qu’on aborde ce genre de question.

Je vous fait grâce des multiples recherches sur le Web pour arriver à trouver une réponse utilisable. Que je vais maintenant vous exposer car ça peut servir ! (et pas seulement avec un écran multitouch, je suppose que le bug du dialogue doit se voir dans d’autres cas).

Pour faire simple, IE range dans la registry la liste des programmes ayant des droits faibles ainsi que la règle d’élévation de droit qui doit être appliquée. Comment certaines applications arrivent dans cette première liste, c’est un mystère que je n’ai pas essayé d’éclaircir, ce genre de plomberie en informatique me donnant rapidement la nausée. Donc, il existe dans la registry une première liste, elle se trouve là :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\

C’est une liste d’ID, donc de GUID. Il faut la balayer pour lire les clés qui correspondent afin de localiser le programme dont on veut changer les droits. (La registry doit être ouverte en mode administrateur cela va sans dire).

Pour ce qui est du stylet, j’ai fini par trouver le coupable, c’est le programme “wisptis.exe” qui se trouve dans %SystemRoot%\System32. Les clés d’un ID sont AppName, le nom de l’appli, ici celui de l’exe (ce qui ne simplifie pas la recherche vu à quel point le nom n’est pas parlant), AppPath, le chemin que je viens d’indiquer et enfin Policy, un DWord codant l’autorisation.

Vous trouverez des explications ici : http://www.hotline-pc.org/mode-protege.html#

Une fois l’application localisée dans cette première liste on a la moitié de la solution. Changer la Policy à ce niveau ne semble pas avoir d’effet (immédiat en tout cas).

Il faut savoir qu’en réalité, pour l’utilisateur courant, IE stocke une seconde liste, similaire, dans une autre clé de la registry :

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

L’astuce consiste donc à créer une nouvelle clé dans cette liste en utilisant le GUID repéré dans la première liste puis de recréer à la main les clés, dont Policy à laquelle on donne une valeur dépendant de ce qu’on cherche à obtenir. Pour la gestion du stylet j’ai mis 3, qui semble donner le maximum de droits.

Je reviens sous VS, je lance mon appli SL, et là, Ô magie… mon appli s’affiche et IE ne pose plus l’infamante question cachée…

Et ça marche !

Problème résolu. Comme on ne peut pas dire que la solution est évidente, je pense que la partagée ici sera un jour utile à quelqu’un.

Visiteur qui tombera au hasard d’une recherche Bing ou Google sur cette page et qui gagnera quelques heures de ton précieux temps, n’hésite pas à me laisser un message, ça fait toujours plaisir ! Quant aux fidèles lecteurs de Dot.Blog, le jour “J” j’espère que vous vous rappellerez que ce billet existe !

Et pour d’autres infos le mieux c’est : Stay Tuned !

Une dernière info : Le multitouch de l'écran utilise une barrière infrarouge visiblement, c'est à dire que les doigts ou le stylet coupe une grille infrarouge invisible. Ca marche vraiment bien. Sauf qu'en cette époque estivale, les mouches arrivent ! Et dans ma campagne elles ne sont pas en retard ! Hélas quand une mouche se pose sur l'écran : elle clique ! Ce qui fiche un beau bazard parfois ! Prévoyez ainsi avec l'achat d'un écran de ce type un désinsecteur électrique qui grillera tous ces nuisibles qui prennent votre écran pour un tarmark ! Je sais ça fait un peu rire comme truc... mais le geek n'a pas que des aventures palpitantes, il doit aussi combattre, outre les bugs, les mouches et autres diptères !

Le retour du spaghetti vengeur

Le code spaghetti est de retour ! Fuyez braves gens !

Sous-titré : Du Rififi dans le Xaml.

Avertissement au lecteur : ce billet, bien que bâti sur un fond technique préoccupant et une expérience réelle, utilise un formalisme un peu romancé. Ne cherchez pas d’extraits de code ici. Mais si vous avez un peu de temps, laissez vous porter par l’histoire. Si vous êtes pressés, revenez plus tard lire ce billet !

Genèse d’un malaise

Comme vous le savez je suis un passionné de WPF et de Silverlight, la puissance de Xaml servi par un Framework aussi riche que .NET et des outils de qualité comme Blend ou Visual Studio ne peuvent laisser de marbre (comment peut-il y avoir encore des gens travaillant sous Java ou Delphi ?). J’en suis tellement passionné que j’évangélise à tour de bras, ici et ailleurs, et que mes compétences autant techniques que de gardien des brebis égarées me valent d’avoir l’honneur d’être Microsoft MVP, notamment en 2010 pour les technologies de développement d’applications clientes (Client Application Development, “CAD”" MVP).

Bref, si je dis tout cela c’est pour faire comprendre que bien que cultivant mon objectivité comme un joyau précieux garant de la liberté de mes neurones, je suis plutôt “pro” Microsoft et que, bien entendu, cela peut déplaire à certains comme en séduire d’autres… La diversité du monde en fait sa richesse, isn’t it.

Et un partisan de Microsoft, MVP de surcroît, fan de Silverlight, ne dira jamais le moindre mal de sa technologie fétiche… Et soyez-en convaincu je ne briserai pas cette loyauté, essentielle à mes yeux, mais il faut pourtant savoir tirer les sonnettes d’alarme de temps en temps. D’ailleurs c’est une question de crédibilité, que vaudrait un expert sans liberté de parole ni de pensée… Et puis au fond vous verrez que c’est bien plus, comme à chaque fois, l’humain qui en prend pour son grade dans ce récit que les outils, innocents, par nature.

Tout cela pour parler franchement d’un risque, d’une dérive, et surtout d’un grand danger : le retour du code spaghetti ! Et, comble de l’infamie, la peur de cette tare qu’on croyait du passé, je ne la brandis pas à propos de langages ésotériques comme F#, ou de solutions vieillissantes comme Java. Non. Le drame est bien là : c’est de WPF et de Silverlight dont je veux vous entretenir, et ce, au travers d’une anecdote récente.

J’ai fait il y a quelques temps un audit dont je tairais, vous le comprendrez aisément, le nom du client visité ainsi que la date exacte. Au demeurant une société ni trop jeune pour n’être pas assez structurée, ni trop vieille pour en être devenue ringarde. Une entreprise de bonne taille, assez dynamique et assez typique de ma clientèle, se targuant de posséder une équipe de développement à la pointe du progrès, la preuve, puisque maniant les balises Xaml avec la même dextérité que la truelle l’est par un vrai maçon diplômé.

Le trait n’est pas forcé, il n’y en a nul besoin. Ce fut au début un audit “classique” c’est à dire durant lequel j’ai vu du code “normal” donc assez médiocre. Je dis “normal” au sens de la loi normale statistique ce qui signifie que grâce à  messieurs Laplace et Gauss il m’arrive de voir des choses épouvantables comme de pures merveilles, mais que ces deux cas représentent un pourcentage faible au deux bouts de la cloche… Je ne savais pas encore que j’allais atteindre le bout de la cloche. Le mauvais. Bien entendu.

Espèce de spaghetti !

Le code “normal” est médiocre généralement. C’est finalement une définition en soi. Le code exceptionnel, étant, par le même genre de raisonnement, plus rare. C’est finalement une lapalissade. Donc, en général, je vois du code médiocre, donc normal (dans l’autre sens c’est intéressant aussi, non ?).

Et j’appelle médiocre un code qui se caractérise par plusieurs aspects distinctifs très techniques que je détaille avec moult délicatesse dans mes rapports d’audit pour expliquer les choses en y mettant les formes mais qui se résument en général à quelques cas généraux qu’on pourrait caractériser très doctement. Je m’exprimerais ici de façon bien plus directe puisqu’on est “entre nous” :

  •  
    • La “putain” c’est à dire le code sur lequel tout le monde est passé, sauf le train et vous, mais ça, c’est même pas sûr, puisque vous êtes là… C’est du code typique des boîtes où les gens sont mal payé et où les salariés défilent plus vite qu’une hirondelle dans un ciel de printemps…
    • Les migrations de migrations de portage d’intégration (de milles sabords, version 24 bis modifiée E). En général du code qu’on trouve dans les administrations. Avec des documentations de plusieurs centaines de pages, que personne n’a jamais lu bien entendu.
    • Le code mille-feuille. Savoureuse pâtisserie constituée de tant de couches qu’on ne peut les compter, comme les pattes du iule (autrement appelé mille-pattes). C’est un peu un mélange des deux précédents mais en plus structuré que le premier (beaucoup plus, et c’est la son problème) et en moins documenté que le second (beaucoup moins, et c’est aussi là son problème). C’est du code de SSII “in” avec de vrais morceaux de “nouvelles technos” dedans.
    • Le code “start-up”, celui-là est bourré de technos innovantes, hélas non maîtrisées, peu documentées et en bêta ne tournant que sur les versions US de l’environnement. Un code d’essayiste pur travaillant pour la beauté du discours qui va autour plus que pour l’efficacité, des gens qui devraient être en agence de pub plutôt que devant un environnement de développement.
    • Le code à papa, ou l’objet est utilisé comme du C procédural. C’est le code C# écrit par de vieux delphistes ou cobolistes reconvertis sur le tard par exemple.
    • Le code d’ingénieur, un des pires. Sortant de l’école et voulant montrer ses muscles en complexifiant tout et l’enrobant dans une prose technique pleine de sigles bizarres et de référence à des bouquins lus de lui seul et de ses potes de promo. Quand il arrêtera de sucer son pouce, il deviendra un bon développeur sévèrement burné comme disait Tapie. Mais en attendant son code c’est l’enfer…
    • Et enfin, le célèbre, le magnifique, le code spaghetti, marquant l’incompétence à maîtriser la complexité du sujet. Celui-là est typique des mauvaises équipes, tous contextes confondus.

Il y en a bien d’autres dans mon bestiaire, en 20 ans d’audit vous imaginez ce que j’ai pu voir (heureusement je rencontre aussi des équipes compétences et même parfois de l’excellent code, sinon ça serait désespérant !).

Et WPF et Silverlight dans tout ça ?

C’est là que je voulais en venir, mais il fallait bien passer par ce détour pour vous plonger dans l’ambiance trouble de cette descente aux enfers binaires. Sinon cela aurait été d’une platitude redoutable. Un peu de lecture ça change des extraits de code en Xaml. Justement. Parlons de lui et de ce dernier audit (qui n’est pas le dernier, confidentialité oblige comme je le disais plus haut). Disons que c’est assez récent pour être en Xaml mais pas suffisamment pour être en Silverlight 3.

Qu’avait ce code qui vaille ce billet un peu particulier ?

Le code qui rend fou

il m’a rendu fou. Tout simplement ! Et en plus il m’a filé les chocottes !

WPF et Silverlight sont des technologies merveilleuses, Xaml a un pouvoir descriptif exceptionnel à tel point qu’il permet d’économiser beaucoup de code behind.

Malgré le génie des équipes MS ayant travaillé sur le Framework j’aurais malgré tout préféré que cette révolution se fasse à 100% dans le respect du paradigme objet et du fortement typé. Or ce ne fut pas totalement le cas, et si je comprends bien les contraintes techniques sous-jacentes qui ont interdit cet idéal, certains choix sont hélas autant de portes ouvertes sur des risques que je viens de palper de près. Et ça fait peur.

Il y a en premier lieu l’architecture. Il ne suffit pas de prendre Prism et ses Dll pour avoir un bon logiciel. Il faut comprendre et maîtriser la chose. Ce qui ne s’improvise pas. Mais il y a pire, car plus lié à la technologie elle-même.

Par exemple, prenez la syntaxe du Binding, en Xaml donc. Vous avez une balise, vous la complétez d’une propriété et là, au lieu de mettre une valeur, vous ouvrez des accolades américaines suivies du mot Binding, le tout entre guillemets, une simple chaine de caractères. Quant à ce qu’il y a après le mot Binding, je suis convaincu qu’aucun aficionado de WPF ou de Silverlight n’est capable de me citer de tête toutes les combinaisons possibles et astuces disponibles. Parfois  c’est {Binding} tout court, parfois c’est une longue phrase intégrant imbriquées d’autres accolades faisant référence à des ressources statiques ou dynamiques, des paramètres, des convertisseurs, etc… Une puissance énorme, un peu comme les expressions régulières : puissant mais pas très clair (et c’est un euphémisme). Pas clair, on peut s’y faire… mais pas clair et pas fortement typé ni même contrôlé, c’est là que la chute aux enfers commence…

Le code que j’ai audité était bourré d’element binding, de datacontext pointant des conteneurs de services avec des indirections dans tous les sens “pour la souplesse”. Quand MVC et MVVM ne sont pas compris, mieux vaut tout mettre en procédural dans le code-behind de chaque fiche, c’est plus simple à débugger ! Le pire c’est que chacun dans l’équipe y allait de sa petite couche, de sa petite modification. Et je fais du “refactoring” par là, et je refactore par ici… Oui mais voilà, dans les balises Xaml ça commence à danser le cha-cha-cha toutes ses chaînes de caractères non contrôlées, tous ces paramètres de convertisseurs qui ont évolués sans qu’on ait mis à jour les références dans le Xaml, ces ressources statiques et d’autre dynamiques dans des dictionnaires chargés dynamiquement !

Le soft ne tenait plus que par un fil qu’un joyeux drille a du couper juste avant que je n’intervienne. Dommage. Je n’arrivais même pas à dépasser un ou deux écrans avant que ça me pète à la figure. Même avec des outils très intelligents comme NDepend, comprendre le soft était virtuellement impossible.

Quant à savoir d’où vient “le” problème ! C’est le soft lui-même tout entier qui était “le” problème… Ainsi que ceux l’avaient écrit (et ceux qui les dirigent, car un mauvais soft est toujours la cause d’une mauvaise direction bien plus que de mauvais développeurs).

En fait, le Binding Xaml est une porte ouverte sur l’inconnu. Une feature d’une grande puissance, sans laquelle beaucoup du charme disparaîtrait, mais assez déraisonnable dans cette implémentation libre sous forme de chaînes de caractères non compilées. La porte sur le néant, l’incontrôlé, et pire : l’incontrôlable. Un trou noir syntaxique. La damnation du testeur envoyé moisir au purgatoire des pisseurs de ligne. Et l’enfer de l’auditeur.

le Binding au pays des X-Files

Le Data binding Xaml est une jungle syntaxique pas très bien … balisée et totalement déconnectée de toute forme d’analyse à la compilation. du “Late Bugging” comme je m’amuse à appeler cette stratégie de type “late binding”, principe de ligature tardive utilisé d’ailleurs en d’autres endroits et même sous d’autres frameworks. Pire que les Dynamic de C# 4 (pratiques mais dangereux), pire que F# (stimulant mais pas industrialisable), le Binding de Xaml est un gouffre à bugs, un chien fou s’il n’est pas tenu en laisse fermement.

En réalité un marteau ne pourra jamais être jeté aux fers (!) pour le meurtre de qui que ce soit. Un marteau est un outil, et même s’il a servi et servira encore dans de nombreux crimes, un outil est un objet sans âme, sans conscience et donc sans responsabilité. Même un fusil mitrailleur est un objet innocent, même un canon de 105 ou une bombe atomique sont plus innocents que l’agneau qui vient de naître et qui, comme tout être vivant, et à la mesure de son intelligence, portera le poids de la responsabilité de ses agissements. Un outil de développement restera donc à jamais hermétique à tout procès d’intention. A celui qui s’en sert de le faire correctement.

Il en va de même de Xaml, de son data Binding et de bien d’autres de ces facettes. La responsabilité incombera toujours à l’humain qui tient le marteau. A l’informaticien qui tient la souris. Au développeur qui tape un code affreux.

Mais certaines features de Xaml, certains choix conceptuels comme l’utilisation de chaînes de caractères non contrôlées et non parsées à la compilation sont à mon sens des erreurs. Si des projets comme celui que j’ai audité et dont je vous parle ici devenaient courants, nul doute que cela signerait l’arrêt de mort de WPF et de Silverlight. La faute aux mauvais développeurs ? Pas seulement. A ceux aussi qui ont décidé de programmer Xaml de cette façon trop ouverte, trop permissive. On voit bien comment Silverlight a été verrouillé dès le départ par Microsoft. Si le moindre virus, le moindre phishing avait été réalisé avec Silverlight 1 ou 2 c’en était fini des espoirs portés par cette technologie. Microsoft a été méfiant pour préserver l’avenir de la technologie et c’est une bonne chose. Ce que j’ai vu dans le projet WPF dont je parle ici, c’est un peu de la même nature, mais à l’inverse : Microsoft n’a pas verrouillé Xaml comme cela a été fait avec Silverlight. Et si de tels détournements se généralisent c’est toute la technologie qui trinquera. D’ici un an environ, lorsque les projets lancés ces derniers temps seront finalisés, et qu’il faudra compter ceux qui n’aboutiront pas ou qui ne marcheront jamais bien, la note peut être salée pour Xaml. Microsoft a pris un sacré risque en faisant des choix de conception comme celui des balises non compilées (et dans lesquelles même Intellisence se prend les pieds dans le tapis).

Déjà sous Delphi je voyais souvent ce genre de code spaghetti avec des variables globales référencées n’importe où, des fiches utilisant des variables d’autres fiches jusqu’à créer des chaines de dépendances ingérables. J’ai vu des codes de ce type ne pouvoir jamais aboutir. Il m’est même arrivé une fois de réécrire en 15 jours proprement à partir de zéro un soft développés en 1 an par deux personnes sans le dire au client histoire que les 15 jours d’expertise qu’il m’avait payés servent à quelque chose… Je tairais ici le nom du client (une administration). J’étais plus jeune et je voulais me prouver des choses certainement, mais personne ne l’a jamais su jusqu’à ce billet (et encore vous en savez peu!). En tout cas ce projet là je l’ai sauvé. Mais être un pompier de l’ombre n’est pas ma vocation. Les gars étaient malgré tout étonnés ne pas vraiment s’y retrouver dans “leur” code. Amusante situation. Je n’avais rien gardé de “leur” code :-) Mais le soft marchait…

Mais avec Xaml, et une puissance décuplée, je viens de voir des horreurs du même genre alors que depuis des années, je commençais à trouver que C# incitait plutôt à faire du code “correct”, le niveau étant globalement meilleur que celui que je voyais sur Delphi. Et patatras ! Xaml arrive avec ces chausses-trappes dans lesquels les développeurs s’engouffrent. La faute à Xaml ? Pas totalement, mais si tout était typé et contrôlé à la compilation certaines mauvaises utilisations ne seraient pas possibles. Après tout, le fortement typé en soi ça ne sert à rien si on suppose que tous les développeurs sont “bons” ! Mais tous les langages modernes tentent de l’être car on sait que l’humain est faillible. En créant une brèche incontrôlable dans un édifice aussi beau de Xaml, ses concepteurs ont fait un pari risqué. Celui que tous les développeurs sauraient maîtriser le potentiel sans tomber dans ses pièges. Un pari forcément perdu d’avance.

Vision d’horreur

Ce que j’ai vu est donc indescriptible. Un peu comme si j’essayais de décrire Cthulhu. Ceux qui ont essayés sont souvent morts avant de finir d’écrire son nom (ah Lovecraft…) !

Imaginez vous un logiciel de 250 fiches WPF environ utilisant de l’ADO.NET, des bouts de LINQ to SQL, et des nouveautés en Entity Framework, le tout à la sauce Prism / MVC (mais en ayant lu le manuel certainement à l’envers car Prism c’est très bien !) avec des tentatives d’inversion de contrôle (et des dérapages non contrôlés) farci d’un code Xaml bourré de Binding renvoyant vers on ne sait quoi (et hélas pas contrôlé à la compilation), le tout planqué dans 4 ou 5 couches DAL, BOL pré-BOL, post-BOL, et j’en passe, histoire de faire court. La note s’élève a 6000 jours/homme (5 ans/homme environ). Pas un truc gigantesque mais qui commence à faire mal au budget malgré tout.

Agrémentez le tout de deux systèmes de versionning dont aucun n’avait vraiment une version complète du soft, des essais épars de tests unitaires avec MbUnit et VSTS. Vous obtiendrez le tableau. Une œuvre qui dépasse le classicisme habituel de ce point de vue, plus proche du Cubisme que de l’Hyperréalisme tout de même, avec au moins la bonne volonté de faire des petites choses (du mauvais testing prouve au moins qu’on a essayé de tester, ce qui est encore bien rare…). Mais l’enfer est pavé de bonnes intentions, c’est un peu ça le problème.

Le code était impossible à maintenir, les problèmes de performances impossible à cerner sans y passer plus de temps qu’à toute refaire, le code Spaghetti, avec un grand S avait frappé de son coup de poignard vengeur et lâche dans le dos. Une complexité non maîtrisée qui tel l’horizon d’un trou noir aspirait irrémédiablement le bon code vers l’enfer central laissant le hasard faire le tri entre les chemins à prendre… Démêler l’écheveau n’était pas possible, pas plus que de formuler des guidelines sérieusement applicables dans un tel contexte ni aucun conseil pour se sortir d’une telle situation.

Vous imaginez peut-être l’horreur qu’a été l’écriture du rapport d’audit. Entre dire une vérité que personne n’était prêt à entendre et mentir sachant que peu importe ce que je dirais cela passerait mal et qu’au fond mieux valait ne pas trop déplaire… Mon éthique a tranché, j’ai dit la vérité. En l’enrobant. Des heures passées à réécrire deux fois, dix fois certains paragraphes. Ils ne s’en douteront jamais… Et au final un rapport qui sera peut-être classé au fond d’un tiroir car personne ne voulait vraiment savoir ce qui n’allait pas. La remise en question d’un tel échec dépasse de loin le cadre technique et peu de gens savent admettre leurs erreurs, surtout quand toute la chaîne hiérarchique de la base au sommet doit participer à ce questionnement.

Le salaire de la peur

La peur dont je parlais plus haut, les chocottes que cet audit m’a données, c’est d’être confronté au fleuron de la technologie informatique, à des choses en lesquelles je crois car elles marquent un réel progrès et que (bien utilisées) elles permettent justement un code limpide. Cet audit a brisé ce fantasme en me rappelant qu’un marteau pouvait servir au meilleur, comme au crime. Xaml, WPF et Silverlight n’échapperaient pas à la règle et il faudra être vigilant. Surtout que l’avalanche de technologies et de patterns (WCF Ria Services, Entity Framework, MVVM, Prism, …) rendent presque impossible la maîtrise de tous ces sujets. Je suis payé pour ça. Au minimum 50% de mon temps est passé en autoformation pour apporter un conseil éclairé sur les technos à venir. Ce sont les 50% vendus qui financent cette formation et cette recherche permanente. Comment un développeur qui fait ces 48h (35 de base + le dépassement obligatoire non payé car il est aux “cadres”) peut-il se former à tout cela en travaillant sur d’autres projets la journée ? C’est impossible. Et cela créé une situation très dangereuse. Technologie sophistiquée + manque de formation = code spaghetti !

David Vincent au pays des tags

Il était donc urgent de vous en parler, d’attirer votre attention sur certaines dérives, car dans une moindre mesure, je sais, je l’ai vu chez d’autres, ces chausses-trappes savent s’ouvrir sous les pieds des développeurs les mieux formés et les mieux intentionnés !  Je les ai vues, et je dois convaincre un monde incrédule…

Ma mission, que j’ai acceptée (forcément avant de voir, on a pas vu…), était de faire un audit de pré-release. C’est à dire de venir faire le point sur l’état de la situation, les derniers fameux “boulons à serrer” en quelque sorte, et surtout de venir signer un satisfecit au DI, très fier de son bébé (Rosemary’s baby plutôt que Dora de TF1 au final), afin qu’il puisse faire monter sa prime de fin d’année je suppose.

Hélas, déception et vilenie. Ce n’est pas avec le prix d’un audit (fort raisonnable, devis gratuit sur simple demande) qu’on achète ma conscience. Il m’a donc fallu trouver les mots et les formules diplomatiques pour rendre un audit policé et mesuré sur cet édifice in-maintenable, voué à l’échec et bon à mettre à la broyeuse. Ce n’est pas la partie la plus difficile, car tout rapport d’audit se doit d’être policé et tourné de façon neutre et technique. Même si parfois on a envie de crier “bande de nuls !”, non, ce n’est pas bien, on ne le fait pas…

Que les futurs clients ne s’affolent pas trop, ce que je raconte aujourd’hui est malgré tout à classer dans les exceptions, le fameux bout de la cloche de la courbe Normale. Même si je ne suis que rarement content du code que je vois, on est, heureusement en moyenne, assez loin de l’horreur qui justifie le présent billet !

O Tempora, O Mores !

Parfois je rêve, j’imagine un monde où l’un de ces clients m’appellerait en me proposant un pont d’or pour lui avoir ouvert les yeux et l’avoir empêché de plonger plus encore tant qu’il était encore temps… Mais ce n’est qu’un rêve, bien entendu. Je suppose que je n’entendrais plus parler de ce client comme de quelques autres dont, les années passant et les vœux annuels restant sans réponse m’ont forcé à une résignation réaliste. Comme le chantait l’artiste, “il a dit la vérité, il doit être exécuté” !

Hélas, les temps ne sont pas à la prise de conscience ni à la bravoure. Nous vivons une époque de lâches où chacun ouvre son parapluie pour que les gouttes en atteignent d’autres. Forcément celui qui est au plus bas de la pyramide se prend tout sur la figure. Souvent c’est le développeur qui trinque pour une chaîne hiérarchique défaillante qui n’a pas fait son métier et qui n’assume pas ses responsabilités. Un développeur n’est jamais coupable seul d’un mauvais code, c’est toute la chaine de commandement qui faillit.

Il y a encore un rêve que je fais et que j’aimerais voir se réaliser avant ma (encore lointaine) retraite : que les entreprises fassent intervenir un conseil, un auditeur avant que l’irréparable ne soit commis, pas après pour constater les dégâts ! … ça serait tellement mieux et plus gratifiant pour moi et mes confrères ! Conseiller, orienter, former, en un mot aider, c’est tout de même plus chouette que de passer pour le père fouettard et l’inspecteur des travaux finis !

Faut-il brûler Xaml ?

Certes non.

Mais ce que je veux qu’il vous reste de ce récit hallucinant autant que réel, c’est que Xaml est utilisé par certains comme un langage dans le langage. Un moyen de vider le code-behind de son C# pour remplir des balises ésotériques. Un langage dans le langage avec son Binding qui est, telles le sont les poupée Russes, encore un langage dans le langage.

A vouloir tout faire par binding, à tout dynamiser, à appliquer tout Prism et le chargement dynamique des modules, la découvertes des plugins avec MEF, le tout mis en forme façon MVVM, sans compter les ruses purement graphiques du templating sous Blend, des DataTemplate à double face pivotante en 2,5 D, à vouloir appliquer tout cela dans un seul soft sans avoir pris les 2 ou 3 ans nécessaires à acquérir la parfaite maîtrise méthodologique pour faire marcher tout cela ensemble, on peut facilement arriver à une situation désastreuse. Encore plus facilement que sous C, encore plus que sous Delphi, pire que sous Windows Forms. Tout cela n’était que de l’amateurisme face aux dérapages délirants que WPF et Silverlight peuvent permettre… Comment faire des tests unitaires parlants sur des balises de Binding imbriquées à un tel point que même Intellisense de VS s’y perd ?

L’extrémisme essayiste est un fléau dans notre métier. Il m’a toujours effrayé, mais il a toujours eu sa sanction “naturelle” : une technologie qui finit par être si mal utilisée créée une telle publicité négative qu’elle tend à disparaître. Je ne voudrais pas que cela arrive à WPF et à Silverlight qui apportent tant d’autres progrès !

Il faut sauver le soldat Xaml !

Pitié pour Xaml, un bon geste pour WPF et Silverlight : ne laissez pas des sagouins faire du mal à toutes ces belles technologies que Microsoft nous offre depuis quelques années. Laissez leur une chance, celle que les développeurs deviennent plus matures et mieux formés aux méthodologies qui vont avec. Ne commettez pas le crime d’être complice de ce genre de chose. Intégrer les technologies les unes après les autres, ne sautez pas d’une bêta à l’autre sans avoir l’assurance que vous maîtrisez la précédente !

Mieux vaut une application Silverlight fonctionnant avec un Service Web classique et dont les champs sont connectés par code, qui marche et qui est maintenable, qu’une élucubration technologique improbable et non maîtrisée qui s’écroulera comme un château de carte au premier éternuement du premier bug venu…

Un peu de sérieux…

Il ne s’agit pas d’une invitation à la méfiance, encore moins au passéisme. Non, c’est une invitation au professionnalisme : n’utilisez que ce que vous maîtrisez.

Si vous maîtriser le top de la techno, allez-ci, franchement. Si vous avez un petit doute : faites joujou dans une machine virtuelle et produisez du code que vous comprendrez à 100% et surtout que d’autres pourront comprendre pour le maintenir, le faire vivre dans les années à venir.

Le code Kleenex coûte cher, il dévalorise notre métier et les outils que nous utilisons.

Le code spaghetti peut assassiner une technologie.

Codez bien. Formez-vous bien.

Et faites auditer vos projets avant, pas après.

Et Stay Tuned, j’aurais des trucs plus légers à vous dire la prochaine fois !

Silverlight 3 : Gestion des cookies

Silverlight propose un espace de stockage privé pour chaque application sur la machine cliente. Cet espace s'appelle l'Isolated Storage (stockage isolé, car protégé et isolé du reste de la machine cliente). C'est dans cet espace qu'il est conseillé de sauvegarder les données propres à l'application (j'y reviendrai dans un prochain billet). Toutefois on peut amené pour certaines informations à préférer le stockage sous la forme de Cookies traditionnels. On peut aussi avoir besoin de lire certains cookies posés par l'éventuelle application hôte en ASP.NET par exemple.

Quelles que soient les raisons, il peut donc s'avérer utile de manipuler les cookies depuis une application Silverlight.

L'application exemple ci-dessous vous permet de tester en live cette fonctionnalité :

[silverlight:source=/SLSamples/Cookies/Cookies.xap;width=380;height=322]

Techniquement, et après avoir ajouté à votre code le using du namespace "System.Windows.Browser", il suffit pour créer (ou modifier) un cookie d'appeler la méthode SetProperty de HtmlPage.Document :

   1:  private bool setCookie(string key, string value)
   2:          {
   3:              if (string.IsNullOrEmpty(key) || string.IsNullOrEmpty(value))
   4:              { return false; }
   5:              DateTime dt = calExpiry.SelectedDate ?? DateTime.Now 
   6:                  + new TimeSpan(1, 0, 0);
   7:              string s = key.Trim() + "=" + value.Trim() 
   8:                  + ";expires=" + dt.ToString("R");
   9:              HtmlPage.Document.SetProperty("cookie", s);
  10:              return true;
  11:          }

Pour la lecture on accède à la chaîne "Cookies" de HtmlPage.Document qu'on peut ensuite traiter pour séparer chaque cookie :

   1:  private string getCookie(string key)
   2:          {
   3:              string[] cookies = HtmlPage.Document.Cookies.Split(';');
   4:              foreach (string cookie in cookies)
   5:              {
   6:                  string[] pair = cookie.Split('=');
   7:                  if (pair.Length == 2)
   8:                  {
   9:                      if (pair[0].ToString() == key)
  10:                          return pair[1];
  11:                  }
  12:              }
  13:              return null;
  14:          }

Bref, rien de bien compliqué mais qui pourra vous servir dans certains cas.

Le code source du projet (Blend 3 de préférence, sinon VS 2008 + SL3) : Cookies.zip (62,65 kb)

Stay Tuned !

 

Silverlight 3 : Styles Cascadés (BasedOn Styles)

Toujours dans ma petite série sur les nouveautés de Silverlight 3 je vais vous présenter aujourd'hui une feature plaisante : les styles cascadés.

En soi rien de nouveau à l'ouest puisque c'est le principe même des feuilles de styles CSS (qui y puisent d'ailleurs leur nom). Mais le CSS s'applique à quelques éléments simples HTML alors que là nous parlons de styles Silverlight, c'est à dire d'objet complexes pouvant définir tout un visuel, animations comprises.

[silverlight:source=/SLSamples/BasedOnStyle/BasedOnStyle.xap;width=405;height=150]

Dans l'application Sivlerlight 3 ci-dessus (fonctionnelle, ce n'est pas une capture écran), vous voyez 4 boutons. Tous sont des boutons standard du framework.

  • Le premier, intitulé "Base SL" possède le style Silverlight par défaut
  • Le second, "Normal" est décoré par le style "BoutonNormal"
  • Le troisième "Gros" est décoré par le style "BoutonGros"
  • Et le quatrième "Alarme" est décoré par le style "BoutonGrosAlarme"

Visuellement c'est plutôt moche, je vous l'accorde, mais le but du jeu est de voir l'effet du cascading styling...

Le style "BoutonNormal" est défini comme suit :

<Style x:Key="BoutonNormal" TargetType="Button">
     <Setter Property="Width" Value="90" />
     <Setter Property="Height" Value="30" />
     <Setter Property="HorizontalAlignment" Value="Left" />
     <Setter Property="VerticalAlignment" Value="Bottom" />
     <Setter Property="BorderThickness" Value="2"/>
</Style>

Là où les choses deviennent plus intéressantes, c'est dans le style "BoutonGros" ci-dessous où l'on voit apparaître l'attribut BasedOn qui permet de fonder le style courant sur celui qu'on indique :

<Style x:Key="BoutonGros" 
         BasedOn="{StaticResource BoutonNormal}"
         TargetType="Button">
  <Setter Property="Width" Value="180" />
  <Setter Property="Height" Value="60" />
  <Setter Property="FontFamily" Value="Comic Sans MS"/>
</Style>

Enfin, le dernier style se fonde lui-même sur le précédent par le même mécanisme, le niveau de cascading n'étant pas limité. On peut voir notamment que le changement de famille de fonte introduit dans le style "BoutonGros" s'est propagé au style "BoutonGrosAlarme" (fonte Comic).

<Style x:Key="BoutonGrosAlarme" 
         BasedOn="{StaticResource BoutonGros}"
         TargetType="Button">
  <Setter Property="Width" Value="160" />
  <Setter Property="Height" Value="40" />
  <Setter Property="FontSize" Value="18"/>
  <Setter Property="FontWeight" Value="Bold"/>
  <Setter Property="Foreground" Value="Red"/>
  <Setter Property="BorderThickness" Value="4"/>
  <Setter Property="BorderBrush" Value="#FFFF0202"/>
</Style>

Voilà, c'est tout simple, mais cela peut radicalement simplifier la création de gros templates pour des applications. Tous les avantages du Cascading Style Sheet de HTML dont l'intérêt ne se démontre plus, mais appliqué à des objets et à la sophistication de Silverlight. Que du bonheur...

Bon Styling,

...Et Stay Tuned !

Silverlight 3 : L'Element Binding

L’Element Binding est une nouvelle feature de Silverlight 3 déjà présente sous WPF.

L’Element Binding définit la capacité de lier les propriétés des objets entre eux sans passer par du code intermédiaire. Cette possibilité existait déjà sous WPF, on la retrouve désormais sous SL3.

Pour simplifier prenons l’exemple d’un panneau d’information, par exemple un Border avec un texte à l’intérieur. Imaginons que l’utilisateur puisse régler l’opacité de cette fenêtre par le biais d’un Slider. (ci-dessous l'application exemple pour jouer en live).

[silverlight:source=/SLSamples/EBinding/EBinding.xap;width=452;height=240]

On place quelques éléments visuels sous le Border (ici des rectangles) afin de mieux voir l’effet du changement d’opacité.

Trois méthodes s'offre à nous pour régler le lien entre le Slider et l'opacité du Border. J'appellerai la première "méthode à l'ancienne", la seconde "méthode du certifié" et la troisième "méthode Silverlight 3". Les trois ont leur intérêt mais si vous êtes très pressé vous pouvez directement vous jeter sur la 3eme solution :-)

Méthode 1 dite « à l’ancienne »

Le développeur Win32 habitué aux MFC ou à des environnements comme Delphi aura comme réflexe immédiat d’aller chercher l’événement ValueChanged du Slider et de taper un code behind de ce type :

MonBorder.Opacity = MonSlider.Value ;

Ça a l’avantage d’être simple, efficace, de répondre (apparemment) au besoin et de recycler les vielles méthodes de travail sans avoir à se poser de questions…

Méthode 2 dite « du certifié »

Ici nous avons affaire à un spécialiste. Son truc c’est la techno, suivre les guide-lines et écrire un code qui suit tous les dogmes de l’instant est un plaisir intellectuel. Parfois ses solutions sont un peu complexes mais elles sont belles et à la pointe de la techno !

Conscient que la solution « à l’ancienne » a un petit problème (en dehors d’être trop simple pour être « belle », elle est one way, le slider modifie l'opacité du border mais l'inverse ne fonctionne pas) il va chercher une solution objet élégante répondant à l’ensemble des cas possibles couvrant ainsi le two way, considération technique trop technophile pour le développeur du cas précédent.

Ici forcément ça se complique. C’est techniquement et intellectuellement plus sexy que la méthode « à l’ancienne » mais cela réclame un effort de compréhension et de codage :

Il faut en fait créer un objet intermédiaire. Cet objet représente la valeur du Slider auquel il est lié lors de son instanciation. Quant à l’objet Border, sa propriété Opacity sera liée par Data Binding standard à l’objet valeur.

Voici le code de la classe de liaison :

public class ValueBinder : INotifyPropertyChanged
       {
             public event PropertyChangedEventHandler PropertyChanged;
             private Slider boundSlider;
             public ValueBinder(Slider origine)
             {
                    boundSlider = origine;
             }
 
             public double Value
             {
                    get { return boundSlider==null?0:boundSlider.Value; }
                    set {
                           if (PropertyChanged!=null)
                                  PropertyChanged(this,
                                    new PropertyChangedEventArgs("Value"));
                           boundSlider.Value = value;
                    }
             }
       }

Cette classe, ou plutôt l’une de ses instances, servira a représenter la valeur courante du Slider. Ce dernier est lié à l’instance lors de la création de cette dernière (voir le constructeur de la classe ValueBinder ci-dessus).

Comment utiliser cette classe ?

La première chose est qu’il faut en créer une instance, cela peut se faire dans le code XAML ou bien dans le code behind de la façon suivante (dans le constructeur de la page par exemple) :

var valueBinder = new ValueBinder(slider);

Maintenant il suffit dans le code XAML de lier les deux objets à la valeur de la classe intermédiaire, par Data Binding :

Côté Slider, le code est :

<Slider x:Name="slider"Value="{Binding Value, Mode=TwoWay}"/> 

Côté Border :

<Border x:Name="borderInfo"Opacity="{Binding Value, Mode=TwoWay}"> 

Ne reste plus qu’à rendre visible l’objet intermédiaire par exemple en en faisant la valeur courante du DataContext de l’objet LayoutRoot :

LayoutRoot.DataContext = valueBinder;

Et voilà ! Ne reste plus qu’à compiler et vous le plaisir de voir que l’opacité du Border change bien lorsque le Slider est déplacé.

La chaîne est la suivante : la modification de la position du Thumb entraîne dans le composant Slider la modification de la valeur de la propriété Value. Comme celle-ci est liée par Data Binding TwoWay à la propriété Value de l’objet intermédiaire cette propriété va se trouver modifiée dans le même temps. Comme le Setter de la propriété notifie le changement de valeur de la propriété (la classe implémente INotifyPropertyChanged) et comme la propriété Opacity du Border est elle aussi liée par Data Binding à la propriété Value de l’objet intermédiaire, le Border sera « prévenu » du changement de valeur et sa propriété Opacité sera immédiatement modifiée pour recevoir la valeur courante de Value de l’objet intermédiaire ! C’est pas fun tout ça ? (hmmm j’en vois un qui suit pas là bas au fond… !).

Vous allez me dire, TwoWay, on veut bien te croire mais on ne le voit pas là … Pour l’instant cela se comporte exactement comme la première solution, juste qu’il faut avoir un niveau de certifié pour comprendre…

C’est pas faux. C’est pourquoi je vais maintenant ajouter un petit bout de code pour faire varier la valeur de la propriété Opacity du Border. Le plus simple est de gérer la roulette de la souris dans le Border :

<Border x:Name="borderInfo"MouseWheel="Border_MouseWheel"> 

Et dans le code behind :

private void Border_MouseWheel(object sender, System.Windows.Input.MouseWheelEventArgs e) 
             { 
                    borderInfo.Opacity += e.Delta/1000d; 
                    e.Handled = true;
             }

Il suffit maintenant de faire rouler la molette au dessus du Border pour en changer l’opacité. Le TwoWay ? Regardez bien : le curseur du Slider avance ou recule tout seul… Pour éviter que la page HTML contenant le plugin Silverlight ne se mette à scroller il faut bien entendu indiquer que l'événement est géré (Handled=true) ce qui est fait dans le code ci-dessus.

Cette solution est élégante, complète mais complexe. Elle reste l’approche à préconiser dans tous les cas du même type car, on le voit bien, si la première solution est simple, elle n’est pas complète. Complexifier par plaisir est un mauvais réflexe, mais ne pas voir qu’une solution est trop simpliste est aussi un défaut qu’il faut fuir !

Bref, sous Silverlight 2 la solution présentée ici est une bonne solution. Sous Silverlight 3 qui supporte le Binding direct entre éléments (comme WPF) nous allons pouvoir faire plaisir à la fois au développeur du premier cas et à celui du second :

Méthode 3 dite « Silverlight 3 »

Comment marier le reflexe (plutôt sain) du premier développeur de notre parabole de vouloir faire vite et simple avec l’exigence intellectuelle (tout aussi saine) du second qui implique de faire « complet » ?

Pour illustrer l’Element Binding de façon simple, prenons un Scrollbar en mode horizontal et un Slider en mode vertical.

Et regardons le code XAML de leur déclaration :

<ScrollBar x:Name="scrollA"Value="{Binding Value, ElementName=sliderB, Mode=TwoWay}"/> 
 
<Slider x:Name="sliderB"Value="{Binding Value, ElementName=scrollA, Mode=TwoWay}" /> 

Et c’est tout ce qu’il y a à faire pour obtenir une solution complète, élégante, sans code behind et très facile à mettre en œuvre ! Merci Silverlight 3 !

En début de billet vous pouvez jouer avec les deux dernières implémentations (je n’ai pas implémenté la méthode 1) .

Vous pouvez aussi télécharger le code du projet (Blend 3 ou VS2008 avec les extensions SL3) : elementBinding.zip (61,43 kb)

Pour d'autres nouvelles, Stay Tuned !

Silverlight 3 : Nouveau contrôle DataForm et Validation des données

Je continue ma petite série sur les nouveautés de Silverlight 3. Au menu un composant des plus intéressant et un nouveau système de validation.

Le composant s'appelle DataForm, il est en quelque sorte le pendant mono enregistrement du composant DataGrid. Avec cette dernière on montre plusieurs enregistrements à la fois, avec la DataForm on présente les données d'une seule fiche. On conserve malgré tout la possibilité de navigueur de fiche en fiche, et le composant est hautement personnalisable grâce aux styles et templates.

Imaginons une petite fiche permettant de créer un login : pseudo, e-mail et mot de passe sont le lot de ce genre de cadres de saisie. Pour les besoins de la démo commençons par créer une classe représentant l'ensemble des informations à saisir (voir le code en fin de billet).

Rien d'exceptionnel ici donc, juste une petite classe. Mais vous remarquerez plusieurs choses :

  • Les propriétés sont décorées d'attributs qui permettent de modifier notamment l'affichage des labels dans la DataForm, un nom interne de propriété n'est pas forcément adapté pour une lecture par l'utilisateur final.
  • Les propriétés sont décorées de l'attribut Required. Autre particularité pour la DataForm : certains champs peuvent être obligatoires.      

Dans le code ci-dessous chaque propriété prend en charge sa validation : elle lève une exception dès que la valeur passée n'est pas conforme à celle attendue. Il existe d'ailleurs un doublon fonctionnel dans ce code : la présence de la méthode CheckNull qui s'assure qu'une propriété n'est pas vide, et l'attribut Required. En l'état c'est la méthode CheckNull qui prend le dessus, on pourrait donc supprimer l'attribut.


Il existe bien d'autres attributs pour la DataForm et le propos de ce billet n'est pas de tous les détailler, mais il est important de noter comment le code peut prévoir certains comportements qui seront reportés sur l'interface utilisateur sans réellement interférer avec elle... subtile.

Regardons maintenant le code XAML de la page affichée par Silverlight (en fin de billet). 

Tout d'abord vous remarquerez que l'instance de LoginInfo n'est pas créée dans le code C# mais sous forme de ressource dans la fiche, en XAML.
Ensuite nous définissions une balise DataForm dont l'item courrant est lié à l'instance de LoginInfo.

Et c'est tout. Pour la décoration j'ai ajouté un bouton "ok" qui accessoirement lance la valitation totale de la fiche. Ne saisissez rien et cliquez dessus : vous verrez apparaître le cadre des erreurs avec la liste de toutes les validations qui ont échouées. Bien entendu l'aspect de ce cadre est templatable aussi.

Le mieux est de jouer avec l'application de test ci-dessous:



Vous pouvez aussi télécharger le code du projet (à utiliser sous Blend 3 ou VS2008 avec les extensions SL3): SL3DataValidation.zip (60,40 kb)


[silverlight:source=/SLSamples/Validation/DataValidation.xap;width=400;height=320]

A noter : la présence du petit symbole info, il répond à l'attribut Description prévu dans le code de la classe et permet d'informer l'utilisateur.
Vous remarquerez aussi qu'en passant d'un champ à un autre les champs invalidés sont décorés par une lisière rouge dont un coin est plus marqué : cliquez sur ce dernier et vous obtiendrez le message d'erreur avec sa petite animation. L'aspect de ce cadre ainsi que l'animation sont bien entendu modifiables à souhait.

Stay Tuned pour d'autres nouveautés de SL3 !

 

Code de la classe LogInfo :

 

   1:  public class LoginInfo : INotifyPropertyChanged
   2:      {
   3:          private string loginName;
   4:          
   5:          [Required()]
   6:          [Display(Name="Login name:",Description="Votre login personnel.")]
   7:          public string LoginName
   8:          {
   9:              get { return loginName; }
  10:              set 
  11:              {
  12:                  checkNull(value);
  13:                  loginName = value.Trim();
  14:                  dochange("LoginName");
  15:              }
  16:          }
  17:          
  18:          
  19:          private string email;
  20:          
  21:          [Required()]
  22:          [Display(Name="e-mail:",Description="Adresse mail pour vous joindre.")]
  23:          public string Email
  24:          {
  25:              get { return email; }
  26:              set 
  27:              {
  28:                  checkNull(value);
  29:                  checkMail(value);
  30:                  email = value.Trim();
  31:                  dochange("Email");
  32:              }
  33:          }
  34:          
  35:          private string password;
  36:          
  37:          [Required()]
  38:          [Display(Name="Mot de passe:",Description="Votre mot de passe de connexion.")]
  39:          public string Password
  40:          {
  41:              get { return password; }
  42:              set 
  43:              {
  44:                  checkNull(value);
  45:                  password = value.Trim();
  46:                  dochange("Password");
  47:              }
  48:          }
  49:          
  50:          private string passwordCheck;
  51:          
  52:          [Required()]
  53:          [Display(Name="Contrôle:",Description="Retapez ici votre mot de passe.")]
  54:          public string PasswordCheck
  55:          {
  56:              get { return passwordCheck; }
  57:              set 
  58:              {
  59:                  checkNull(value);
  60:                  passwordCheck = value.Trim();
  61:                  if (string.Compare(password,passwordCheck)!=0)
  62:                      throw new Exception("Les mots de passe diffèrent !");
  63:                  dochange("PasswordCheck");
  64:              }
  65:          }
  66:          
  67:          private void checkMail(string value)
  68:          {
  69:              string pattern = @"^(([^<>()[\]\\.,;:\s@\""]+" 
  70:                          + @"(\.[^<>()[\]\\.,;:\s@\""]+)*)|(\"".+\""))@" 
  71:                          + @"((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 
  72:                          + @"\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+" 
  73:                          + @"[a-zA-Z]{2,}))$";
  74:                    Regex regMail = new Regex(pattern);
  75:                   if (!regMail.IsMatch(value)) throw new Exception("E-mail non valide !");
  76:          }
  77:          
  78:          private void checkNull(string value)
  79:          { 
  80:              if (string.IsNullOrEmpty(value)) throw new Exception("Ne peut être vide !");
  81:          }
  82:   
  83:          #region INotifyPropertyChanged Members
  84:   
  85:          public event PropertyChangedEventHandler PropertyChanged;
  86:          private void dochange(string property)
  87:          {
  88:              if (PropertyChanged!=null) PropertyChanged(this,new PropertyChangedEventArgs(property));
  89:          }
  90:   
  91:          #endregion
  92:      }

le code XAML de la fiche :

 

   1:  <UserControl
   2:      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:      xmlns:dataFormToolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data.DataForm.Toolkit"
   5:      xmlns:local="clr-namespace:DataValidation"
   6:      x:Class="DataValidation.MainPage"
   7:      Width="300" Height="320">
   8:   
   9:      <UserControl.Resources>
  10:       <local:LoginInfo x:Key="loginRec"  />
  11:      </UserControl.Resources>
  12:   
  13:      <StackPanel x:Name="LayoutRoot">
  14:          <dataFormToolkit:DataForm 
  15:              x:Name="PwForm" 
  16:              CurrentItem="{StaticResource loginRec}" 
  17:              Foreground="Black" 
  18:              Height="292" 
  19:              VerticalAlignment="Top" 
  20:              TabNavigation="Cycle"/>
  21:          <Button 
  22:              Content="Ok" 
  23:              VerticalAlignment="Center" 
  24:              HorizontalAlignment="Center" 
  25:              Click="Button_Click"/>
  26:      </StackPanel>
  27:  </UserControl>

Silverlight 3 Releasé !

Ca y est, Silverlight 3 est releasé ! Avec Blend 3 RC (la finale dans 1 mois) et son nouveau système Sketchflow et des tonnes de nouveautés.

Silverlight 3 est une release d'importance qui pousse un cran plus loin encore le niveau des performances et de services rendus. On trouve parmi les nouveautés (sans ordre de préférence et avec des oublis) :

  • La vidéo HD avec accélérateur GPU d'une fluidité à couper le souffle ! Surtout cela permet de libérer le CPU et de tirer parti de la puissance de la carte graphique, donc d'avoir une qualité plus grande sur des PC moins puissants. Bien entendu, sur les plus puissants le gain est nettement visible aussi. De nouveaux Codec viennent s'ajouter avec le support H.264, l'audio AAC et le MPEG-4. Une API permet de créer de nouveaux Codec dans tout langage .NET ! Microsoft propose dans le même temps IIS Media Service, une application de streaming gratuite à installer sous IIS pour offrir un service de diffusion fluide et efficace.
  • L'accélération vidéo via le matériel (GPU) profite aussi et bien entendu à tous les logiciels développés en Silverlight pour une plus grande fluidité graphique. Ce qui permet au passage d'ajouter à Silverlight 3 le support des effets bitmap tant attendus comme le drop shadow ou le blur. Une interface ouverte permettant de créer soi-même de nouveaux effets.
  • De Nouveaux composants arrivent aussi. Avec Silverlight 3 et son SDK ce sont plus de 100 contrôles qui sont livrés pour concevoir des applications innovantes et fonctionnelles. L'accès aux données est largement amélioré avec la présence de la DataForm qui complète la DataGrid en fournissant une vision fiche de saisie plus orientée business.
  • Silverlight 3 améliore aussi la navigation en permettant l'exploitation des touches avance/recul du navigateur. La nouvelle fonction des bookmarks internes permet aussi de créer des liens mémorisables par les navigateurs qui peuvent alors plonger à l'intérieur d'une application Sliverlight.
  • Les styles deviennent héritables, on retrouve ainsi tout l'intérêt du cascading de CSS appliqué non pas à quelques styles HTML mais à des graphiques, des templates et des animations !
  • Les applications Silverlight peuvent désormais vivre en dehors du navigateur et être installées "sans installation" dans les menus de Windows. Les applications sont exécutables directement sans même plus avoir conscience qu'il s'agit, au départ, d'une application internet. Le tout en un clic...
  • En matière de communication la partie WCF est aussi améliorée avec une meilleure propagation des erreurs, la possibilité d'utiliser du XML binaire, c'est à dire compressé pour diminuer la taille des paquets échangés entre l'application et le serveur WCF.
  • Les Services .NET RIA permettent d'écrire du code de validation plus efficacement agissant à la fois sur la couche de présentation et celle du code métier, le tout sans avoir besoin de réécrire les mêmes régles dans plusieurs codes différents.
  • Visual Studio 2010 supportera bien entendu toutes les nouveautés mais il est déjà possible de bénéficier de tous les avantages cités depuis VS 2008.
  • Blend 3, évoqué en introduction est fourni en RC avant sa sortie officielle dans 1 mois. On y trouve de très nombreuses améliorations sur lesquelles je reviendrai prochainement dont le Sketchflow qui méritera à lui seul tout un article tellement le concept est génial pour faciliter le maquettage tant sous Silverlight que WPF.
  • Blend 3 introduit aussi des notions nouvelles comme les comportements (behaviors), sortes d'automates logiciels qu'on peut poser par drag-and-drop sur tout contrôle ou graphique pour lui permettre d'agir sans aucune programmation en code behind. Par exemple il existe un comportement de changement de propriété : déposez-le sur un cercle, et vous pourrez régler quel événement sera la source (le mouse enter par exemple), et quel autre objet sera la cible (couple objet / propriété). Fixer la nouvelle valeur (par exemple changer la couleur d'un autre contrôle). Le tout peut se faire immédiatement ou avec une timelime automatique pour un effet visuel plus "smooth" (on entre la durée voulue) !
  • Silverlight 3 supporte la 3D perspective, c'est à dire qu'on n'est pas encore arrivé au niveau de WPF qui sait manipuler des scènes 3D (objets 3D, lumières, caméras...) mais qu'il est possible de donner un effet de perspective à tout objet en application des rotations sur les 3 axes de l'espace. Cela ouvre de nouvelles ... perspectives pour créer par exemple des effets de transition novateurs sans une ligne de code.
  • Que dire aussi des Ease-in/out complexes qui permettent facilement de changer une animation un peu trop rigide en quelque chose de plus "organique", comme l'impression de rebond ou celle du comportement d'un elastique...
  • Blend 3 supporte aussi Intellisense dans le code XAML ce qui manquait cruellement.
  • Il permet aussi d'importer des graphiques PhotoShop ou Illustrator en conservant les layers, avec sélection des parties à importer.
  • Le templating inversé est aussi une nouveauté fantastique : vous partez d'un dessin fait par le graphiste et vous expliquez à Blend qu'il va devenir un bouton, un slider.. et Blend vous guide pour indiquer quel bout du dessin joue le rôle de piste, de curseur, etc. Réellement bluffant !
  • Les données manquent souvent lors de la conception d'un écran, et il est parfois difficile de templater une listbox ou une grille sans voir des exemples réalistes de contenu (un nom, une adresse mail, un numéro de téléphone etc). Blend 3 propose un mini générateur de données aléatoire typées (dans l'esprit de DataGen, le générateur de données que j'ai conçu, mais la fonction de Blend est de loin moins puissante). En tout cas cela permet d'immédiatement disposer de données assez réalistes pour mettre au point les écrans. On peut aussi charger des données de test depuis un fichier XML externe (généré par DataGen par exemple ? !).
  • Blend supporte l'intégration des projets au système de versionning. Cette évolution tombe sous le sens puisque Blend et VS sont conçus pour travailler de concert sur les mêmes projets et que dans ce cadre les deux produits doivent pouvoir gérer les changements dans un repository centralisé. Cette option s'entend pour le travail en équipe principalement.
  • Media Encoder 3 est lui aussi releasé dans la même vague, avec Design 3. Encoder permet de supporter les nouveaux modes videos de streaming HD de Silverlight 3.

Bref, je m'arrête là, c'est une moisson extraordinaire. Des outils de plus en plus puissants, de plus en plus agréables à utiliser, une gamme cohérente.

J'ai forcément oublié plein de choses, mais j'aurai forcément l'occasion de revenir sur toutes ces nouveautés dans des papiers à venir.

Entre temps, vous pouvez télécharger tout le nécessaire en vous rendant sur http://www.silverlight.net/ (téléchargements, tutors...), http://expression.microsoft.com/en-us/default.aspx (le site de la communauté Expression), ou encore http://www.microsoft.com/silverlight (le site de base de Silverligth avec des démos des nouveautés de la V3)

Amusez-vous bien !

Et Stay tuned, car des nouveaux papiers, il va forcément y en avoir d'ici quelques temps !

 

 

Xaml, l'ami des artistes

XAML, comme le savez, est au coeur de WPF et de Silverlight. Sa puissance, doublée par celle du Framework et de langages comme C#, en fait une machine de guerre sans équivalent pour qui veut développer des applications modernes, c'est à dire efficaces techniquement mais "lookées". 

Mais si XAML est l'ami des développeurs, il est aussi celui des artistes !
Il créé un lien entre deux mondes parallèles : celui des métiers IT et celui des métiers de l'art, graphisme, vidéo, son et musique.

Démontrer une nouvelle technologie est généralement assez facile, il suffit de se former et d'écrire un article et des exemples. Mais comment "démontrer" et rendre tangible ce lien immatériel entre informatique et art créé par XAML ?

Car une application aujourd'hui, en plus du fonctionnel, c'est aussi de l'image et du son. De l'interface, mais aussi de la "promo" visuelle, des vidéos, de la musique, des logos.

Evoquer ce lien entre art et technique, c'est la finalité de E-Naxos Art, une démo Silverlight 2 qui permettra peut-être de réveiller l'artiste qui sommeille en vous et vous inciter à vous lancer dans WPF et Silverlight si vous hésitez encore !

Pour l'instant l'application est en bêta et elle n'est pas encore très fournie. Il y a tout de même à voir des vidéos en 3D, des dessins et des bouts de sons ou de musiques. Tout cela sera complété au fil du temps.

Alors pour mieux comprendre le mariage entre "art" et technologie que matérialise XAML, bonne visite sur E-Naxos Art !

Et Stay tuned !