Dot.Blog

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

Les posters de VS2008 (affectation de touche, référence .NET)

Voic quelques posters à imprimer qui peuvent s'avérer très utiles au bureau ou même pour être geek jusqu'au bout pour décorer sa salle de bain, voire d'autres lieux de méditation intense que la bienséance m'interdit de préciser plus avant mais qui s'avèrent être des sanctuaires de tranquilité propice à la lecture des docs techniques qu'on néglige trop souvent de consulter...

Donner du peps à Linq ! (Linq dynamique et parser d'expressions)

J'ai eu moulte fois ici l'occasion de dire tout le bien que  je pense de LINQ, de sa puissance, de sa souplesse, de sa versatilité (de xml à SQL en passant par les objets et l'Entity Framework).

Mais une petite chose me chagrinait : toute cette belle puissance s'entendait "hard coded". Je veux dire par là que les expressions et requêtes LINQ s'écrivent en C# dans le code et qu'il semblait très difficile de rendre la chose très dynamique, sous entendu dépendant d'expressions tapées à l'exécution de l'application. En un mot, faire du LINQ dynamique comme on fait du SQL dynamique.

Ce besoin est bien réel et ne concerne pas que les sources SQL. Prenez une simple liste d'objets que l'utilisateur peut vouloir trier selon l'une des propriétés ou filtrer selon le contenu des objets... Comment implémenter une telle feature ?

Contourner ce manque en écrivant des parsers, en jonglant avec les expressions lamba et la réflexion n'est pas, il faut l'avouer, ce qu'il y a de plus simple. Mais rassurez-vous chez Microsoft des gens y ont pensé pour nous ! Seulement voila, la chose est assez confidentielle il faut bien le dire, et on ne tombe pas dessus par hasard. Ou alors c'était un jour à jouer au Lotto, voire à contrôler, selon les mauvaises langues, l'emploi du temps de sa femme !

La chose s'appelle "LINQ Dynamic Query Library", un grand nom pour une petite chose puisqu'il s'agit en réalité d'un simple fichier source C# à ajouter à ses applications.  Mais quel fichier source !

Toute la difficulté consiste donc à savoir que ce fichier existe et mieux, où il se cache... C'est là que c'est un peu vicieux, la chose se cache dans un sous-répertoire d'un zip d'exemples Linq/C#, fichier lui-même astucieusement planqué dans la jungle des milliers de téléchargement de MSDN...

Sans plus attendre allez chercher le fichier cliquant ici.

Une fois que vous aurez accepté les termes de la licence ("I Accept" tout en bas à gauche) vous recevrez le fichier "CSharpSamples.zip". Dans ce dernier (dont tout le contenu est vraiment intéressant) aller dans le répertoire "LinqSamples" puis dans le projet "DynamicQuery" vous descendrez dans une autre sous-répertoire appelé lui aussi "DynamicQuery" (non, ce n'est pas un jeu de rôle, juste un téléchargement MSDN!). Et là, le Graal s'y trouve, "Dynamic.cs".

Copiez-le dans vos projets, et ajouter un "using System.Linq.Dynamic". A partir de là vous pourrez utiliser la nouvelle syntaxe permettant de faire du LINQ dynamique. A noter que dans le répertoire de la solution vous trouverez aussi un fichier "Dynamic Expressions.html" qui explique la syntaxe du parser.

Quelles sont les possibilités de LINQ Dynamic Query Library ?

C'est assez simple, pour vous expliquer en deux images je reprend deux captures écrans tirées du blog de Scott Guthrie (un excellent blog à visiter si vous parlez l'anglais).

Voici un exemple de requête LINQ (en VB.NET, si j'avais refait la capture cela aurait été du C#, mais je ne vais pas rouspéter hein ! )

Maintenant voici la même requête utilisant du LINQ dynamique :

Vous voyez l'astuce ? Le filtrage et le tri sont maintenant passés en chaîne de caractères... Bien entendu cette chaîne peut avoir été construite dynamiquement par code (c'est tout l'intérêt) ou bien saisie depuis un TextBox rempli par l'utilisateur.

Ici pas de risque d'attaque par "SQL injection", d'abord parce que LINQ n'est pas limité à SQL et que le problème ne se pose que dans ce cas, mais surtout parce que LINQ to SQL utilise des classes issues d'un modèle de données "type safe" et que par défaut LINQ to SQL est protégé contre les attaques de ce type. Pas de souci à se faire donc.

Pour terminer j'insisterai lourdement sur le fait que LINQ ne se limite pas aux données SQL, et que l'astuce de LINQ dynamique ici décrite s'applique même à LINQ to Object par exemple. Laisser la possibilité à un utilisateur de trier une List<> ou une Collection<>, de la filtrer, tout cela en mémoire et sans qu'il y ait la moindre base de données est bien entendu possible.

LINQ est vraiment une innovation majeure en matière de programmation, pouvoir le dynamiser simplement c'est atteindre le nirvana...

Je vous laisse vous jeter sur vos claviers pour expérimenter du LINQ dynamique, amusez-vous bien !

..et surtout.. Stay tuned !

 

Des skins pour Visual Studio 2008 !

VS 2008 ne se contente pas d'être à mon sens le meilleur EDI jamais créé (et le plus stable aussi comme son prédécesseur), il peut aussi être beau !

Certes VS2008 ou 2005 ne sont pas laids, ce sont des EDI sobres, professionnels et fonctionnels. Mais même si Apple n'est plus un fabriquant de machine adulé mais un vendeur de lecteurs mp3 et de téléphones, il faut bien concéder qu'ils ont modifié en profondeur une chose : le look & feel des machines comme des applications. L'esprit Apple c'est le beau. Et même si nos PC et nos logiciels Windows ont gagné la bataille du fonctionnel, ils sont loin d'avoir gagné la guerre du look !

Ce n'est pas pour rien que Microsoft s'oriente vers Vista et son moteur graphique, que la programmation .NET évolue vers WPF, la programmation web vers Silverlight : l'utilisateur est désormais habitué à la qualité fonctionnelle, il en veut plus, il veut du beau.. Et l'informaticien n'est pas en reste. Il veut que son IDE soit aussi le plus esthétique possible.

Le look de votre VS 2008 vous lasse ? .. Et bien changez de peau !

Il est en effet possible, dans certaines limites, de modifier l'aspect de VS 2008 grâce à une logique classique de "thèmes". Ne rêvez pas, Visual Studio ne se transformera pas en jeu video 3D pour autant ! Mais vous pourrez au moins le relooker un peu. Pour ne pas vous laissez vous emballer pour rien, précisons même que les fameux thèmes jouent principalement sur les couleurs des éditeurs, pas sur l'aspect des fenêtres, leur forme, leur opacité ou toutes ces choses que sous-entend habituellement le mot "thème". Mais bon, vous allez voir, c'est toujours mieux que rien !

D'autant que nul besoin de tripatouiller les réglages de VS puisqu'il existe en téléchargement gratuit des thèmes assez chouettes que vous pouvez installer directement.

Une fois un thème installé dans le répertoire ...\Mes Documents\Visual Studio 2008\Settings vous pouvez l'importer de la façon suivante (j'utilise l'IDE en anglais à vous de traduire donc) :

  • Etape 0 : faites un export/sauvegarde de vos réglages actuels avant de commencer, on ne sait jamais!
  • Tools | Import and Export Settings
  • Import Selected environment settings
  • "No", just import new settings
  • Cliquez sur "Next" et "Import All Settings"

Les fichiers de thèmes ne contiennent que des informations portant sur les fontes et les couleurs, aucun autre paramètres ne sera donc effacé par cette manoeuvre. D'ailleurs un écran précédent l'import vous permettra de choisir dans l'arbre des paramètres ceux à prendre en compte.

où trouver des thèmes ?

Dans le cas où vous souhaiteriez retrouver le look d'origine :

 En cherchant sur le Web vous trouverez certainement d'autres thèmes.

Amusez-vous bien et.. Stay tuned !

Le blues du générateur d'état (sous titré: Et si RDL était la solution ?)

Il n'y a pas que le "Set of" de Delphi qui peut donner le blues (voir ce billet pour comprendre), non, il y a pire, sous tous les langages, depuis toujours, sous tous les OS, l'informaticien a toujours eu le blues des générateurs d'état, et le blues, c'est peu dire...

[EDIT: Voir ce billet plus récent qui propose un tutor complet] 

Les delphistes ont pesté contre QuickReport et ses bugs après avoir ronchonné sur ReportSmith (qui s'en souvient?), Borland l'a remplacé un jour par RaveReport, encore pire, Microsoft intègre de longue date Crystal Report qui n'a jamais eu les faveurs des développeurs (comment peut-il encore exister d'ailleurs si personne ne l'aime ? un mystère), sans trop rien dire tout en le disant sans le dire, Microsoft propose un service de génération d'état dans Sql Server. Quelle drôle d'idée que de le lier au serveur (même s'il y a une logique compréhensible) plutôt que d'en faire un produit à part réellement intégré à VS. Mais peu de gens s'en servent et MS ne semblent pas non plus le promouvoir avec force et vigueur...

Je suis convaincu que les Java-istes, les C-istes, et même les cobolistes (heeuu non, eux ils faisaient les états à la main avec des petites étoiles pour dessiner les cadres), enfin à part les cobolistes donc, je suis convaincu que tous les développeurs du monde ont toujours été déçus par les générateurs d'état.

La faute à qui ? A la nature même des états... Un état cela peut être tout et n'importe quoi. D'un simple "listing" à l'ancienne, jusqu'à la mise en page d'une ordonnance ou d'un rapport d'activité annuel, d'une facture à une liasse fiscale, d'un chèque à un mailing publicitaire... Une vraie liste à la Prévert ! Et chacun de ces documents a ses propres exigences, ses priorités, ses "non négociables". Un mailing avec enveloppe à fenêtre ou une liaisse fiscale pré-imprimée devront se reposer sur un outil très précis au niveau du placements des zones, pour un listing c'est la facilité et la rapidité de mise en page en colonnes, les sous-totaux, les regroupements, les ruptures qui seront essentiels..

Bref, le générateur d'état idéal et parfait n'existe pas. Il en existe de très mauvais (non, je te citerai pas de noms !), d'autres meilleurs, mais aucun n'est adapté à tous les besoins.

RDL vous connaissez ?

Report Definition Language. Une norme de description d'état dérivée de XML, voilà ce qu'est RDL. C'est sur ce langage d'ailleurs que repose le service générateur d'état de SQL Server 2005 et 2008, mais RDL existe en dehors de cette base de données. Et c'est tout là son intérêt !

La description de la norme de novembre 2005 se trouve ici, une lecture édifiante, mais peu passionnante il faut l'avouer.

Le site suivant (ici) regroupe des informations complémentaires sur RDL ainsi que le composant ReportViewer de Microsoft qui s'intègre à Visual Studio (une version VS 2005 et une pour VS 2008 existent).

On trouve même ici un moteur RDL autonome ainsi qu'un designer visuel évitant de trop mettre les mains dans XML. Gratuit et avec les sources, accompagné d'un serveur d'états, il s'agit là d'une base intéressante.

RDL et ses trops rares outils restent encore trop confidentiels, la puissance descriptive du langage est pourtant plus qu'intéressante, la possibilité de requêter des sources SQL mais aussi des services Web, des flux RSS, etc, n'est qu'une des facettes de cette puissante alternative aux générateurs d'état classiques.

RDL est-t-il le générateur d'état idéal ?
Difficile à dire car c'est avant tout un langage, mais justement, là est sa force : les états deviennent descriptifs, "générables" par programmation (fabriquer un fichier XML à coup de WriteLine dans un fichier texte est d'une simplicité enfantine), partageables (RDL est un format ouvert et publié), et les moteurs traitant RDL savent exporter les états en PDF, HTML, CSV, MHT, Texte, RTF, etc..

Il n'y a pas à l'heure actuelle (à ma connaissance) de superbes designers hyper sexy pour RDL (mais VS 2008 intègre un designer visuel, le saviez-vous ?!), l'information est difficile à trouver, c'est le côté "underground" de RDL.. Mais si comme tous les informaticiens de la planète (et peut-être même de quelques exoplanètes!) vous avez le blues du générateur d'état, alors jetez un oeil à RDL, il y a des chances que cela vous séduise. Dans tous les cas vous aurez au moins gagné un sujet de conversation hyper branché pour la machine à café !

Merci qui ? ... Laughing

Alors stay tuned !

Les bonnes adresses Microsoft : Tout sur Visual Studio 2008

Le monde Microsoft est tellement vaste que retrouver certains téléchargements peut s'avérer difficile. Pour vous simplifier la vie voici une liste de bonnes adresses !

Visual Studio 2008

  • Version Express gratuite ( ici )
  • Version payante [ abonndés MSDN seulement ] ( ici )
  • Version d'essaiici )

Visual Studio 2008 SDK 

Kit de développement officiel.
Download Visual Studio 2008 SDK ( Version 1.0  beta 1.1)

Visual Studio 2008 - Exemples

"ASP.NET

  • Exemples et starter kits ici.
Visual Basic Visual C#

Outils VS pour Microsoft Office system 3.0

  • Download Microsoft Visual Studio Tools for the Microsoft Office system ( x86 )

Microsoft Report Viewer Redistributable 2008

  • Microsoft Report Viewer Redistributable 2008 ( ici

Visual Studio 2008 Training Kit

  • Visual Studio 2008 Training Kit ( ici   

Visual Studio 2008 Shell (isolated mode) Redistributable Package

  • Download Visual Studio 2008 Shell (isolated mode) Redistributable Package ( ici )

Visual Studio 2008 Shell (integrated mode) Redistributable Package

  • Download Visual Studio 2008 Shell (integrated mode) Redistributable Package ( ici ) 

 

 

fichiers CHM bloqués ou non lisibles.. la solution au mystère

Certes le format CHM n'est plus "officiellement" le format d'aide préconisé, mais il faut bien convenir qu'on trouve encore beaucoup de ces fichiers : du simple fichier d'aide à des livres entiers, ce format Html compressé et agrémenté d'index et de recherche est compact, pratique et donc encore très utilisé. D'où certainement l'intérêt pour beaucoup d'entre vous de cette petite astuce...

Ne vous est-il jamais arrivé qu'en ouvrant un fichier CHM vous puissiez voir généralement l'index mais que l'affichage de toute page se solde par une page d'erreur du type "page indisponible, impossible d'atteindre la page..." ?

Bien souvent ces fichiers viennent d'Internet suite à un téléchargement parfois depuis des sources nous allons dire peu orthodoxes... De fait se croyant puni par le sort pour son forfait l'infortuné informaticien fouineur finit par jeter le fichier à la corbeille pensant qu'il est "vérolé" et n'osant pas trop faire de réclamation en raison de la provenance du fichier... Mais ne vous moquez pas ! Cette situation arrive aussi avec des fichiers CHM aux sources nobles et parfaitement légitimes, il suffit pour cela que Windows (et le service Pack 2 de XP) ait compris qu'il provienne d'Internet pour que le contenu se retrouve ainsi bloqué !

L'intention de Microsoft est louable dans un tel renforcement de sécurité, mais hélas le message d'erreur affiché est tellement éloigné de la raison réelle que le fichier termine à la poubelle sans qu'on ait pu comprendre qu'il y avait bien plus simple, et surtout que le contenu du fichier était parfaitement accessible ! Dommage non ? .. Quand on pense à tous ces CHM pleins de bonnes informations qui ont été mis injustement à la corbeille... Je propose d'ailleurs une minute de silence..  ... ... Merci.

Donc, le SP2 de XP bloque les fichiers CHM qui proviennent d'Internet, même stockés sur votre disque dur (et non pas depuis un téléchargement en live. Nous parlons bien d'un fichier présent physiquement sur vos disques).

Pour débloquer la situation naviguez dans le répertoire du fichier CHM en question, clic droit, Propriétés, puis choisir... et oui... "Débloquer" ! C'est bête non ?

Je vous laisse pleurer sur les CHM parfaitement valides que vous avez téléchargés ici et là et qui sont depuis longtemps digérés par la corbeille de votre XP, soyez positifs, maintenant cela n'arrivera plus...

 Stay tuned !

Le blues du "Set Of" de Delphi en C#

Il y a bien fort peu de chose qui puisse faire regretter un delphiste d'être passé à C#, et quand je parle de regrets, c'est un mot bien fort, disons plus modestement des manques agaçants. 

Rien qui puisse faire réellement pencher la balance au point de revenir à Delphi, non, ce langage est bel et bien mort, assassiné par Borland/Inprise/Borland/CodeGear et son dernier big boss, tod nielsen qui ne mérite pas même les majuscules à son nom mais là n'est pas la question.

Donc il existe syntaxiquement trois choses qui peuvent agacer le delphiste, même, comme moi, quand cela fait au moins cinq ans maintenant que je ne pratique presque plus que C# (et un peu de Delphi pour maintenir des vieilleries et aider certains clients à tourner la page en migrant sous C#).

La première qui revient à longueur de code, ce sont ces satanés parenthèses dans les "if". On n'arrête pas de revenir en arrière parce qu'on rajoute un test dans le "if" et qu'il faut remettre tout ça entre de nouvelles parenthèses qui repartent depuis le début. Certes on gagne l'économie du "then" pascalien, mais que ces parenthèses du "if" sont épouvantables et ralentissent la frappe bien plus qu'un "then" unique et ponctuel qu'on ne touche plus une fois écrit même si on rajoute "and machin=truc" ! A cela pas d'astuce ni truc. Et aucun espoir que les parenthèses de C# dans les "if" soient abandonnées un jour pour revenir au "then" ... Donc faut faire avec ! Le dogme "java/C++" est bien trop fort (quoi que C# possède le Goto de Delphi, ce qui n'est pas la meilleure idée du langage :-) ).

La seconde tracacerie syntaxique est cette limitation totalement déroutante des indexeurs : un seul par classe et il ne porte pas de nom. this[], un point c'est tout. Je sais pas ce que notre bon Hejlsberg avait en tête, mais pourquoi diable n'a-t-il repris de Delphi qu'un seul indexeur et non pas la feature entière ? Il fait beaucoup de recherche, et le fait bien, mais je présume qu'il n'a jamais plus codé un "vraie" appli depuis des lustres... Car dans la vraie vie, il existe plein de situations où un objet est composé de plus d'une collections. Une voiture a 4 roues et 2 ou 4 portières. Pourquoi lorsque je modélise la classe Voiture je devrais donner plus d'importance aux roues qu'aux portières et choisir lesquelles auront le droit d'être l'unique indexeur de la classe ? Pourquoi tout simplement ne pas avoir Voiture.Roues[xx] et Voiture.Portières[yy] ? Mon incompréhension de ce choix très gênant dans plus d'un cas a été et reste des années après totale. Surtout après toutes les évolutions de C# sans que jamais cette erreur de conception ne soit corrigée. Pas suffisant pour faire oublier toute la puissance de C# et le bonheur qu'on a à travailler dans ce langage, mais quand même, ça agace.

Enfin, dans la même veine d'ailleurs, l'absence de "Set of" est cruelle. Pourquoi avec zappé cette feature de Delphi dans C# alors que bien d'autres ont été reprises (avec raison ou moins comme le Goto) ?

Mais là on peut trouver des astuces et certains (dont je fais partie) ont écrit ou essayer d'écrire des classes "SetOf" qui permettent de gérer des ensembles comme Delphi, mais que c'est lourd tout ce code au lieu d'écrire "variable machin : set of typeTruc" !

Autre astuce moins connue, et c'est pour ça que je vous la livre, est l'utilisation fine des Enums. En effet, tout comme sous Delphi, il est possible d'affecter des valeurs entières à chaque entrée d'une énumération. On peut donc déclarer "enum toto { item1 = 5, item2 = 28, item3 = 77 }". 

Mais ce que l'on sait moins c'est que rien ne vous interdit d'utiliser des puissances de 2 explicitement car les Enums savent d'une part parser des chaînes séparées par des virgules et d'autre part savent reconnaître les valeurs entières cumulées.

Ainsi, avec enum Colors { rouge=1, vert=2, bleu=4, jaune=8 }; on peut déclarer :
Colors orange = (Colors)Enum.Parse(typeof(Colors),"rouge,jaune"); // étonnant non ?

La valeur de "orange" sera 9 qu'on pourra décomposer facilement, même par un simple Convert.ToInt64.

Pour ne pas réinventer la roue et éviter de faire des coquilles je reprends cet exemple tel que fourni dans la doc MS. Voici le code complet qui vous permettra, peut-être, d'oublier plus facilement "Set of" de Dephi...

Stay tuned!

Code de la doc MS :

using System;

public class ParseTest
{
    [FlagsAttribute]
    enum Colors { Red = 1, Green = 2, Blue = 4, Yellow = 8 };

    public static void Main()
    {
        Console.WriteLine("The entries of the Colors Enum are:");
        foreach (string colorName in Enum.GetNames(typeof(Colors)))
        {
            Console.WriteLine("{0}={1}", colorName,
                                         Convert.ToInt32(Enum.Parse(typeof(Colors), colorName)));
        }
        Console.WriteLine();
        Colors myOrange = (Colors)Enum.Parse(typeof(Colors), "Red, Yellow");
        Console.WriteLine("The myOrange value {1} has the combined entries of {0}",
                           myOrange, Convert.ToInt64(myOrange));
    }
}

/*
This code example produces the following results:

The entries of the Colors Enum are:
Red=1
Green=2
Blue=4
Yellow=8

The myOrange value 9 has the combined entries of Red, Yellow

*/

 

 

Les class Helpers, enfer ou paradis ?

Class Helpers 

Les class helpers sont une nouvelle feature du langage C# 3.0 (voir mon billet et mon article sur les nouveautés de C# 3.0).

Pour résumer il s'agit de "décorer" une classe existante avec de nouvelles méthodes sans modifier le code de cette classe, les méthodes en questions étant implémentées dans une autre classe.

Le principe lui-même n'est pas récent puisque Borland l'avait "inventé" pour Delphi 8.Net (la première version de Delphi sous .Net) afin de permettre l'ajout des méthodes de TObject à System.Object (qu'ils ne pouvaient pas modifier bien entendu) afin que la VCL puisse être facilement portée sous .Net. Borland avait déposé un brevet pour ce procédé (ils le prétendaient à l'époque en tout cas) et je m'étonne toujours que Microsoft ait pu implémenter exactement la même chose dans C# sans que cela ne fasse de vagues. Un mystère donc, mais là n'est pas la question.

Mauvaises raisons ?

Les deux seules implémentations de cet artifice syntaxique que je connaisse (je ne connais pas tout hélas, si vous en connaissez d'autres n'hésitez pas à le dire en commentaire que l'on puisse comparer) sont donc celle de Borland dans Delphi 8 pour simplifier le portage de la VCL sous .NET et celle de Microsoft dans C# pour faciliter l'intégration de Linq dans le langage.

Deux exemples, deux fois pour la même raison un peu spécieuse à mes yeux : simplifier le boulot du concepteur du langage pour supporter de nouvelles features. Deux fois une mauvaise raison à mes yeux, un peu trop puristes peut-être, qui pensent qu'un élément syntaxique doit se justifier d'une façon plus forte, plus théorique que simplement "pratique".

Résultat, je me suis toujours méfié des class helpers car leur danger est qu'un objet se trouve d'un seul coup affublé de méthodes "sorties d'un chapeau", c'est à dire qu'il semble exposer des méthodes publiques qui ne sont nulles part dans son code. J'ai horreur de ce genre de combines qui, à mon sens, favorise un code immaintenable. Si j'adore la magie, à voir ou à pratiquer, je la déteste lorsque je porte ma casquette d'informaticien... J'ai donc toujours conseillé la plus grande circonspection vis à vis de cet artifice syntaxique, que ce soit à l'époque (déjà lointaine.. le temp passe!) où je faisais du Delphi que maintenant sous C# qui vient d'ajouter cette fioriture à sa palette.

Jusqu'à aujourd'hui, faute d'avoir trouver une utilisation intelligente des class helpers qui ne puissent être mise en oeuvre plus "proprement", les class helpers étaient à mon sens plutôt à classer du côté enfer que paradis. Interface et héritage m'ont toujours semblé une solution préférable à ces méthodes fantomes.

Trouver une justification

Mais il n'y a que les imbéciles qui ne changent pas d'avis, n'est-ce pas... Et je cherche malgré tout toujours à trouver une utilité à un outil même si je le trouve inutile de prime abord, réflexe d'ingénieur qui aime trouver une place à toute chose certainement.
J'ai ainsi essayé plusieurs fois dans des projets de voir si les class helpers pouvaient rendre de vrais services avec une réelle justification, c'est à dire sans être un cache misère ni une façon paresseuse de modifier une classe sans la modifier tout en la modifiant...

Comme j'ai enfin trouvé quelques cas (rares certes) dans lesquels les class helpers me semblent avoir une justification pratique, je me suis dit que vous en toucher deux mots pourraient éventuellement faire avancer votre propre réflexion sur le sujet (même si j'ai bien conscience que je dois être assez seul à me torturer la cervelle pour trouver absolument une utilité aux class helpers :-) ).

