En termes d’ergonomie, il est souhaitable qu’une page HTML se charge le plus vite possible ou en tout cas que les composants graphiques qu’elle comporte soient manipulables dès que possible par l’utilisateur. Lorsqu’on utilise un framework javascript (et qu’on n’utilise pas la méthode du partage de code cf. dernier article), il faut charger le code correspondant. Sur la plupart des navigateurs actuels, l’interprétation du code javascript est bloquante vis-à-vis de l’interprétation du DOM. Autrement dit, si la page est en train de se charger, qu’elle rencontre une balise SCRIPT, l’HTML cesse d’être interprété pendant que le contenu de la balise SCRIPT (le code javascript) est exécuté.

Pour cette raison, il est préférable d’interpréter le code javascript à la fin de la page ou après le onload (le DOM étant totalement chargé à ce moment). Les seules choses qu’on peut paralléliser sont le déclenchement du chargement de fichier javascript en parallèle. Néanmoins, une fois que le fichier est récupéré sur le poste client, son interprétation devient bloquante à son tour.

Ainsi, si on déclenche le chargement dynamique d’un fichier javascript dans le head ; si l’interprétation de ce fichier prend une seconde et a lieu avant la fin de l’affichage de la page HTML, on a une interruption de une seconde dans l’affichage.

Pour une question d’ergonomie, on en serait donc réduit à ne faire aucun traitement javascript lors du chargement de la page (le chargement de la librairie et les traitements associés étant déclenchés par le onload). Cela aurait des conséquences en termes … d’ergonomie. En effet, l’utilisateur risque de voir une première version (purement HTML) de la page, puis des corrections visuelles réalisées par le javascript.

Prenons l’exemple d’une page comportant des éléments de formulaire HTML. Cette page est entièrement statique et c’est sur le poste client, en javascript, que l’on souhaite initialiser les valeurs des éléments de formulaire (dans la page HTML, les attributs value sont vides).

La solution la plus simple si on veut charger la librairie javascript dynamiquement est :

• Chargement de la page HTML (les value sont vides)
• Chargement asynchrone de la librairie (déclenchée en bas de la page ou dans le onload)
• Interprétation de la librairie (1 seconde)
• Modification des value des composants (uniquement lorsque la librairie est chargée)

Cette solution se traduit par une page HTML qui se charge très vite, mais les champs de saisie restent vides pendant plus d’une seconde. C’est donc tout à fait perceptible par l’utilisateur.

Introduction

Nous abordons dans cet article une méthode qui permet de concilier les avantages d’un chargement dynamique des librairies javascript tout en garantissant une certaine ergonomie d’utilisation.

Lors du chargement de la page, de façon à ce que l’utilisateur ne puisse pas percevoir les changements dus à javascript, on va les faire au fil de l’eau, dès que chaque nœud HTML sur lesquels on veut faire un changement apparaît.

Comment un nœud DOM prévient quand il est prêt

On souhaite donc pouvoir déclencher un traitement javascript sur un nœud DOM au plus tôt, c’est-à-dire dès que le nœud existe.

On sait que :

• les balises SCRIPT inline sont lues séquentiellement dans l’ordre du code source HTML.
• un script javascript a immédiatement accès au DOM du document, même si celui-ci est encore en court de chargement.

Par ailleurs, on souhaite être conforme aux préconisations de l’unobtrusive javascript : on veut séparer les balises HTML du code javascript. Il n’y aura donc pas de handler d’événement javascript déclaré dans une balise HTML.

Une solution la simple (et portable) est donc d’insérer une balise SCRIPT à proximité immédiate de la balise DOM sur laquelle on souhaite réaliser un traitement.

Pour une balise auto-fermante comme INPUT, par exemple :

<INPUT value="Smith" />

çà donne:

<INPUT value="Smith" />
<SCRIPT>…</SCRIPT>

On est certain que

Pour une balise classique, telle que :

<DIV>
<balise>…</balise>
<balise>…</balise>
</DIV>

