SimonFerquel.net

[DSL Tools] Génération incrémentale, génération multi-artefacts : partie 2

Simon FERQUEL — Mon, 28 Apr 2008 18:56:41 GMT

Dans la précédente partie de cet article, nous avons vu comment générer plusieurs fichier à partir du même DSL. Nous allons maintenant voir comment faire de la génération de code incrémentale. C'est à dire que l'on va modifier du code existant écrit par l'utilisateur en injectant du code provenant de notre générateur. Pour y parvenir, nous allons utiliser une API COM exposée par Visual Studio baptisée CodeModel.

CodeModel permet de parcourir en lecture-écriture notre code source sous forme d'arbre d'objets, pour peu qu'il soit écrit dans un langage supportant CodeModel (C#, VB.Net et C++ sont actuellement supportés par Microsoft). Cette API est assez rudimentaire et peu pratique à utiliser "out of the box". Pour comprendre l'API et son fonctionnement, je vous conseille la lecture de cet article de la MSDN : http://msdn2.microsoft.com/en-us/library/92aexfx5(VS.80).aspx.

Ce qu'il faut en retenir, c'est que ca ressemble énormément à du DOM XML, mais dont la grammaire est différentes. L'interface "de base" (oui, on est en COM, on ne manipule pas les objets directement en utilisant leur classe, mais via les interfaces qu'ils implémentent... le "de base" voulant dire que c'est l'interface commune à tous les objets d'un arbre CodeModel) CodeElement a des propriétés Parent, Children et Kind, tout comme XmlNode. On peut ensuite le caster sous forme de CodeClass, CodeNamespace etc., tout come XmlNode peut-être casté en XmlElement, XmlAttribute, etc. Le soucis étant qu'il n'éxiste pas d'API de requétage correct pour CodeModel.

Afin de palier à ce manque et rendre l'API plus "developer friendly", mon idée a été de développer des méthodes d'extensions pour les classes CodeClass2, CodeFunction2, CodeProperty etc.

Voici un exemple simple:

public static IEnumerable<CodeFunction2> FindMethodsByName(this CodeClass2 codeClass, string name)
        {
            return codeClass.Children.OfType<CodeFunction2>().Where(cf => cf.Name == name);
        }

Cette méthode d'extension me permet de faire des choses du genre :

if (codeClass.FindMethodsByName("Initialize").FirstOrDefault() == null)
                CreateInitializeMethod();

Ce qui est vous l'avouerez est quand même plutôt simple comparé à ce que l'on aurait du faire en C# 2 :).

Pour illustrer l'utilisation de cette API, de mes méthodes d'extension ainsi que de ce que l'on a vu dans la précédente partie, nous allons écrire un générateur de Behavior ASP.Net Ajax qui produit les behaviors côté client en Script#, et des Control Extender côté serveur pour faciliter leur utilisation avec ASP.Net.

Création du modèle

Le modèle est très simple, car il ne fait intervenir que 2 notions : L'Extender et l'ExtenderProperty

Je ne m'étendrai pas trop là dessus, car c'est vraiment simple. La seule chose à dire c'est que j'ai créé des TypeEditor pour le BehaviorFile et ExtenderFile, ainsi qu'une enum PropertyType (qui n'a que 3 valeurs possibles pour l'instant : String, ExternalControl, ExternalBehavior, qui permettront donc de référencer d'autres contrôles / extenders facilement).

Création des "CodeGenerators"

Comme nous l'avons vu dans l'article précédant, nous n'allons pas créer de CustomTool, mais nous allons directement mettre le code de génération dans le projet de Package Visual Studio. Dans notre cas, nous avons 2 classes à générer dans 2 projets différents (un projet Script# côté client, un projet C# côté serveur). Les 2 classes étant écrites en C#, avec les même contraintes de capacité de "customisation", nous allons toutes les 2 les créer / modifier avec CodeModel. Pour faciliter tout celà, j'ai créer une classe de base dont les 2 générateurs hériteront :