Bref, passons à la pratique.

Un cas pratique

Premier cas, les chaînes de caractères. Voilà un type de données vieux comme la programmation qui pourrait être un bon candidat à l'exploitation des possibilités des class helpers. En effet, hors de question de dériver la classe System.String et encore moins de pouvoir modifier le mot clé "string" de C#. Pourtant nous utilisons très souvent les mêmes fonctions "personnelles" sur les chaînes de caractères d'un même projet.

Par exemple, j'ai pour principe que les chaînes exposées par une classe (propriétés de type string donc) ne soient jamais à null. De ce fait, dans toutes les classes qui exposent un string, j'ai, dans le setter, la même séquence qui change l'éventuel null de value à string.Empty. C'est assez casse-pieds à répéter comme ça mécaniquement dans toutes les propriétés string de toutes les classes.

Et là, pas de possibilité de faire supporter une interface à System.String, ni de la dériver comme je le disais plus haut. C'est ici que les class helpers peuvent trouver une première justification pratique pour le développeur en dehors d'avoir facilité la vie à MS pour implémenter Linq.

Prenons le code suivant que nous plaçons dans une unité "Tools" de notre projet :

public static class Utilities
{

     public static string NotNullString(this string s)
      { 
return !string.IsNullOrEmpty(s) ? s.Trim() : string.Empty; }
...
 }