on peut insèrer la balise SCRIPT immédiatement à l’intérieur de la balise HTML :

<DIV>
<SCRIPT>…</SCRIPT>
<balise>…</balise>
<balise>…</balise>
</DIV>

Dans ce cas, le script a accès à la balise englobante (d’identifiant c1) mais pas aux autres balises.

On peut aussi insérer la balise SCRIPT à la fin de la balise HTML :

<DIV>
<balise>…</balise>
<balise>…</balise>
<SCRIPT>…</SCRIPT>
</DIV>

Dans ce cas, le script a accès à la totalité des balises filles de la balise englobante.

On peut aussi (ce qui a priori ne change pas grand-chose par rapport à la solution précédente), utiliser la même approche que pour les balises auto-englobantes, c’est-à-dire insérer le script après :

<DIV>
<balise>…</balise>
<balise>…</balise>
</DIV>
<SCRIPT>…</SCRIPT>

Mise en œuvre

Nous allons exclure de cet article les solutions consistant à interroger le body du document pour déterminer quelle est la balise courante en cours de lecture. Nous prendrons donc une solution plus simple. Cette solution impose la contrainte d’associer un attribut id unique à chaque nœud HTML concerné. Même si la balise SCRIPT est située à l’intérieur de la balise en cours de lecture, on peut déjà accéder à cette balise.

Ainsi, la forme suivante est parfaitement fonctionnelle :

<DIV>
<SCRIPT>
// Récupération du noeud DOM
var domEl=this.document.getElementById("c1");
</SCRIPT>
<DIV>…</DIV>
<DIV>…</DIV>
</DIV>

domEl contient bien le nœud DOM correspondant à la balise DIV d’identifiant c1, même si la balise SCRIPT est située à l’intérieur du DIV et que les balises suivantes n’ont pas encore été évaluées. Bien entendu, si on fait domEl.childNodes, on ne récupère que la balise SCRIPT, pas les balises d’identifiants a et b.

Cette solution utilisant les identifiants est parfaitement adaptée à une génération côté serveur. Par exemple, en JSP, on pourrait avoir une balise

<skynet:input id="c1" name="${path}">

qui générerait le fragment complet suivant :

<INPUT id="c1" name="p1.prenom" />
<SCRIPT>
// Récupération du noeud DOM
var domEl=this.document.getElementById("c1");
… // Actions à faire sur le DOM
</SCRIPT>

Exemple

Cet exemple est disponible en ligne ici.

Ajout d’un handler d’événement

On veut séparer le code de la balise HTML et la déclaration de son handler d’événement javascript.

Il s’agit ici d’un bouton de type submit :

<INPUT value="Valider">

Si javascript n’est pas activé, le bouton a le comportement normal d’un bouton submit (envoi du formulaire sur le serveur).

Si javascript est activé, on associe au bouton un handler d’événement ouvrant un dialogue demandant si on veut vraiment soumettre le formulaire.

Le code résultant est le suivant :

<INPUT value="Test">
<SCRIPT>
// Récupération du dom element (le bouton)
var domEl=this.document.getElementById("button1");
/** Le handler du bouton
*  Il empêche la validation du formulaire (returnValue=false)
* @param ev {Event}
**/
function verifierValidation(ev){
if (confirm("Voulez vous vraiment valider ?")) {
ev.returnValue=true;
} else {
ev.returnValue=false;
}
};
// Ajout du handler d’événement
if (domEl.addEventListener) {  // Firefox, Google Chrome, Safari, Opera
domEl.addEventListener ("click", verifierValidation, false);
}
else {
if (domEl.attachEvent) {   // IE
domEl.attachEvent ("onclick", verifierValidation);
}
}
</SCRIPT>

