Google a récemment (et sans prévenir) changé son API permettant d'intégrer des Waves sur des sites.
Rien de méchant, car cela concerne surtout les options graphiques, mais cela a suffi pour empêcher mes compte-rendus de conférence de s'afficher correctement : à la place, il n'y avait plus que du blanc... J'ai donc fouillé un peu pour trouver d'où cela pouvait venir.
Vous trouverez ci-dessous les nouvelles instructions détaillées.

Et puis, j'en profite pour vous annoncer la bonne nouvelle : il est maintenant possible de consulter les Waves intégrées sans posséder de compte Wave !
C'était la principale critique remontée à Google, et elle a visiblement été écoutée. Par contre, la modification de la Wave est toujours réservée aux utilisateurs authentifiés.

Google Wave provides an "Embedded API" that can be leveraged to insert a single Wave into any HTML page.
Unfortunately, the official documentation is somewhat old and gives the procedure only for the sandbox waves, not the regular ones. As a result, I had to struggle more than an hour long and browse the API's source code to get all the parameters right, and eventually successfully display a wave in a blog post (see my summary of the last Paris JUG's meeting, in French).

Here is a very short tutorial to help you integrate waves in your own websites/blogs in minutes !

Je me suis un peu amusé avec la nouvelle balise HTML5 Canvas et l'API Javascript associée...
Si vous avez un navigateur récent, vous devriez pouvoir voir et contrôler les flammes :

Je vous invite à regarder le code source de la page pour plus de détails !

Voici le compte-rendu de la conférence "Dans la tête de Peter Lubbers" organisée par Zenika mercredi dernier.

Peter Lubbers est directeur de la formation chez Kaazing, une société spécialisée dans le streaming de données en temps réel pour le web ; leur produit phare, le WebSocket Gateway, exploite au maximum les dernières API de communication proposées par HTML5. Peter était donc l'homme de la situation pour nous donner les dernières nouvelles du front, en attendant la sortie de son livre "Pro HTML5 Programming", prévue pour avril.

La conférence s'organisait autour de 5 points : le bilan des technologies actuelles, les WebSockets, les Server-sent Events, l'objet XmlHttpRequest version 2, et le Cross-document messaging.

Lorsque, dans une page Web, l'utilisateur déclenche une action qui modifie toute la page, il est de bon ton de s'assurer qu'il ne déclenche pas une autre action avant que la page suivante ne soit chargée.

Tous les éléments qui permettent à l'utilisateur d'agir sur la page doivent donc être désactivés. Parmi ceux-ci, il y a les champs de formulaires (champs texte, boutons-poussoir, boutons radio, cases à cocher, ...), et les liens hypertextes.

Si désactiver les champs de formulaires est assez facile en JavaScript (tous possèdent un attribut disabled, qu'il suffit de mettre à true), désactiver les liens est une autre paire de manches ! Il y a bien un attribut disabled sur les ancres, mais c'est une spécificité, non standard, d'Internet Explorer. Et en plus cet attribut ne modifie que l'affichage : avec IE, un hyperlien dans l'état "disabled" est toujours actif !

Ce constat mène assez rapidement à la question suivante : comment faire ? Et d'ailleurs, est-ce faisable ?

Qu'insère le bloc JavaScript suivant dans la page HTML ?

var flagBidon = true;
 
function test() {
    var x = 5;
 
    document.write(x);
    document.write("<br/>");
 
    if (flagBidon) {
        var x = 10;
        document.write(x);
        document.write("<br/>");
    }
 
    document.write(x);
    document.write("<br/>");
}
 
test();

Qu'insère le bloc JavaScript suivant dans la page HTML ?

var x = 9;
function test() {
    document.write(x);
    document.write("<br/>");
 
    var x = 10;
 
    document.write(x);
    document.write("<br/>");
}
test();
document.write(x);

Un petit quiz JavaScript, pour changer. Voici une fonction de validation de dates, écrite en JavaScript :

/**
* Vérifie que la date passée sous la forme d'une chaîne de caractères
* (exemple : "15/11/2008") est valide
*/
function validateDate(dateAsString) {
    // Vérifie que la date est du format "JJ/MM/AAAA"
    var regex = new RegExp("^[0-9]{2}[/][0-9]{2}[/][0-9]{4}$", "g");
 
    if (regex.test(dateAsString)) {
        // Vérifie en plus que les champs jour, mois et année sont
        // cohérents et correspondent à une date pas totalement farfelue.
        var fields = dateAsString.split("/");
        var day    = parseInt(fields[0]);
        var month  = parseInt(fields[1]);
        var year   = parseInt(fields[2]);
 
        if (day   > 0 && day   < 32 &&
            month > 0 && month < 13 &&
            year  > 1970 && year < 2200) {
            return true;
        }
    }
    return false;
}

Question : Certains jours de l'année 2009 ne passent pas la validation alors qu'ils le devraient. Lesquels, et pourquoi ?

La librairie Javascript MoreCSS permet d'appliquer des fonctions Javascript à des éléments HTML simplement en les stylant à l'aide de propriétés CSS spéciales. Cette approche, bien qu'assez surprenante au premier abord, permet de bénéficier à la fois de la simplicité de la syntaxe CSS et de la puissance du code Javascript.

On peut en revanche regretter que le code du fichier javascript soit obfusqué, malgré la licence Creative Commons...

Avec AJAX, Javascript a considérablement renforcé sa position de langage incontournable du web. Pourtant, il est notoirement délicat à programmer et à debugguer -- la faute tant à sa syntaxe parfois exotique qu'à son support inégal par les différents navigateurs...

Avec Javascript 2 (ECMA-Script 4), la relève est en marche et les spécifications semblent prometteuses (pdf). Bien qu'encore en cours de rédaction (une première version est prévue pour l'automne), elles laissent d'ores et déjà apparaître d'intéressantes fonctionnalités :

• programmation objet (classes, interfaces...),
• typage statique des variables,
• compilation/vérification du code,
• chargement de modules à la demande (lazy-loading)...

Si elles sont évidemment les bienvenues, ces améliorations ne sont-elles pas un peu tardives ? Les développeurs, qui commencent enfin à disposer d'outils et de frameworks performants rendant Javascript réellement exploitable, sont-ils prêts à franchir le pas ?
De plus, leur frustration envers Javascript a déclenché la prolifération de solutions alternatives (Google Web Toolkit, Flex...) qui sont généralement plus performantes et plus simples à développer et maintenir. La version 2.0 saura-t-elle regagner le coeur des développeurs ?