La classe Utilities est une classe statique qui contient tous les petits bouts de code utilisables dans tout le projet. Parmi ces méthodes, on voit ici l'implémentation du class helper "NotNullString". D'après cette dernière, la méthode ne sera visible que sur les instances de la classe "string". Le code lui-même est d'une grande simplicité puisqu'il teste si la chaîne en question est vide ou non, et, selon le cas, retourne string.Empty ou bien un Trim() de la chaîne. J'aime bien faire aussi systématiquement un Trim() sur toutes les propriétés string, je trouve ça plus propre surtout si on doit tester des équalités et que les chaînes proviennent de saisies utilisateurs.

Dans la pratique il suffira maintenant n'importe où dans notre projet d'écrire la chose suivante pour être certain qu'à la sortie de l'affectation la chaîne résultante ne sera jamais nulle et qu'elle ne comportera jamais d'espaces en trop en début ou en fin :

public string BusinessID
{  
get { return _BusinessID; }
    
set if (value != _BusinessID)
            
{ _BusinessID = value.NotNullString().ToUpperInvariant();
                
DoChange("BusinessID");
            
}
         
}
}

On voit ici une propriété string "BusinessID" qui, dans son setter, utilise désormais la nouvelle méthode fantome de la classe string... En fin de séquence nous sommes certains que _BusinessID est soit vide, soit contient un chaîne sans espace de tête ou de queue (et qu'elle est en majuscules, en plus dans cet exemple).

Voici donc une première utilisation "intelligente" des class helpers, la décoration d'une classe du framework (ou d'une lib dont on n'a pas le code source) pour lui ajouter un comportement, éventuellement complexe, dont on a souvent l'utilité dans un projet donné.

On pourrait penser ainsi à une fonction "ProperCase" qui passe automatiquement la casse d'une chaîne en mode "nom de famille", c'est à dire première lettre de chaque mot en majuscule, le reste en minuscule, ou à bien d'autres traitements qu'on aurait besoin d'appliquer souvent à des chaînes dans un projet.

Encore un autre cas

Dans la même veine, une application doit souvent manipuler des données issues d'une base de données et les modifier (en plus d'en insérer de nouvelles). On le sait moins (mais on s'aperçoit vite quand cela bug!) que le framework .NET possède, pour les dates par exemple, ses propres mini et maxi qui ne sont pas compatibles à toutes les bases de données, notamment SQL Server. Si vous attribuer à une date la valeur DateTime.MinValue et que vous essayez d'insérer cette dernière dans un champ Date d'une base SQL Server vous obtiendrez une exception de la part du serveur : la date passée n'est pas dans la fourchette acceptée par le serveur.
Dommage... DateTime.MinValue est bien pratique...

On peut bien entendu fixer une constante dans son projet et l'utiliser en place et lieu de DateTime.MinValue. Voci un exemple pour MaxValue (le problème étant le même):

DateTime MaxiDate = new DateTime(3000, 1, 1, 0, 0, 0);

Il suffira donc d'utiliser MaxiDate à la place de DateTime.MaxValue. La date considérée comme "maxi" est ici arbitraire (comme on le ferait pour la date mini) et est choisie pour représenter une valeur acceptable à la fois pour l'application et pour la base de données. Ici on notera que je prépare le terrain pour le bug de l'an 3000. Moins stupide qu'un coboliste et le bug de l'an 2000, vous remarquerez que je me suis arrangé ne plus être joignable à la date du bug et que mes héritiers sont aussi à l'abris de poursuites judiciaires pour quelques siècles :-)