Il est facile d’utiliser ce mécanisme pour que les handlers d’événements ne soient plus déclarés en tant qu’attributs HTML (comme onclick par exemple) mais dans un code javascript séparé. En faisant cette déclaration immédiatement, on s’assure que certains comportements javascript seront déjà actifs avant le chargement de la librairie du framework. Dans notre exemple, l’utilisateur ne pourra pas cliquer sur le bouton « Valider » sans passer par la vérification javascript, même si la librairie n’a pas encore été chargée.

Ajouter un fragment HTML au DOM si javascript est activé

On veut générer un fragment HTML à attacher au nœud DOM existant.

On applique la première solution à la génération d’un icône de calendrier permettant de lancer une pop-up de saisie des dates.

Si javascript est désactivé, seul le champ de saisie textuel est présent.

<INPUT type="text" value="">
<SCRIPT>
var domEl=this.document.getElementById("calendar1");
domEl.insertAdjacentHTML("afterEnd",

"<IMG src='./Agenda-Icon.gif' onclick='launchCalendar()' />");
</SCRIPT>

Noter qu’il faut bien évidemment que la fonction launchCalendar soit définie à ce moment. Parce que sinon, si l’utilisateur clique immédiatement dessus, il y aura une erreur.

Cela implique qu’il faudra identifier et différencier :

• les traitements à réaliser AVANT le chargement de la librairie (leur code doit être défini avant leur utilisation, on peut par exemple les définir dans le head du document),
• les traitements standards (qui nécessitent le chargement de la librairie complète)

Autres utilisations

On peut multiplier à loisir les utilisations de cette approche.

Dans le cadre de l’unobtrusive javascript, on a vu l’ajout des events listeners ou l’insertion conditionnelle de fragments html, on pourrait aussi rendre visible ou changer l’état d’éléments HTML générés sur le serveur.

Cette approche permet aussi de profiler les temps d’interprétation du DOM : il suffit que chaque balise SCRIPT insérée fasse des mesures du temps.

