Dans le précèdent billet, je vous avais proposé d’invoquer un service WCF en utilisant les XmlHttpRequest à la sauce dojo (xhrGet et xhrPost).

Bien que cette façon de faire soit bien plus rapide et « élégante » que lorsqu’on doit écrire soit même ce type de code js (avec support des navigateurs browser etc…), il existe une méthode encore plus simple.

Bien, revenons quelques instants sur les services web publiés aussi bien sous forme d’ASMX qu’en WCF, ils ont la bonne idée d’être accompagnés d’une nomenclature les décrivants ; Vous l’aurez compris je parle bien ici du wsdl.

L’intérêt majeur que je vois dans le wsdl est que cela permet de générer automatiquement un proxy qui saura communiquer avec le service web ciblé. D’ailleurs, c’est grâce à cette description que visual studio génère la classe proxy lorsque vous ajoutez une référence web dans votre solution.

L’idée derrière les classes du namespace dojox.rpc est d’avoir ce même comportement en JavaScript, c’est-à-dire, la possibilité d’interroger un service pour connaitre ses caractéristiques et de générer automatiquement un proxy JavaScript simplifiant son utilisation.

Excellent me direz-vous, nous avons déjà le wsdl… arf c’est la que le bas blesse, le xml (et plus spéciale une définition wsdl) n’a jamais été le format le plus simple et le plus rapide à traiter en JavaScript. Par contre, comme vous le savez déjà le json est le format fétiche du web.

C’est donc à partir d’une définition en json respectant le formalisme nommé smd (pour Simple Method Description) que le Framework dojo va vous permettre de générer le proxy JavaScript qui correspondra à votre service web.

Bien trêve de discussion adaptons notre précédent exemple pour l’adapter a cette technique de génération de proxy. Créons la définition du service :

{
    "transport": "POST",
    "envelope": "URL",
    "target": "http://localhost/WCFDojoRpc/ClockService.svc/",
    "services": {
        "GetTime": {
            "transport": "GET",
            "target": "GetTime",
            "parameters": []
        }
    }
}

On y retrouve facilement les informations relatives a l’adresse du service et la méthode disponible. Pour plus de détail, je vous laisse vous reporter au groupe de travail qui s’intéresse au format smd.

Modifions quelque peu notre script :

    Dojo & WCF

    

    
        dojo.require('dojo.parser');
        dojo.require("dojox.rpc.Service");

        var clockProxy;

        dojo.addOnLoad(
            function() {
                clockProxy = new dojox.rpc.Service("definition.json");
                GetTime();
            }
        );

        function GetTime() {
            clockProxy.GetTime()
                .addCallback(
                    function(data) {
                        dojo.byId('ServerTime').innerHTML = data.d;
                    }
                )
                .addErrback(
                    function(data) {
                        alert(data);
                    }
                );
        }    
        
    

    
    

Comme vous le voyez nous avons principalement retiré l’utilisation des xhrPost, que nous avons remplacés par une simple ligne new dojox.rpc.Service(“definition.json”); qui génère le proxy JavaScript automatiquement a partir de la définition en json.

Bien évidement le service WCF reste identique a celui présenté dans la première partie de cet article.

Je retire deux conclusions partielles de l’utilisation des smd :

• Il est certain que la possibilité de décrire un service facilite ensuite la vie du développeur coté js.
• Il est dommage de devoir utiliser autre chose que le wsdl qui est généré pour nous, surtout lorsqu’on est un développeur .NET.

Le top serait d’avoir une description smd générée automatiquement à chaque modification de notre service WCF et que ce soit intégré dans le pipeline WCF. C’est ce que je me propose de vous montrer lors de la troisième partie de cet article.

Voila déjà plusieurs mois, j’avais une discussion sur les architectures SOA avec Christophe et surtout comment les mettre en œuvre avec les Framework (Ajax) Javascript. A l’époque il démarrait une refonte de sa galerie de photos perso LCCFamilly et souhaitait qu’elle soit Full Ajax.