public abstract class CodeModelBasedGenerator
    {
        private DTE2 _dte;
        public DTE2 DTE
        {
            get { return _dte; }
        }
        private string _fileName;

        protected string FileName
        {
            get { return _fileName; }
        }

        private FileCodeModel2 _fileCodeModel;

        protected FileCodeModel2 FileCodeModel
        {
            get { return _fileCodeModel; }
        }
        private CodeModel _codeModel;

        protected CodeModel CodeModel
        {
            get { return _codeModel; }
        }
        private ProjectItem _projectItem;

        protected ProjectItem ProjectItem
        {
            get { return _projectItem; }
        }
        protected CodeModelBasedGenerator(string fileName, IServiceProvider serviceProvider)
        {
            _fileName = fileName;
            _dte = (DTE2)serviceProvider.GetService(typeof(DTE));
            if (_dte == null)
                throw new InvalidOperationException("The service provider cannot provide Visual Studio DTE Service");
            _projectItem = _dte.Solution.FindProjectItem(_fileName);
            if (_projectItem == null)
                throw new InvalidOperationException("The specified file is not part of the current solution projects");
            _fileCodeModel = (FileCodeModel2)_projectItem.FileCodeModel;
            if (_fileCodeModel == null)
                throw new InvalidOperationException("The specified file does not support Code Model");
            _codeModel = _projectItem.ContainingProject.CodeModel;
           
        }

        public abstract void Generate();
    }

En héritant de cette classe, mes générateurs auront ainsi accès au FileCodeModel du fichier qu'ils doivent manipuler, ainsi qu'à d'autres points d'extensibilité.

Voici un extrait de code du générateur de behavior Script#, illustrant l'utilisation de la classe de base, et de mon API de requétage CodeModel :