De façon générale, cette approche permet de réaliser des modifications du code HTML de la page sans pour autant que l’utilisateur puisse les percevoir. Çà permet par exemple d’utiliser une page HTML complètement statique et de modifier au chargement les attributs value et l’état (disabled, readonly) de chaque composant. Cette solution ne fonctionne évidemment plus sans javascript (les composants graphiques n’ont pas la bonne value) mais elle peut être utilisée pour réutiliser la même page avec des valeurs différentes sans appel serveur (devient très intéressante en terme de performance : le serveur d’application se contentant de générer valeurs et états et pas la page HTML qui peut être gérée par un serveur web.

Constat

Cette approche permet de réaliser des modifications javascript sur la page en cours de chargement sans pour autant qu’on soit obligé d’avoir chargé avant la librairie javascript gérant les composants graphiques. Cette approche permet en effet d’afficher très rapidement le contenu de la page HTML (sans être retardé par des chargements de code javascript, ceux-ci peuvent par exemple avoir lieu au onload de la page). Cela permet de garantir à l’utilisateur qu’il a accès immédiatement (en cours de chargement) à certaines fonctionnalités ou tout du moins que les modifications réalisées par javascript ne sont pas visuellement perceptibles.

Bien sûr, l’interprétation de l’HTML de la page est légèrement plus lente (mais çà reste à peine perceptible tant que les traitements javascript réalisés sont simples – et que ceux-ci ne nécessitent pas à une évaluation longue de code javascript –).

Les composants semblent être correctement initialisés.

Plan de l’article

• Chargement du framework par chaque page
  • étape 1 : chargement synchrone du framework par chaque page
  • étape 2 : chargement asynchrone du framework par chaque page
• Partage du framework avec une page pop-up
  • Rappels (affichage d’une page en html et en javascript)
  • étape 3 : la fenêtre pop-up charge elle-même le framework
  • étape 4 : la fenêtre pop-up partage le framework
  • Algorithme final

Chargement du frameworkpour chaque page

Étape 1 : chargement synchrone du framework

Mise en œuvre

Dans cette étape, la première page de l’application, page1.html charge explicitement le framework. Le chargement du fichier skynetlib.js est fait inline via une balise SCRIPT :

<SCRIPT src="skynetlib.js"></SCRIPT>

La balise SCRIPT respecte l’ordonnancement, donc il suffit de lancer la méthode init après le chargement du fichier skynetlib.js :

<SCRIPT src="skynetlib.js"></SCRIPT>
<SCRIPT>
function init(){
// Création d’une instance de Probe et affectation à une variable
var a=new Skynet.tools.Probe(1337) ;
} ;
init() ;
</SCRIPT>

Mesures

Nos mesures sont faites en javascript. Les chiffres annoncés sont des moyennes.

Noter que l’interprétation du fichier skynetlib.js s’arrête à 1168ms, cette interprétation dure bien de l’ordre de la seconde.

Constat

La méthode init est lancée après chargement de skynetlib.js et ce chargement prend une seconde. La page ne peut donc utiliser le framework qu’après ce temps de chargement.

On voit que le onload de la page est aussi en attente du chargement du fichier javascript. C’est visible sur cette copie d’écran de firebug :

Étape 2 : chargement asynchrone du framework

Mise en œuvre

On sait (cf. par exemple les transparents « Even Faster Web Sites » de Steve Souders) qu’il vaut mieux charger les fichiers javascript en asynchrone qu’en inline.

Dans cette étape, on veut que la première page, page1.html charge dynamiquement le fichier javascript. C’est assez facile à faire, par exemple via le DOM par création d’une balise SCRIPT dans le HEAD :

function loadScript(filename){
var targetTag=document.getElementsByTagName("head")[0];
var nodeS=document.createElement("SCRIPT");
nodeS.src=filename;
targetTag.appendChild(nodeS);
}

Néanmoins, ce chargement dynamique ne permet pas de garantir l’ordre d’exécution des scripts. Ainsi même si l’appel de loadScript est effectué AVANT l’appel de la méthode init() ; on ne peut pas garantir que le code du framework aura été interprété avant cet appel.

La méthode init() échoue donc puisqu’au moment où elle est appelée, elle ne peut pas accéder au code du framework (la variable Skynet).

On pourra se référer aux transparents de Steve Souders pour les différents moyens d’ordonnancer des scripts chargés dynamiquement. En ce qui me concerne, j’ai directement pris la librairie EFWS qu’il utilise dans son livre « Even faster Web Sites ».

Après l’initialisation de cette librairie (150 lignes en mode non minifié), il suffit de faire

EFWS.Script.loadScripts(["skynetlib.js"], init);

pour que le fichier skynetlib.js soit chargé dynamiquement puis que la méthode init soit appelée.

Attention, ce chargement dynamique garantit que la méthode init est appelée après que le chargement du fichier skynetlib.js,. Il n’y a par contre aucune garantie rien vis-à-vis de l’exécution du onload de la page (qui peut avoir lieu avant ou après).

Mesures

Le chargement du fichier skynetlib commence à 209ms (donc un peu plus tard que le chargement par balise <SCRIPT> de l’étape précédente) et s’arrête à 1221ms.

Constat

L’utilisation d’un chargement dynamique se traduit dans notre exemple par un léger surcoût (l’évaluation de la fonction init commence à 1266ms> à la place de 1221ms). Il est clair cependant que la page d’exemple n’est pas significative : elle ne comporte pratiquement pas de balises HTML, or le chargement dynamique est surtout intéressant parce qu’il ne bloque pas l’évaluation de la page. On voit néanmoins que le onload lors d’un chargement asynchrone :

est lancé plus d’une seconde (1280 – 107) avant celui de la solution synchrone (étape 1).

Partage du framework avec une page pop-up

Nous allons maintenant comparer le temps de chargement d’une fenêtre si au lieu d’être ouverte directement par son url, elle est ouverte en javascript par une page parente.

Rappels

Affichage d’une page en HTML

En html, il suffit d’utiliser un hyperlien pour afficher une page.

Si on ne précise pas l’attribut target, la page courante est remplacée par la page cible :

<A href="Page1.html">Page1.html</A>

Si on précise l’attribut target à la valeur _blank, on ouvre une nouvelle fenêtre. On peut aussi préciser comme target le name d’une frame ou d’une window existante.

<A href="Page1.html" target="_blank">Page1.html</A>

Affichage d’une page en javascript

Il existe plusieurs méthodes en javascript pour afficher une page dans fenêtre.

La première méthode est d’utiliser document.location= »pageCible.html » qui remplace la page courante par pageCible.html.

La seconde méthode utilise window.open. Cette méthode est plus puissante : elle permet d’ouvrir d’autres fenêtres (et pas seulement de remplacer le contenu de la fenêtre courante).

La méthode window.open a la syntaxe suivante :

window.open(url, windowName, windowFeatures)

• url est l’url de la page à ouvrir,
• windowName est le nom de la fenêtre (ce nom peut être utilisé pour rouvrir une nouvelle page dans la même fenêtre)
• windowFeatures, une chaîne avec différentes propriétés que l’on peut donner à la nouvelle fenêtre.

Cela donne par exemple :

window.open("eventEditionPage.html","Event editor",

"location=1,status=0,scrollbars=1, width=100,height=100")

Sur Chrome comme Firefox, si on veut ouvrir la nouvelle page dans une fenêtre qui lui est propre, il suffit de mettre une chaîne non vide dans windowFeatures, sinon, la fenêtre s’ouvre dans un onglet du navigateur.

Si l’on souhaite remplacer la fenêtre courante, il suffit d’utiliser comme windowName le nom de la fenêtre courante. On se retrouve alors avec un comportement identique à l’affectation de document.location.

Cas particulier : le chargement dans la même fenêtre

Il est possible de réutiliser la même fenêtre pour plusieurs fenêtres. soit par balise A avec pour target _self, soit par affectation de document.location, soit par l’utilisation de window.open en précisant pour windowName le même nom de fenêtre que pour la première page.

Même dans ce cas où l’on réutilise la même fenêtre, par exemple si la page page1.html charge la page un page2.html, la page page2.html possède toujours un window.opener. Par contre, on a window.opener==window, et page1.html est inaccessible. Il est donc impossible de récupérer les variables initialisées dans page1.html. Dans ce cas, il est obligatoire de charger skynetlib.js dans page2.html. La seule présence d’un window.opener ne suffit donc pas à garantir que le framework est présent dans ce window.opener.

Autrement dit, on ne peut pas partager un code javascript situé dans la même fenêtre et chargé par une page que la page courante a remplacé.

Mise en oeuvre

Dans la suite de l’exemple, nous introduisons une page master1.html. Cette page charge elle-même le fichier skynetlib.js (en synchrone via une balise SCRIPT).

C’est master1.html qui ouvre la fenêtre pop-up par un appel javascript tel que :

window.open("mapage.html")

Étape 3 : la fenêtre pop-up charge le framework

Mise en œuvre

La page master1.html lance la page page1-frm.html en tant que fenêtre pop-up. La page1-frm fait elle-même un chargement synchrone du fichier skynetlib.js.

Mesures

Au niveau de page1-frm.html (les temps sont mesurés à partir du chargement de cette page) :

Noter que comme on peut s’y attendre l’utilisation de la méthode de chargement dynamique du framework (avec la page1-dyn.html) ne change que la date de d’événement onload qui se déclenche vers 42ms (comme dans l’étape 2).

Constat

Avec cette méthode, on a chargé deux fois le fichier skynetlib.js : une fois dans la page master1.html, une autre fois dans la page page1-frm.html.

Autrement dit, à chaque fois qu’on ouvre une fenêtre pop-up, on est obligé de recharger le framework dans cette fenêtre pop-up.

Ainsi, si vous avez un composant comme un calendrier et que vous utilisez une page pop-up pour créer ou modifier un événement de calendrier, vous êtes obligés de recharger le framework dans cette fenêtre pop-up. Si vous avez une vue détail de cet page pop-up, par exemple pour pouvoir choisir le fuseau horaire, vous êtes là-aussi obligés de charger le framework pour la vue détail.

Étape 4 : window.open avec partage de framework

On va maintenant chercher à ne charger qu’une seule fois le fichier skynetlib.js. la page master1.html ouvre maintenant page1.html en tant que fenêtre pop-up.

Mise en œuvre

Quand on ouvre une fenêtre via javascript (via document.location ou via window.open), elle comporte une variable window.opener qui pointe sur la window qui l’a ouverte. Dans notre cas, le window.opener de page1.html pointe sur la window de master1.html. Or master1.html a chargé le fichier skynetlib.js.

Il suffit donc de faire Skynet=window.opener.Skynet dans page1.html pour que le framework soit accessible directement, sans aucune modification du code utilisant le framework.

Noter que cela nécessite d’être sur un site web, pour des questions de sécurité (liées au cross scripting), il n’est pas possible d’utiliser le protocole file://.

Ainsi, après cette affectation, dans page2.html, le code de la fonction init :

var a=new Skynet.tools.Probe(1337) ;

fonctionne parfaitement sans chargement du fichier skynetlib.js.

Remarque

Noter que si on ferme la fenêtre parente (alors que la fenêtre pop-up est toujours ouverte), la variable capturée dans la fenêtre parente, ainsi que tout le code afférant reste valide. Ainsi, le framework est toujours accessible via la variable Skynet alors même que la page qui a chargé ce fichier a disparu.

Mesures

Les temps sont inchangés au niveau de master1.html.

Au niveau de page1.html (les temps sont mesurés à partir du chargement de cette page) :

Constat

Autrement dit, les gains sont très importants au niveau de la fenêtre pop-up qui n’a plus à charger le fichier skynetlib.js ce qu’on peut vérifier dans la vue réseau de firebug :

Dans l’étape précédente, la méthode init était appelée au bout de 1100ms, en partageant le framework, elle est appelée au bout de 8ms.

La méthode init de la fenêtre pop-up peut être exécutée très rapidement : la fenêtre pop-up peut utiliser pratiquement immédiatement le code du framework chargé dans la fenêtre parente master1.html.

Algorithme final

Principe

On peut maintenant récupérer le framework sans le charger de nouveau dans page1.html. Cependant, pour le moment, la page1.html ne peut plus être chargée directement. Il faut obligatoirement qu’elle ait été chargée via un window.open. et que la fenêtre qui a déclenché cette ouverture ait elle-même chargé le framework. Il faut corriger ce défaut.

On peut facilement détecter si une fenêtre a été ouverte via un window.open ou un document.location, il suffit de regarder si elle possède un window.opener et si window.opener != window (cf. le paragraphe sur le chargement dans la même fenêtre)

L’idée est donc de :

1)      Détecter si la fenêtre a été ouverte directement

