Retrouvez cet article dans : Linux Magazine 77
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
Le site est donc consultable depuis quelques temps (quelques jours à l’heure où j’écris ces lignes) à l’URL : http://www.openjsan.org/.
Celui-ci est encore un peu dépeuplé, mais CPAN ne s’est pas construit en un jour. Gageons que le nombre de développeurs Javascript publiant leurs scripts ailleurs voudront ajouter à leur crédibilité en s’appuyant sur l’infrastructure de qualité mise en œuvre pour JSAN.
Car le but de ce site n’est pas seulement de centraliser les scripts et autres bibliothèques Javascript, il est surtout de permettre une intégration de toutes ces ressources entre elles et d’en vérifier la qualité, que ce soit par des tests ou par la documentation, bref, de reproduire le sérieux de CPAN. Mieux, dès le départ, JSAN, propose des fonctionnalités qui ne sont apparues que progressivement sur CPAN.
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, 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 de 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 d’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 :
[1] Le site du projet OpenJSAN :
http://www.openjsan.org/
[2] Listes de diffusion : (utilisateurs, développeurs, auteur de modules, testeurs, etc.)
http://www.openjsan.org/community/lists.html
[3] Michael G Schwern n’aime pas Javascript
http://schwern.hates-software.com/2005/04/08/7eae2d31.html
[4] JavaScript Tutorial for Programmers
http://www.wdvl.com/Authoring/JavaScript/Tutorial/
[5] Higher Order JavaScript
http://interglacial.com/hoj/
[6] Higher Order Perl
http://hop.perl.plover.com/
