OpenJSAN : Les Mongueurs de JavaScript

Ceux qui lisent les listes de la communauté Perl auront peut-être remarqué la mention d'un site venant d'ouvrir dans le style de CPAN  : JSAN, JavaScript Archive Network. Ce site a pour objectif de rendre le même service à la communauté des développeurs Web que CPAN à celles des développeurs Perl.

Le site

Les défis techniques

Mais là où Perl a quelques avantages, comme la gestion d'espaces de noms au sein même du langage, Javascript s'appuie sur un DOM sans notion de hiérarchie. De même, pour les tests et la documentation, pas de standard de fait, ni de normes.

Ainsi, Adam Kennedy, Casey West, David Wheeler et Sean Burke, quelques-uns des instigateurs de JSAN, ont commencé à songer aux réponses à ces soucis. Et la recette est souvent simple : reprendre ce qui fonctionne pour la communauté Perl et le porter ou l'adapter à Javascript quand cela est faisable.

Espace de nommage

Comme on l'a dit plus haut, pas d'espace de nommage à proprement parler dans Javascript, mais un DOM (modèle objet de document) que l'on peut exploiter. L'avantage de Javascript est que l'on peut construire son espace de nommage en utilisant des closures (fermetures, des fonctions anonymes) ou des objets simples qui s'insèrent ainsi dans l'espace de nommage vu par Javascript. On peut le vérifier facilement en utilisant l'inspecteur DOM de Mozilla/Firefox.

Associés à ces fermetures, on peut aussi rencontrer les prototypes d'objets. Ils se font via une assignation d'une collection de fonctions, tableaux ou autres objets Javascript à la propriété prototype de l'objet créé.

Documentation

Le POD, Plain Old Documentation, est donc le format repris pour JSAN. Ce format est connu de nombre de développeurs Perl (et JSAN), est très simple à utiliser, tout en restant libéral. Pas de champs obligatoires dont l'absence ferait planter la génération de la documentation.

Les tests

David Wheeler a procédé à un portage de Test::Simple en Javascript, qui est ainsi devenu Test.Simple. Test.Harness est aussi disponible, ainsi que Test.Harness.Browser qui permet de lancer toute la suite de tests dans un navigateur, de la même façon que make test (ou Build test) lance toute la suite d'un modules Perl. Bon, en fait, c'est à vous d'ouvrir le navigateur sur la bonne page, qui contient un cadre avec la liste des suites des tests, à vous ensuite de cliquer pour en voir les résultats.

Exemple

Voici une version raccourcie (sans la totalité du POD) et traduite et commentée de l'exemple de module JSAN fourni sur le site :

    // Set up namespace
    if (!JSAN) var JSAN = {};

    JSAN.Example = function () {
       // Constructeur. Cela permet de remettre à zéro les membres de la
       // classe ici.
       // Si le code est utilisé pour une interface non objet (à base de
       // simples fonctions), l'assignation peut être un simple objet
       // vide :     JSAN.Example = {};
    }

    // Exporter System for JSAN. Utilisé par le framework JSAN, comme
    // Exporter en Perl.
    JSAN.Example.EXPORT = [ 'functionOne', 'functionTwo' ];

    // Déclarations de fonctions totalement nommées
    JSAN.Example.functionOne = function (list) { }
    JSAN.Example.functionTwo = function () { }

    // Idem pour une propriété
    JSAN.Example.DEBUG = 1;

    // Prototype de classe.
    // Mettre les méthodes et les données de la classe ici.
    JSAN.Example.prototype = {

       // Propriété "privée" de la classe, car préfixée par « _ », comme
       // en Perl. Ici un scalaire.
       _privateProperty: null,

       // Une propriété publique, sous forme d'un tableau vide.
       publicProperty: [],

       // Méthode privée, à n'appeler qu'au sein de la classe en
       // utilisant « this »
       _onlyForMe: function (format, str) { },

       // Une méthode publique, qui peut être appelée par n'importe
       // quelle instance de la classe
       useMeHere: function () { }
    };

    /*
    =head1 NAME
    
    JSAN.Example - Example Library for the Javascript Archive Network
    
    =head1 SYNOPSIS
    
    ...
    
    Le POD est donc mis entre commentaires JavaScript (à la C).
    
    =cut
    */

Inconvénients

Un des inconvénients les plus importants de Javascript a été relevé par Michael Schwern, qui maintient nombre de modules Perl d'importance dont l'essentiel ExtUtils::MakeMaker. Il s'agit du fait que JavaScript n'a pas de mécanisme d'inclusion comme Perl peut l'avoir avec use ou require, ou comme C peut l'avoir avec l'utilisation du préprocesseur (#include).

Pour résumer ses commentaires, il est en effet obligatoire de coller du code dans chaque page HTML que vous écrivez afin d'éviter de coller du code dans chaque page HTML... En effet, l'inclusion de code permet d'éviter de coller toujours le même code dans un nouveau programme. Mais comme le montre Schwern, et comme JavaScript n'a pas cette fonction d'inclusion, il faut tout de même coller du code afin d'éviter d'en coller encore plus.

Et ce code est le suivant :

      function include(jssrc) {
        document.write("<script type='text/javascript' src='"+jssrc+"'></script>");
      }
      include("include2.js");

Ce qui fait dire à Schwern que les gens qui ont conçu JavaScript n'ont pas dépassé l'année 1962.

Mais dans le cadre de JSAN (le module), ça devient quasiment aussi simple qu'en Perl. Le code à coller dans toutes les pages HTML est le suivant :

    <script type="text/javascript" src="/js/JSAN.js"></script>

Ensuite, une inclusion (qui se fait derrière par le biais de XMLHTTPRequest) est l'affaire d'un simple use, comme en Perl :

    <script>
        JSAN.use('Test.Simple');
        plan({tests: 1});
        ok(1 == 1, 'one does equal one!');
    </script>

Dans un autre module :

    try {
        JSAN.use('Some.Library');
    } catch (e) {
        alert("Requires JSAN");
    }

Ces deux exemples sont tirés de la documentation du module JSAN, je vous laisse le soin d'explorer le reste.

Dernière minute : il semble que l'infrastructure JSAN change de tactique pour cette inclusion, de par le fait que l'utilisation de inclusion avec XMLHTTPRequest en synchrone soit violente tant pour le serveur que pour l'utilisateur qui attend. La solution est d'en revenir à l'injection dans le DOM (solution utilisée par Schwern), mais en utilisant une définition des dépendances d'un module. Ces dépendances sont déterminées et calculées à la construction du module par son auteur, et surtout avec le module Perl JavaScript::Librarian d'Adam Kennedy.

En résumé : JSAN est une archive de modules JavaScript comme CPAN est une archive de modules Perl. Comme CPAN, JSAN propose un espace de nommage hiérarchique et la gestion des versions de modules. Ces modules sont inclus dans des scripts par JSAN.use('nom.de.module'); Comme CPAN, JSAN propose une infrastructure de tests unitaires.

Bon développement.

Liens

À vous !

Envoyez vos perles à <perles@mongueurs.net>, elles seront peut-être publiées dans un prochain numéro de Linux Magazine.