Denis Dollfus' Blog

DotWeb : commémoration du premier anniversaire de la disparition de Volta

Il y a un an jour pour jour le projet Volta s'arrêtait brutalement malgré un accueil enthousiaste. Volta proposait (très) ambitieusement des outils pour faciliter le codage et le déploiement des applications Web n-tier. Dans une approche très "write once run anywhere", le même code C# aurait pu être déployé sur le serveur ou sur le client, la même IHM aurait pu se matérialiser en Ajax ou en Silverlight.

Dans la série "On Trouve Tout Sur le Web" : le tombstone generator

Je suis plutôt circonspect sur le côté "write once run anywhere" tant les problématiques de performance et de cache, pour ne citer que celles-là, diffèrent suivant l'endroit où le code s'éxécute. 

En revanche le fait de pouvoir écrire en C# ce qui tournera en Javascript promettait confort et productivité. Non pas que le Javascript soit une ignominie, mais simplement que les outils d'assistance au développeur sont bien plus élaborés en C# qu'en Javascript de par le simple typage fort de C#. L'auto-completion, le refactoring semi-automatique et l'orientation objet structurante (i.e. getter et setter ) suffisent à faire la différence. 

Aborder une grosse application Ajax en C# plutôt qu'en Javascript rassure. En C# "si ça ne compile pas, ça ne marchera pas" dit le dicton. En JavaScript puisqu'il n'y a pas de compilation, il reste "ça ne marchera pas". J'ironise mais tous les développeurs qui parcourent le Web en mode "debug" savent au nombre d'erreurs de script rencontrés combien le JavaScript fait souffrir le Web. 

Bref. Y a-t-il une vie après Volta ?

Oui :

1. Il y a mieux que Volta, il y a Script#, bien supérieur à Volta parce que lui n'est pas mort. Script# a servi en interne chez Microsoft au développement d'Office 14 version Web, de Live Messenger et de Live Mesh. Script# marche bien, les contributions (ExtJS#, jQuery#) en témoignent. Un avantage de Script# est que le Javascript généré est parfaitement lisible. En revanche pas moyen de poser un point d'arrêt au sein du C#, il faut débugger en JavaScript. Néanmoins cette approche permet déjà de concevoir Javascript comme le langage assembleur du Web : un truc réservé aux experts, bien compris des machines mais peu des humains, qu'on a vu à l'école et qu'on oublie sans remord (pas .
2. Il y a mieux que Script#, il y a Google Web Toolkit (GWT). Avec un succès grandissant, GWT est de plus en plus utilisés dans les applications de taille respectable. Google Wave notamment repose sur GWT. Pour fixer les idées concernant sa popularité, d'après Google Trends GWT est presque aussi populaire que Linq. Au fait : au lieu de C#, GWT s'appuie sur Java. Gros avantage par rapport à Script#, GWT permet de debugger directement dans le code Java, plus besoin de visualiser le JavaScript, qui n'a désormais plus vocation à être lu et a fortiori édité.
3. Pour info le précurseur de ses outils s'appelle Morfik, toujours commercialisé. Je ne le connais pas.
4. Encore plus fort, pendant que je préparais ce billet qui aurait du être un simple hommage à feu Volta, Franck Laub annonce sur le forum Alt.Net l'existence de son projet de clone .Net de GWT, DotWeb. DotWeb est le seul environnement dans l'esprit "JavaScript est l'assembleur du Web" qui dispose d'un debugger C#. A suivre de très très près ! Franck recherche des contributeurs, c'est une opportunité pour des développeurs intéressés. Les sources de DotWeb, pour en avoir le coeur net,  sont disponibles ici.

Excellent timing !

0HTML : du HTML sans HTML

Photo cc Curious_Zed

Pourquoi faut-il générer du HTML sans écrire du HTML ?

• Parce que HTML ressemble au XML, et que XML est affreux;
• Pour faire comme JavaFX, qui permet de décrire le code et les élements graphiques avec un seul langage au lieu des duos habituels graphique/code tels que XAML/C#, MXML/ActionScript et HTML/Javascript. Regardez cet exemple de code JavaFX pour comprendre comment graphiques et code (déclaratif et procédural) s'enchevêtrent en JavaFX.

Sans code côté serveur, ça serait trop facile.

Voici donc une tentative baptisée 0html (qui repose sur jQuery). Vous constaterez que les sources ne contiennent que très peu de HTML, même la balise body est manquante. Fondamentalement, c'est du HTML écrit en JSON.