Sur ce même principe, je me propose aujourd’hui de vous montrer comment interroger un WebService WCF à partir du Framework Dojo ; Faisons un service qui nous donne l’heure et la date courante formatée selon la locale du serveur. On commence par déclarer l’interface de notre service.

[ServiceContract(Namespace="http://www.devolis.com/2009/04/WCFDOJO")]
    public interface IClockService
    {
        [OperationContract]
        [WebInvoke(Method = "POST")]
        string GetTime();
    }

Notez l’utilisation du verbe POST ; Il convient d’éviter le verbe GET comme la peste si vous utilisez Internet Explorer comme client de votre WebService. En effet, sa gestion du cache, fait qu’il n’effectue que le premier appel, puis se contente de renvoyer ce qu’il a en cache.

Puis passons à l’implémentation à proprement dit du service

/// AspNetCompatibilityRequirements n'est utile que si le webservice est hosté dans IIS
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class ClockService : IClockService
    { 
        public string GetTime()
        {
            return DateTime.Now.ToString();
        }
    }

Ok, a ce moment précis, il vous est déjà possible de tester le WebService en créant rapidement un projet console et en ajoutant une WebReference sur ce dernier… Je vous laisse le faire de votre coté :)

Passons à notre page web :

    Dojo & WCF
    
    
    
    
        dojo.require('dojo.parser');
    
    
    

        function GetTime() {
            dojo.xhrPost({
                url: "ClockService.svc/GetTime",
                handleAs: "text",
                contentType: "application/json; charset=utf-8",
                load: function(response, ioArgs) {
                    dojo.byId('ServerTime').innerHTML = dojo.fromJson(response).d;
                    return response;
                },
                error: function(response, ioArgs) {
                    alert("Error :" + ioArgs.xhr.status);
                    return response;
                }
            });
        }
        
    

    
    

Comme vous pouvez le constater, le code est assez concis. Apres avoir déclaré l’utilisation de Dojo 1.3 à partir du CDN de Google, j’ai déclaré une fonction GetTime() qui par le biais d’un XmlHttpRequest (xhr) va demander au WebService de lui retourner le DateTime actuel ; les données sont attendues sous forme de JSon.

Vous remarquerez aussi la construction de l’url d’appel, il s’agit du nom du Service suivit par le nom de la méthode.

Si vous exécutez maintenant la page web, vous recevrez une erreur http 405. En effet pour l’instant Dojo et WCF ne parlent pas encore la même langue. Dojo parle en JSon et WCF en Soap… il va nous falloir configurer le service.

Voici la globalité du ServiceModel que vous trouverez dans votre web.config ou app.config en fonction du type de projet choisit.

La principale différence avec la configuration standard est au niveau du binding du endpoint. Par défaut le binding est définit en tant que wsHttpBinding (messages soap) ; Pour parler Json il nous faut choisir le binding webHttpBinding (JSon).

Voila, relancez la page web… tadam… c’est magique.

Dans la prochaine partie de cet article je tacherais de vous montrer comment éviter d’avoir à écrire les blocs de javascript xhrPost en passant par dojo.rpc

Christophe, t’as plus qu’a réécrire LCCFamily :)

Il y a quelques jours, je suis tombé un peu par hazard sur la page Microsoft Web Platform Installer.

De quoi s’agit-t-il? Sans avoir testé mais d’après les infos qui sont distillées sur ce mini site, cela prend la forme d’un installeur qui vous aidera à mettre en place :

• Le framework .NET evidemment
• Le serveur web IIS 7
• La base relationnelle SQL Serveur
• Les outils de dev : Visual Studio et Expression Web
• Et tout un tas d’applications web opensource comme DNN, BlogEngine.NET etc…
• Et tenez vous bien vous trouverez même des applications qui fonctionnent sous PHP (Acquia Drupal, WordPress etc…)