2)      Si la fenêtre a été ouverte directement, ou a remplacé la page qui l’a ouverte, déclencher un chargement dynamique du framework

Mise en oeuvre

L’algorithme final reste assez simple :

• soit la fenêtre courante a été ouverte via une fenêtre parente et on récupère la variable Skynet via window.opener.Skynet
• soit on charge dynamiquement le fichier skynetlib.js qui initialise (localement) la variable Skynet.

Les exemples en ligne sont disponibles ici

Le fichier compressé comprenant toutes les pages de l’exemple sont ici

Conclusion

Nos mesures montrent que lorsqu’on veut utiliser une fenêtre pop-up, il est très intéressant de partager le code du framework.

C’est d’autant plus important que généralement les fenêtres pop-up sont des fenêtres très utilisées : elles servent par exemple à éditer les objets manipulés par la fenêtre principale. Par exemple on peut avoir une page principale comportant un calendrier et une page pop-up qui permet d’éditer ces événements. Il est clair que le chargement de la page pop-up doit être extrêmement rapide. Dans notre exemple, nous avons vu qu’en partageant le framework, on peut utiliser son code au bout de quelques millisecondes (au lieu d’attendre que son code soit chargé puis évalué).

En plus, nous n’avons compté dans les mesures effectuées que le temps d’interprétation du fichier javascript. Nous n’avons pas tenu compte du temps nécessaire à la récupération des fichiers eux-mêmes. Le gain issu du partage du framework est donc encore supérieur. Sans ce partage, l’utilisateur est donc confronté à un délai d’attente plus important.