public class BehaviorCodeGenerator : CodeModelBasedGenerator
    {
        private ExtenderElement _element;
        public BehaviorCodeGenerator(string fileName,ExtenderElement element, IServiceProvider provider)
            : base(fileName, provider)
        { _element = element; }

        public override void Generate()
        {
            FileCodeModel.AddImportsIfNotExist("System", "System.DHTML", "Sys", "Sys.UI");
            var behaviorNS = FileCodeModel.FindOrCreateNamespace(_element.BehaviorNamespace);
            var behaviorClass = behaviorNS.FindOrCreateClass(_element.Name + "Behavior");
            if (behaviorClass.Bases.OfType<CodeElement>().Where(ctr => ctr.FullName == "Sys.UI.Behavior")
                                                         .FirstOrDefault() == null)
                behaviorClass.AddBase("Behavior", null);


            // Constructor
            var constructor = behaviorClass.FindConstructors().Where(fc => fc.MatchParameterTypes("System.DHTML.DOMElement"))
                                                              .FirstOrDefault();
            if (constructor == null)
            {
                constructor = (CodeFunction2) behaviorClass.AddFunction(_element.Name + "Behavior", 
                                                            vsCMFunction.vsCMFunctionConstructor, 
                                                            null, -1, 
                                                            vsCMAccess.vsCMAccessPublic, null);
                var param = constructor.AddParameter("element", "DOMElement", -1);
                var editPoint = param.EndPoint.CreateEditPoint();
                editPoint.EndOfLine();
                editPoint.InsertFormated(" : base(element)");
            }

            // Properties
            foreach (var prop in _element.ExtenderPropertyElements)
            {
                CodeVariable2 field;
                CodeProperty codeProp;

(en violet, ce sont les méthodes d'extensions que j'ai rajouté)

Comme on peut le voir, le code existant est manipulé, mais pas écraser. On vérifie la présence du constructeur des propriétés, des "using" etc. avant de les ajouter au code existant.

Branchement des générateurs

Comme dans mon article précédant, je déclenche la génération au moment ou le document est sauvé. Ce code a donc lieu dans la classe DocData (que l'on étend par partialité, pour ne pas se faire écraser par le générateur de code du designer de DSL) :

partial class ExtenderFactoryDocData
   {
       protected override void OnDocumentSaved(EventArgs e)
       {
           base.OnDocumentSaved(e);
           ExtenderBagModel root = RootElement as ExtenderBagModel;
           foreach (var elem in root.ExtenderElements)
           {
               var behaviorGen = new CodeGenerators.BehaviorCodeGenerator(elem.BehaviorFile, elem, ServiceProvider);
               behaviorGen.Generate();
               var extenderGen = new CodeGenerators.ExtenderCodeGenerator(elem.ExtenderFile, elem, ServiceProvider);
               extenderGen.Generate();
           }
       }
   }

Et voilà, rien de très compliqué en somme... juste une librairies d'extensions (que vous pouvez télécharger avec les sources), qui facilite grandement la vie.

Pour regarder ce que ca donne en vrai, manipuler le code et l'améliorer (par exemple, utiliser des chemins relatifs plutôt qu'absolus pour référencer les fichiers, gérer d'autres types de données...), voici les sources, contenant un petit projet de test tout simple (qui nécessite par ailleurs l'installation de Script# pour fonctionner) :

Les sources

Mots clés Technorati : DSL,C Sharp,CodeModel,Visual Studio

[DSL Tools] Génération incrémentale, génération multi-artefacts : partie 1

Simon FERQUEL — Thu, 03 Apr 2008 21:53:39 GMT

Dans la plupart des présentations sur les DSL Tools, on nous montre des scénarios très simples de génération de code "one-shot", et qui ne tiennent pas compte du code éxistant.

Récemment, j'ai eu à travailler sur un cas plus complexe : Notre client souhaitait faire du développement d'interface utilisateur Ajax piloté par les specs. C'est à dire, que la personne en charge des spécifications de l'UI doit pouvoir définir le contenu de l'écran (les champs de formulaires), des règles d'assistance à la saisie (remplir une combobox en fonction de tels ou tels autres champs, de données provenant d'un SGBD etc.) et des déclencheurs pour exécuter ces règles (événement sur un champs, timer, ...), et qu'à partir de cela, un squelette de code et des artefacts de documentation soient générés. Pour chaque champs et chaque règle, le "spécificateur" donnera une description détaillée de ce que le "dévelopeur" devra faire. L'outil utilisé par le "spécificateur" (et plus tard par le "dévelopeur" aussi, rassurez vous ;-)) est un DSL qui va donc générer un certain nombre d'artefacts:

Un extrait de doc au format xhtml utilisé pour les documents de spécification détaillant le contenu des écrans, les actions déclenchées sur tel ou tel évènement etc.
Un UserControl ASP.Net contenant les champs définis dans le DSL
Un Behavior ASP.Net Ajax permettant de contrôler l'état de l'écran côté client et générer les "triggers" sensés déclencher les "règles", et contenir des points d'entrée customisables par le dévelopeur (notamment pour donner la possibilité d'implémenter certaines règles côté client)
Un Service WCF exposé à ASP.Net Ajax, contenant des méthodes correspondant aux règles à exécuter côté serveur (celles qui nécessitent un accès à la base de donnée par exemple). La description de chaque règle sera recopiée dans la Documentation Xml de ces méthodes afin d'assister le dévelopeur
Bien sûr, le développeur n'aura à sa charge que l'implémentation des règles et éventuellement la retouche du UserControl pour modifier le layout (la communication entre le behavior et les règles côté client et serveur étant entièrement générée)

Une première problématique se pose directement : notre DSL génère plusieurs artefacts, donc un CustomTool implémentant IVsSingleFileGenerator ne fonctionnera pas. Pour cela il existe un moyen simple, il suffit dans la classe DocData générée par le designer DSL (dans le projet DslPackage) et de surcharger sa méthode OnDocumentSaved (créez une partial class dans un fichier à part pour ne pas vous faire écraser vos modifications) :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Company.DemoIncrementalDSL
{
    partial class DemoIncrementalDSLDocData
    {
        protected override void OnDocumentSaved(EventArgs e)
        {
            base.OnDocumentSaved(e);

            // Do your own logic
            var rootElement =  this.RootElement as ModelWithMultipleFiles;

            string docFilePath = rootElement.DocumentationFilePath;
            string classFilePath = rootElement.ClassFilePath;
        }
    }
}

Dans cet exemple, ModelWithMultipleFiles est le nom de l'élément racine de mon model, et il contient 2 DomainProperties "DocumentationFilePath" et "ClassFilePath". Nous sommes donc prêt ici à générer nos fichiers à partir du model (car ici nous savons que le model vient d'être persisté, nous avons l'instance en cours dans la variable rootElement, et nous avons donc les chemins des fichier à générer).

Pour parfaire cet exemple, il serait bon de fournir un éditeur personnalisé pour les chemins de fichier. En effet, l'expérience utilisateur de notre DSL reste pour le moment à désirer, car nos propriétés de types string, ne sont éditables que via une TextBox.

Pour y remédier, nous devons implémenter un UITypeEditor et placer un attribut sur notre propriété spécifiant l'utilisation de notre editeur. Voici un exemple de code pour implémenter UITypeEditor à base de SaveFileDialog :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Drawing.Design;
using System.Windows.Forms;

namespace Company.DemoIncrementalDSL
{
    // UITypeEditor est situé dans le namespace System.Drawing.Design
    class FilePathEditor : UITypeEditor
    {
        public override UITypeEditorEditStyle GetEditStyle(System.ComponentModel.ITypeDescriptorContext context)
        {
            return UITypeEditorEditStyle.Modal;
        }
        public override object EditValue(System.ComponentModel.ITypeDescriptorContext context, IServiceProvider provider, object value)
        {
            using (var sfd = new SaveFileDialog())
            {
                sfd.FileName = value.ToString();
                if (sfd.ShowDialog() == DialogResult.OK)
                {
                    return sfd.FileName;
                }
                else
                    return value;
            }
        }
    }
}

Dans l'éditeur de DSL, on posera alors un custom attribute sur les propriété qui devront utiliser cet éditeur :

Un deuxième problème se pose à nous : Générer du code de manière incrémentale. En effet, je n'ai jamais vu de projet où les spécifications étaient fixées une fois pour toute. Il y a toujours des allers-retours à faire, adapter les specs au feedback utilisateur etc. Il n'est donc pas possible de regénérer notre code sans tenir compte des personnalisations opérées par le dévelopeur depuis la précédente génération (remplissage des méthodes de règle). Pour des fichiers basés sur du X(ht)ml, il n'y a pas de soucis, les APIs DOM, ou Linq to Xml sont là pour ca, mais en ce qui concerne le code C# (ou VB), cela semble assez compliqué.

Nous verrons dans la prochaine partie de cet article comment utiliser une API fournie par Visual Studio pour explorer / écrire / modifier du code programatiquement (et qui nous aidera donc à régler notre problème) : CodeModel.

UPDATE : La 2e partie de l'article est publiée

Mots clés Technorati : DSL,Ajax,UITypeEditor,CodeModel

VLinq is alive!

Simon FERQUEL — Thu, 03 Apr 2008 08:41:05 GMT

Et voilà, vous l'attendiez, moi aussi d'ailleurs, VLinq vient d'être "releasé" sur MSDN Code Gallery : http://code.msdn.microsoft.com/vlinq

Mitsu a fait un long poste récapitulatif sur le projet, son déroulement, comment il marche etc., je vous le (v)linq donc ^^: Le poste avec toutes les infos qui vont bien sur VLinq.

Apparemment il y'a encore un bug ou deux qui traînent, notamment dans le programme d'installation. Mitsu a posté une solution en commentaire de son post, et je vais essayer de regarder ce qui va pas dès que j'ai un peu de temps et une VPC vierge sous la main.

Enjoy it, Comment it, Share it!

Mots clés Technorati : Linq,Visual Studio,VLinq,WPF,C Sharp

[TFS] Debug de Custom Task Team Build

Simon FERQUEL — Wed, 20 Feb 2008 14:13:17 GMT

Pour un projet interne, j'ai récemment du étendre les fonctionnalités de Team Foundation Server, en implémentant (entre autres) une tâche MSBuild pour Team Build.

Le processus de création de custom task est éxactement le même que celui d'une task MSBuild classique, mais le debugging n'est pas franchement aisé. Dans le cas où la tâche n'utilise pas d'informations fournies par Team Build, il n'y a pas de problème, il suffit de lancer un MSBuild en stand-alone sur lequel on attache le debugger, mais dans le cas contraire, ca se complique.

En effet, attacher le debugger sur le processus du Web-Service Team Build ne résout rien, car il ne fait que lancer et piloter un process MSBuild externe (le debugger ne voit que ce qui tourne dans le process ASP.Net).

Ainsi pour pouvoir attacher un debugger, il faut feinter légèrement et faire en sorte que ce soit la task MSBuild elle-même qui demande un debugger. Pour ce-faire, une solution consiste d'écrire au début de la méthode Execute:

#if DEBUG

System.Diagnostics.Debug.Fail("Click Retry, and attach a debugger!");

#endif

Cet astuce peut aussi être utilisée, par exemple lors du développement de Services Windows.

Techdays 2008 : Sources du projet MyFlickr

Simon FERQUEL — Mon, 18 Feb 2008 09:20:50 GMT

Comme promis, je poste les sources du projet MyFlickr, avant et après Silverlightisation.

Je vais prendre le temps ce week end ou le week end prochain de rejouer la démo en WebCast, en prenant tout le temps d'expliquer en détail ce que je fais (chose que je n'ai pas pu faire en 15 minutes de démo mardi dernier ^^).

En attendant, profitez des sources qui fournissent un bon exemple d'utilisation de SBT, Script#, des techniques de templatisation, de conventions de nommage et tout ce que l'on a vu dans cette session "marathon".

MyFlickr Source code.

Mots clés Technorati : Techdays,Silverlight,Javascript,Script#

Techdays 2008 : Viendez les amis ! viendez !

Simon FERQUEL — Wed, 30 Jan 2008 01:53:32 GMT

Les Techdays 2008, comme on dit par chez nous, "C'est-bon-mangez-en", avec pleins de présentations et démos sur les nouveautés MS.

Ce sera aussi l'occasion de venir me rencontrer lors de 2 sessions que j'aurai le plaisir de co-animer :

Visual Linq Query Builder, mardi 12 février 14h30 - 15h30, avec Mitsu Furuta, mon mentor le temps de mon stage chez MS ;-). On parlera de Linq bien sûr, de VLinq aussi, de WPF dans Visual Studio sûrement, mais aussi des choses plus rigolotes sur le "comment qu'on a fait avec nos petits doigts", et l'occasion pour les développeurs junior et étudiants d'avoir un retour d'expérience sur le déroulement d'un stage chez Microsoft (même si le stage que j'ai fait est un petit peu... particulier !). C'est une session niveau 200, donc on ne rentrera pas dans des détails trop trop techniques non plus, session aspirine-free ! (mais néanmoins une session à laquelle je tiens tout particulièrement, parce que c'est quand même un peu mon bébé)
Développement avancé avec Silverlight 1.0 et JavaScript, mardi 12 février 13h00 - 14h00, avec Guillaume Renaud, architecte au MTC, architecte du projet Blue Portal (et aussi celui qui s'est le levé le plus tard le samedi du ProFrance à Biarritz :-p). Attention, session 400, mais pas dans un sens "je vais voir des trucs hyper techniques et je vais rien y comprendre" (enfin, y'aura quand même de quoi bien se poiler, je vous rassure), mais plutôt, avec l'expérience acquise en production, comment être productif avec Silverlight 1.0 et JavaScript, quels sont les pièges à éviter, et quelles sont les perspectives d'avenir de Silverlight 1.0 avec la sortie de la prochaine version... En vrac voici de quoi on va essayer de parler:

Rappels sur JS / ASP.Net Ajax, IntelliSense, Debugging, appels de Web Services
Animations : Blend, création de templates et conventions de nommage, solution adoptée dans Silverlight Behaviors Toolkit, Tweened, Injection de xaml dynamique à partir de JS / depuis des fichiers de template
Silverlight et l'existant JS : migration DHTML -> Silverlight, scénarios multi-plugin, clipping, utilisation du framework Silverlight Behavior Toolkit dans une application ASP.Net Ajax, programmation orientée composants et comment Script# peut nous aider, build events, ou comment automatiser pleins de choses ;-)
Sujets pur Silverlight : debugging, gestion des erreurs, écrans de loading, downloader, fonts, overlay CSS, architecturer ses applications en JS, gestion du mode Full Screen, Drag & Drop...
Silverlight 1.0 vs Silverlight 2.0

Comme vous pouvez le voir cette session Silverlight est vraiment TRES fournie... On vous promet très peu de slides, beaucoup d'action, et pour le coup normalement tout le monde devrait sortir de la salle sur les rotules (et moi le premier ^^).

Vous pourrez récupérer les sources des démos (en tout cas des miennes...) sur ce blog dès la fin de la session... A savoir partir d'une application ASP.Net Ajax avec du code fonctionnel déjà en place, et migrer l'interface en Silverlight 1.0 avec des effets "zouff ! wiff ! boom !" en s'appuyant sur cet existant fonctionnel.

Voilà voilà, je vous conseil de prendre un peu d'avance sur la session et de vous familiariser un minimum avec Asp.Net Ajax (côté client hein, pas juste l'Update Panel), ainsi qu'avec JavaScript et Silverlight 1.0 avant de venir...

Mots clés Technorati : Techdays,Silverlight,Linq,VLinq,JavaScript

Source code du Framework .Net

Simon FERQUEL — Wed, 16 Jan 2008 23:19:04 GMT

Ca a été annoncé il y a quelques temps déjà, c'est maintenant chose faite : Le code source du Framework .Net 3.5 est ouvert :-).

Enjoy!

Mots clés Technorati : .Net,C#,Visual Studio

Silverlight Behaviors Toolkit - Happy New Year release

Simon FERQUEL — Sun, 30 Dec 2007 17:12:19 GMT

Je viens de publier une nouvelle release de Silverlight Behaviors Toolkit, pleine de Breaking Changes, mais avec quelques nouveautés sympathiques dans l'"API core" :

MultiBehavior : Permet d'attacher plusieurs Behaviors au même UIElement
Supports des UIElement non nommés
Supports des NameScopes Silverlight
Version compactée qui fonctionne
FlowPanel (merci Pierlag ^^)

Cette version nécessite Script# 0.4.5.0 minimum (qui apporte quelques nouveauté sympathiques, voir mon post précédant).

SBT n'est pas encore tout à fait stabilisé, mais le nombre de breaking changes dans les prochaines versions devraient être considérablement réduit.

N'hésitez pas à tester, utiliser, commenter, et communiquer sur ce projet :)!

Mots clés Technorati : Silverlight,SBT,Silverlight Behaviors Toolkit

Script# 0.4.5 : Support de VS 2008 et pas mal de BugFixes

Simon FERQUEL — Sat, 29 Dec 2007 16:16:41 GMT

Pendant ces périodes de fêtes, je surveille un peu moins les différents blogs / projets qui m'intéresse, et j'ai donc loupé il y'a une dizaine de jours, la sortie d'une nouvelle version de Script# (projet mené par Nikhil Kothari).

La plus grosse nouveauté est la présence d'un MSI pour Visual Studio 2008 à côté du MSI version 2005. Une autre nouveauté importante, est la présence de nombreux big-fixes du compilateur, surtout en ce qui concerne la génération de code compacté (code release). Par exemple, Silverlight Behavior Toolkit fonctionne désormais correctement en version "Release".

Au passage, je suis en train de travailler activement sur SBT, et de nombreuses modifications de fond (refactoring, application de behaviors sur des éléments non nommés, application de plusieurs behaviors sur le même élément), ainsi que de nouveaux samples, avec utilisation du downloader Silverlight pour compacter et télécharger séparément les templates d'animation sont en cours de finition.

Attendez vous à des Breaking changes qui vont faire mal... et on est toujours à un stade alpha, sans garantie de compatibilité ascendante pour le moment !

Ca y est, c'est fini

Simon FERQUEL — Thu, 20 Dec 2007 10:51:06 GMT

Et voilà, après 6 mois de travail sur VLinq au sein de l'équipe DPE de Microsoft France (salut les gens au fait ^^), le projet est en cours de finalisation (localisation, tests finaux, quelques réglages au niveau de la distributions...) et mon stage est finit.

J'en profite justement pour vous annoncer la sortie des Webcast du tour "Accès aux données" de Mitsu, dans lequel vous pourrez voir 13 minutes de présentation du projet (bon la version sur laquelle on l'a fait date un peu, mais ça donne une bonne idée ^^).

Mots clés Technorati : Linq,VLinq,Data access,Microsoft