Personnellement tout cela me fait penser aux initiatives qui furent lancées il y a une petite dizaine d’années en arrière avec des installateurs comme EasyPhp et compagnie… encore une fois, l’histoire se répète!! mais pour le coup, il me semble que c’est plutôt une bonne chose.

Une petite question me traverse l’esprit tout d’un coup; on ne parle pas une seule seconde de WSS dans tout ça… pourtant ça risque bien de faire un peu d’ombre… non?

Dojo est désormais passé en version 1.3 avec son lot de nouveautés que je vous laisse découvrir ici.

Mais ce qui est plus excitant encore (et qui est presque passé inaperçu) c’est la mise à disposition de TaskSpeed, un outil de benchmark des principaux Framework Ajax actuellement disponible [JQuery, Dojo, Prototype, MooTools].

Mais comment benchmarker des Framework qui n’offrent pas tous les mêmes fonctionnalités ? (JQuery n’offre pas de composants graphique par exemple). TaskSpeed propose de les noter sur leur plus petit dénominateur commun, c’est-à-dire la manipulation du DOM HTML.

Sur le site, il est possible à tout un chacun de visualiser les résultats d’une bonne quinzaine de métrique par Framework. J’ai moi-même réalisé le test avec mon navigateur préféré Firefox… (Jérôme, y’a des gens qui ont fait le test avec Opéra… je te jure y’a pas que toi qui l’utilise :) ).

Et le vainqueur est… Dojo bien sur.

Le dernier est JQuery… Au fait, qui peut me rappeler pourquoi Microsoft à choisit ce Framework pour l’intégrer dans son offre Ajax ?

Afin d’assurer la plus grande transparence, il est possible de voir le code exécuté pour chaque test en cliquant simplement sur la cellule au croisement d’un Framework et d’un browser.

PS : Pour ceux qui se demandent comment sont faits les graphs… il s’agit de dojox.gfx.

PS2 : Je vous laisse aussi découvrir par la même occasion quel est le pire navigateur lorsqu’il s’agit de manipuler le DOM.

A croire que l’histoire se répète indéfiniment, et qu’on ne tire pas de leçons du passé.

Pourquoi ce coup de gueule ? Tout simplement parce que je viens de tomber sur une news qui présente les EXTRAORDINAIRES nouvelles propriétés CSS du moteur Webkit (utilisé principalement par Safari et Google Chrome)…

Attention mesdames et messieurs, jusqu’à maintenant on utilisait les CSS pour styler un élément, maintenant avec Webkit vous pouvez lui donner un comportement.

La preuve en image : une horloge uniquement en CSS.

Et le fabuleux bout de CSS proprietaire qui va bien…

      /* -webkit-transition: property duration timing-function */
      #clock img[src*='hour'] {
         -webkit-transform: rotate(90deg);
       }

      #clock img[src*='second'] {
         -webkit-transition: -webkit-transform 60s linear;
       }

      #clock:target img[src*='second'] {
         -webkit-transform: rotate(360deg);
       }

Comportements vous avez dit ? Mais, normalement ce n’est pas le rôle de Javascript de donner un comportement, dit l’architecte Web ?

Et dire que dans le passé, lorsqu’ Internet Explorer 6 était le seul browser potable du marché (non Jérome Links n’est pas à proprement parlé un browser :)) des milliers de voix s’élevait contre toutes les fonctions propriétaires que Microsoft avait introduites en marge de la norme.

Tient, la c’est marrant, j’en entends beaucoup moins s’insurger….

      #fabrice {
         -webkit-shutup: 5sec;
      }

[Source Ajaxian]

Dernièrement, j’ai l’impression que dans le giron de Microsoft on s’émeut de plus en plus, parfois outre mesures, de ce qui se fait chez Google. Pourtant, je me suis laissé dire qu’il existe surement des terrains ou les deux offres se complètent.