L'utilisation d'une constante n'a rien de "sale" ou de "moche", c'est un procédé classique en programmation, même la plus éthérée et la plus sophistiquée. Toutefois, Puisque DateTime existe, puisque DateTime est un type complexe (une classe) et non pas un simple emplacement mémoire (comme les types de base en Pascal par exemple), puisque cette classe expose déjà des méthodes, dont Min et MaxValue, il serait finalement plus "linéaire" et plus cohérent d'ajouter notre propre MaxValue à cette dernière en place et lieu d'une constante.

Encore un bon exemple d'utilisation des class helpers. Ici nous homogénéisons notre style de programmation en évitant le mélange entre méthodes de DateTime et utilisation d'une constante. De plus, en ajoutant une méthode spécifique à DateTime, celle-ci sera visible par Intellisense come membre de DateTime, ce qui ne serait pas le cas de la constante. 

Dans la même classe Utilities nous trouverons ainsi :

public static DateTime SQLMaxValue(this DateTime d)
{
return new DateTime(3000, 1, 1, 0, 0, 0); }

 Et nous voici avec la possibilité d'écrire : MaDate = DateTime.SQLMaxValue();

Conclusion

Enfer ou paradis ? Les class helpers, comme tout artifice syntaxique peuvent se ranger dans les deux catégories, ils ne sont qu'un outil à la disposition du développeur. Un simple marteau peut servir à bâtir une maison où vivre heureux ou bien à assassiner sauvagement son voisin...  Les objets inanimés n'ont pas de conscience, ou plutôt, si, ils en ont une : celle de celui qui les utilise. A chacun d'utiliser les outils que la technologie humaine met à sa disposition pour créer un enfer ou un paradis...