Quand on réalise une application web, il est fondamental d’optimiser les temps de chargement de chacune des pages. C’est un impératif en termes d’ergonomie. Cette série d’articles étudie le partage de code javascript inter-fenêtres ou comment éviter de recharger un framework javascript qui est utilisé dans chacune des pages de l’application web.

Les contraintes sont les suivantes :

• On doit pouvoir accéder directement à chaque page html de l’application via son url (on ne peut pas facilement empêcher l’utilisation des menus ou des raccourcis des navigateurs ; de plus, en termes d’ergonomie, il est conseillé que toute fonctionnalité d’une application possède sa propre url).
• L’application peut ouvrir ses pages html dans d’autres fenêtres via des appels javascript ou intégrer ces pages dans des balises IFRAME
• Dans chacun de ces cas, le code qui dans chaque page utilise le framework doit rester identique. Il est par exemple exclus de se préoccuper de la façon dont la page a été ouverte : directement, sous forme d’un dialogue modal simulé avec des balises DIV ou sous forme d’un IFRAME.

Dans les exemples, nous étudierons des pages statiques html mais elles pourraient être générées dynamiquement (jsp ou php par exemple), sans que çà change quoi que ce soit à l’approche utilisée.

Plan de la série d’articles

Un premier article étudiera le cas de l’ouverture de fenêtres pop-up et comment il est possible de partager le code chargé par la fenêtre qui les a ouvertes.