En ce moment par exemple, je travaille chez mon client avec le composant Javascript de Virtual Earth qui permet, comme tout le monde doit déjà le savoir, d’afficher de belles cartes géographique avec zoom, navigation interactive et toutes les petites choses sexy que les aficionados de Google Maps apprécient.

Imaginez maintenant que vous ne souhaitiez pas uniquement

• explorer les environs de votre lieu d’habitation,
• ou bien encore prévoir le trajet en faire en auto pour vous rendre dans votre prochain lieu de villégiature

mais que vous souhaitiez pour votre projet BI actuel afficher vos indicateurs quels qu’ils soient sur une jolie carte le tout sur une simple page web…

Bien, je suis sur que vous me voyez venir avec mes gros sabots…

Alors prenons une petite dose de Virtual Earth et un soupçon de Google Charts et l’on obtient alors quelque chose dans ce goût la :

Et pour ceux qui se demande comment on peut faire ce genre de chose voici le code, somme toute très très simple :

 Virtual Earth

    
    
    
        function initialize() {
            map = new VEMap('myMap');
            var ParisLatLong = new VELatLong(48.8667, 2.3333);
            map.LoadMap(ParisLatLong);
            map.Resize(800, 600);
            map.SetZoomLevel(7);
            map.SetCenter(ParisLatLong);

            var newShape = new VEShape(VEShapeType.Pushpin, ParisLatLong);

            newShape.SetTitle("Répartition des moyens de transport à Paris");
            newShape.SetDescription('![My google chart](http://chart.apis.google.com/chart?chtt=un+beau+spacer&chts=ffffff&chs=200x100&chf=bg,s,ffffff&cht=p3&chd=t:56.00,40.00,4.00&chl=Autos|Motos|Autres)');
            map.AddShape(newShape);
        }
    
    
    
        HTML, BODY, FORM {margin:0; padding:0; height:100%; width:100%;}
    
    

    
        
    

Evidement je laisse libre cours à votre imagination pour rendre vos cartes BI encore plus interactive et bien entendu attractives pour les utilisateurs.

J’en profite pour vous donner deux liens qui m’ont semblé fort intéressants :

• Google Chart Creator pour créer vos graphs rapidement
• Virtual Earth Map Control SDK 6.2 offline documentation

Un post très très rapide afin d’annoncer la sortie de la version 0.4 d’AllyStats. Cette version permet de :

• utiliser le script dans tout les pays.
• utiliser le script si vous possedez plusieurs compte sur des univers différents.
• modifier la couleur de fond des graphiques.
• meilleure proportion des graphs.
• correction du calcul de la progression lors de l’export HTML

Toutes vos remarques ont étés prises en compte et je les intégrerais à mesure dans le script… il me faut juste un peu de temps… libre

Depuis l’annonce de la première version Française d’OGame Skript sur le forum officiel OGame, les choses ont pris une bonne tournure. En effet l’accueil qui lui à été réservé à été plutôt bon, plusieurs personnes m’ont gentillement aider à corriger les coquilles qui se sont faufilées par ci par là, certains allant même jusqu’à poster les corrections nécessaires dans telle ou telle regexp.

Je ne pouvais rêver mieux… encore merci à tout ceux qui participent à améliorer le script.

Ainsi grâce au travail de tous, j’ai le plaisir de releaser la version 0.3 de cette traduction Française du script qui comporte toutes les corrections demandées sur le board OGame.Pour les plus préssés, le script est diponible ici le temps qu’il soit publié sur le site OGame Skript officiel; Fallait bien que je vous fasse profiter de la primeur.

Pour cette seconde release, il n’y aura pas de Changelog, car je savais qu’il y aurait beaucoup de remontées, mais promis la prochaine fois, je tracerais exactement tout les changements.

Beaucoup d’entre vous doivent dors et déjà connaitre cette astuce qui facilite les problématiques de déploiement de vos cubes Olap (Sql Server Analysis Services); Pour ma part je n’ai découvert qu’aujourd’hui qu’il est possible de parametrer les scripts XMLA, MDX et DMX lors de leur execution via ASCMD.