Techniquement, je n'enfoncerai pas les portes ouvertes en donnant l'impression d'avoir découvert une utilisation miraculeuse des class helpers. Cela serait stupide, puisque justement cette syntaxe a été créée par Borland puis MS pour justement décorer des classes dont on ne possède pas le source (pas d'ajout de méthode ni d'interface) et qui ne sont pas héritables. En ajoutant des class helpers à string ou DateTime nous ne faisons rien d'autre que d'utiliser les class helpers exactement en conformité avec ce pour quoi ils ont été créés.

L'intérêt de ce billet se situe alors dans deux objectifs : vous permettre de réfléchir à cette nouveauté de C#3.0 que vous ne connaissez peut-être pas ou mal et vous montrer comment, en pratique, cela peut rendre des services non négligeables.

Si l'un ou l'autre de ces objectifs a été atteint, vous tenez alors votre récompense d'avoir tout lu jusqu'ici, et moi d'avoir écrit ce billet :-)

Stay tuned !

[EDIT: voir cet autre billet plus récent sur les class helpers]

Une bande de hackers chez Microsoft !

Nous ne sommes plus le 1er avril donc il s'agit d'info et non d'intox...

En effet, Microsoft a engagé, depuis un moment déjà, des hackers parmi les meilleurs.

Pourquoi ? De la même façon que Fichet-Bauche emploie d'anciens taulards spécialisés dans l'ouverture des coffres et autres portes sécurisés : pour valider en interne la solidité des solutions de sécurité retenues et apporter des conseils sur les améliorations possibles.