Un second article étudiera le cas des fenêtres incluses dans un IFRAME et comment partager le code chargé par la fenêtre parente.

Un troisième article étudiera comment optimiser cette utilisation des IFRAME pour partager le code

Un quatrième article fera le point sur les contraintes dues à ce partage de code : par exemple au niveau de la conception du code lui-même, en termes de sécurité (cross-scripting), d’ergonomie, de robustesse.

L’exemple

D’un point de vue pratique, nous allons simuler l’utilisation d’un framework en utilisant un unique fichier javascript intitulé skynetlib.js. Ce fichier contient une boucle d’attente d’1 seconde pour simuler le temps d’interprétation d’un « gros » framework.

Ce temps d’1 seconde n’est absolument pas délirant. Il est courant d’avoir des frameworks du marché, qui ayant fait le choix d’utiliser un fichier javascript unique (rassemblant tous les composants) ont un temps de chargement de cet ordre (voir pire) et qui peuvent aller jusqu’à retarder l’événement onload de 5 à 6 secondes même sur une machine décente. On peut voir ce mécanisme dans cette copie d’écran de firebug où le onload (trait rouge) est très tardif.

Chronologie du chargement d'un gros framework

Le framework de l’exemple est sensé être conforme au design pattern « module » et l’ensemble de son code est donc accessible sous forme d’une variable globale. Dans les exemples suivants, cette variable, qui sert aussi d’espace de nommage, sera intitulée Skynet. Ce framework d’exemple comporte un constructeur appelé Skynet.tools.Probe.

Une fois le code du framework chargé, chaque page de l’application lance une méthode d’initialisation qui lui est propre (dans notre exemple, elle s’appelera init). Voilà par exemple une fonction init qui réalise l’instanciation du constructeur Probe définit par le framework :

function init(){
// Création d’une instance de Probe et affectation à une variable
var a=new Skynet.tools.Probe(1337) ;
}