Puisque je ne pense vraiment pas être le premier à y avoir pensé (plus de 200 frameworks Javascript...), connaissez-vous des frameworks qui ont déjà atteint l'objectif de créer des pages Web sans écrire de HTML (ni des montagnes de code procédural) ?

JQuery sera distribué avec Visual Studio

Puisque JQuery est le plus populaire des frameworks open-source JavaScript et que Microsoft s'ouvre vraiment à l'open-source, il ne devrait pas être étonnant que Microsoft ait décidé de livrer JQuery avec la prochaine version de Visual Studio. Enfin si un peu, j'ai quand même du mal à m'y faire.

Cela dit la popularité de JQuery est tel qu'il bat Silverlight et GWT au jeu du nombre de requêtes Google. Impressionant.

A noter que JQuery sera utilisé pour étendre les contrôles ASP.NET Ajax et ASP.NET MVC. C'est Scott qui le dit : "Going forward we'll use jQuery as one of the libraries used to implement higher-level controls in the ASP.NET AJAX Control Toolkit, as well as to implement new Ajax server-side helper methods for ASP.NET MVC.  New features we add to ASP.NET AJAX (like the new client template support) will be designed to integrate nicely with jQuery as well. "

Dropthings, portail Web 2.0 open-source

Omar AL Zabir publie sur  codeplex.com tout le nécessaire, en open-source of course, pour que chacun puisse construire son propre portail à la mode 2.0, c'est à dire avec widgets à choisir et à drag-and-droper dans la page.

Ca s'appelle Dropthings et c'est entièrement développé avec les nouveautés de .Net 3.5 et 3.0 : Workflow Foundation, C# 3.0 et ASP.NET Ajax Extenders.

C'est bien ? A vous de juger, mais on a de bonnes raison de le penser puisqu'Omar connait bien le monde des portails Web2.0 : il est co-fondateur et directeur technique de pageflakes.com, un des concurrents dans la course au portail Web 2.0, loin derrière netvibes.

Et vous ne pourrez pas vous plaindre d'un manque de documentation puisqu'Omar a aussi publié un livre qui décrit entre autres choses le design de dropthings : "Building a Web 2.0 Portal with ASP.NET 3.5".

Trop fort.

Démo : http://www.dropthings.com/
Sources : http://www.codeplex.com/dropthings
Le blog de Omar : http://msmvps.com/blogs/omar/Default.aspx
Pageflakes : http://www.pageflakes.com/

Exposer un service Web JSON en ASP.NET

Quand un service Web retourne des objets au format JSON, ces objets sont directement exploitables en JavaScript. C'est une façon productive (mais quick  & dirty ?) d'amener les objets métiers du serveur au sein du client léger.

Mais les infos qui concernent la mise en œuvre d'un service Web au format JSON sont assez éparpillées et parfois incorrectes. On peut notamment lire ici ou là  qu'un service Web flanqué de l'attribut ScriptMethod se sérialise par défaut au format JSON, ce que l'expérience ne confirme pas.

Voici la recette (qui suppose qu'ASP.NET Ajax est installé sur le serveur et correctement configuré) :

1. Ajouter l'attribut ScriptMethod devant la classe de service;
2. Spécifier que le binding ne se conforme à aucun profil WS-I via l'attribut WebServiceBinding;
3. Devant les méthodes de services, ajouter les attributs WebMethod et ScriptMethod, en spécifiant en paramètre JSON en format de réponse et le cas échéant en autorisant la commande http GET;
4. Dans le fichier de config de l'application Web, autoriser les "protocoles" httpget et httppost qui ne sont autorisés par défaut (seul HttpSOAP l'est).

Soit au total :

[WebService(Namespace = "http://www.denisdollfus.com/WebServices", Description = "JSON Web service")]
[WebServiceBinding(ConformsTo = WsiProfiles.None)]
[ScriptService]
public class JsonServices : System.Web.Services.WebService
{
    public JsonServices()
    {}
 
    [WebMethod]
    [ScriptMethod(ResponseFormat = ResponseFormat.Json, UseHttpGet=true)]
    public SerializableOrder[] GetTopOrders()
    {
        DataAccessLayer l_dal = new DataAccessLayer();
        return l_dal.GetTopOrders();
    }
}

Et dans le fichier .config, sous <system.web> :

<webServices>
    <protocols>
        <add name="HttpGet"/>
        <add name="HttpPost"/>
    </protocols>
</webServices>

A raffiner en fonction des besoins bien sûr.

Plus d'infos :

• Configuration (HttpSoap, HttpGet, etc.) 
• ScriptServiceAttribute
• ScriptMethodAttribute