Cette équipe possède un blog, qui commence à s'activer un peu. Il est donc bon d'y aller faire des petits tours pour se ternir informer. Dans le dernier billet publié on y apprend par exemple la création du site www.HelloSecureWorld.com, un site Microsoft dédié à la sensibilisation sur les problèmes de sécurité. Ludique et très animé, cela vaut une visite pour vous détendre. 

Bon Surf !

Office Open XML enfin standardisé

Après un an et demi de bataille, Microsoft vient d'annoncer la standardisation par ISO/IEC de son format Office Open XML. (l'annonce MS ici).

Connu aussi sous le nom de OOXML ou OpenXML, il s'agit d'un format de stockage composite utilisable par de nombreuses applications utilisant la notion de "document". Les traitements de texte, tableurs, les présentations de type PowerPoint sont bien entendu les condidats tout trouvé pour exploiter cette norme basée sur XML et permettant l'échange autant que la manipulation des documents sans passer par des formats propriétaires.

C'est en soi un grand progrès, même si techniquement c'est encore un moyen de mettre XML à toutes les sauces. Mais ce format, pour être verbeux n'en est pas point une évolution majeure du point de vue conceptuel. Les utilisateurs de GED et même les développeurs désirant mieux intégrer les documents externes dans leurs applications pour les cataloguer, les archiver, les manipuler, y trouveront leur compte.

Les différents "bouts de XML" constituant un document OpenXML sont regroupés dans un conteneur, un package "Open Packaging Convention" qui n'est autre qu'un (pas tout jeune) fichier Zip. Le conteneur regroupe aussi les différents fichiers annexes formant le document telles les images par exemple.

Saluons ainsi la naissance d'une norme ouverte et facilement exploitable annonçant l'ère d'une vraie interopérabilité entre les différents logiciels et OS pour une partie essentielle des informations produites par les utilisateurs : les documents (textes, présentations, feuilles de calcul majoritairement).

D'un autre côté il est intéressant de noter comment notre profession qui est l'illustration même du terme "high tech" est capable de faire de l'innovant avec des formats aussi vieux et simples que le sont XML (issu de SGML, descendant de GML créé en...1960!) et Zip (années 80). Cela démontre peut-être que nous atteignons un palier de maturité : celui où on commence à plus se concentrer sur les concepts que sur le dernier zinzin à la mode qui oblige à tout reconcevoir. Plutôt une bonne chose donc.