Petit retour en arrière, ASCMD est un utilitaire en ligne de commande qui permet d’exécuter des scripts sur une instance d’Analysis Services locale ou distante. Le code source est fournit dans les samples de SQL Server sous forme d’un projet C# à compiler.

Dans le cadre d’une livraison chez un de vos client par exemple, ASCMD s’avère fort utile car il permet de scripter toutes les opérations possible que vous souhaiter effectuer; ceci vous affranchit de la lourde tache des backup/restore couramment usités dans la version 2000 d’Analysis Services.

Prenons un exemple concret; Le script suivant, permet de modifier le nom du serveur sur lequel est disponible la source de données relationnelle :

    
        Adventure Works DW
        Adventure Works DW
    
    
        
            Adventure Works DW
            Adventure Works DW
            Provider=SQLNCLI.1;Data Source=$(ServerName);Persist Security Info=False;Integrated Security=SSPI;Initial Catalog=AdventureWorksDW
            
                ImpersonateServiceAccount
            
            PT0S
        
    

Notez la déclaration et l’utilisation de la variable $(ServerName). Celle-ci va pouvoir être définit lors de l’execution de la manière suivante :

ascmd.exe -S localhost -i modifyDS.xmla -v ServerName=My_production_server

Cette fonctionnalité ouvre de nouveaux horizons pour les déploiements, plus besoin de demander à vos interlocuteurs de faire ceci ou cela;

• Scriptez vos actions sous forme de scripts XMLA parametrés.
• Livrez un fichier ini, seul point que votre interlocuteur devra éditer afin de le faire correspondre à son environnement.
• Demander à votre interlocuteur de lancer le seul fichier fichier bat fournit réunissant l’ensemble des commandes à executer.
• Vous êtes zen, vous venez de considérablement diminuer les chances d’erreurs du à une mauvaise manipulation de votre interlocuteur.

Bon déploiements à tous.

Je vous l’avais annoncé à demi mots le 12 septembre dernier (OGame Skript [Fr] releasé), j’allais écrire au moins un script greasemonkey pour OGame. Voila c’est chose faite, enfin pour une béta :)… je vous présente AllyStats; L’idée est d’améliorer la page statistique d’alliance (merci ptitony & les Freeglad pour l’idée) de la manièere suivante :

Si ce que vous avez vu vous plais, n’hésitez pas à l’installer.

Pré-requis

• Firefox 3.0
• greasemonkey

Il est possible qu’il vous soit demandé de redémarrer Firefox; Dans ce cas, surtout faites le.

Installation

• Installer le script AllyStats

Synchronisation

Pour les utilisateurs avancés, il vous est possible de (re)charger les statistiques d’une période précédente en suivant le formalisme JSON suivant :

[
 {"Name":"Player 1","Points":"1000","Homeworld":"[x:xxx:xx]"},
 {"Name":"Player 2","Points":"1242","Homeworld":"[x:xxx:xx]"},
 ... 
 {"Name":"Player N","Points":"758","Homeworld":"[x:xxx:xx]"}
]

Cette feature vous permettra également de synchroniser les stats de tout les membres de votre alliance lors de la première installation.

Utilisation

Elle est des plus simple; dès la première utilisation AllyStats va stocker les points de chaque joueur de votre alliance. A mesure que leur points augmentent, le graphique qui est apparu dans la nouvelle colonne mettra en évidence leur progression. Si vous souhaitez surveiller l’évolution de vos coéquipier de manière hebdomadaire, il vous faudra réinitialiser le classement en utilisant le bouton prévu à cet effet (le second). Finalement, si vous disposez également d’un forum ou vous vous retrouvez avec vos amis, AllytStats vous donne la possibilité d’exporter vos progressions au format html & bbcode

N’hésitez pas à me dire ce que vous en pensez, ainsi que me faire part de toutes vos remarques constructives.

Enjoy