Après cette accroche quelque peu racoleuse, je m’explique :
JsUnit est un outil permettant de tester ses fonctions écrit en JavaScript. C’est tout simplement l’équivalent Javascript de JUnit. J’ai programmé mes tests au fur et à mesure en utilisant Firefox, puis à la fin de la semaine, je me suis rappelé l’existence d’Internet Explorer. Au vu des résultats, je me suis dit que la compatibilité présumée de Prototype envers FF et IE allait prendre du plomb dans l’aile. Il m’a donc fallu chercher l’origine de ces bugs.

Première partie : des variations minimes mais suffisantes

Les lecteurs avisés me diront que je ne teste pas la même chose, puisque j’ai 56 tests sur FireFox et 59 sur IE. C’est parce que JUnit sous IE s’amuse à évaluer des fonctions telles que celle-ci :

Avec Prototype, j’ai étendu l’objet Element pour y mettre la fonction getParentElement() qui renvoit le paragraph le plus proche de l’élément.
J’utilise donc la ligne : parent=element.up(".paragraph");

IE me renvoit une erreur "Not Implemented". Je pensais qu’il y avait une erreur avec l’implémentation de up() par Prototype mais en fait mÔnsieur Internet Explorer n’accepte pas le nom de variable parent. Essayez parent="" ou parent="java" et vous aurez une erreur "Not Implemented".

En déclarant la variable var parent="", tout va mieux.

Il faut ensuite savoir que lorsque vous écriver du code HTML, les moteurs de Firefox et IE les réécrivent derrière vous. Cela se voit en utilisant alert(monElement.innerHTML). J’ai repéré deux problèmes notables :

Internet Explorer réécrit au lieu de . Les guillemets de l’attribut value disparait : ce qui fait que value n’est d’ailleurs plus un attribut au sens xml. Assez génant pour les tests unitaires tels que celui-ci :
assertTrue (divControllers.innerHTML.include(‘ value="I" ‘));

Internet Explorer réécrit ses balises en majuscules. InnerHTML renvoit H3 au lieu de h3. Il faut donc réécrire les tests :
assertTrue(divForm.innerHTML.toLowerCase().include(‘h3′));
au lieu de :
assertTrue(divForm.innerHTML.include(‘h3′));

Deuxième partie : Le XML avec Prototype

Dans mes tests unitaires, j’utilise une String :

Et je teste ma fonction sensée recevoir transport.responseText.

Une fonction utilisant transport.responseText est à priori plus facile à tester qu’une autre utilisant transport.responseXML.

result.select("firstname")[0].innerHTML fonctionne très bien sous FireFox et me renvoit « Nicolas ». Mais sous IE, impossible de parser un élément non inscrit dans le document ! Prototype fonctionne bien, mais considère, sous IE, result comme une string, et pas comme un ensemble d’élément organisés en arbre. Il est donc nécessaire de passer par responseXML et d’ignorer ici les avantages de Prototype.

Le test unitaire de la fonction traitant le résultat devient plus compliqué : le Mock object n’est plus une String mais un document. Si vous avez une petite fonction fiable transformant mon String en document XML, je suis preneur.

Finalement, on y arrive.

Edupassion.com fournira un éditeur de cours online spécialement concu pour les besoins d’un prof. Avec notamment une numérotation des paragraphes de type GrandX, PetitX, et Lettre.
Le but du jeu est donc de traduire la balise XML <paragraph depth="GrandX" number="II">value</paragraph > en <h2>II) value</h2> pour le XHTML, ou <paragraph depth="Lettre" number="c">value</paragraph> en <h4>c)value</h4>

XSLT a pour objectif de transformer le Modèle (fichier XML) en Vue (fichier XHTML), et il eut été logique qu’XSLT transformasse aussi les nombres des paragraphes en caractères adaptés comme "II", ou "c". Cette opération purement fonctionnelle est cependant plus simple et surtout plus propre à la relecture en utilisant Java.

Pour résoudre le problème, la première idée qui vient à l’esprit est de le traiter cas par cas :

<xsl:template match="paragraph">
<xsl:choose>
<xsl:when test="./@depth=’GrandX’ ">
<h2>
<xsl:value-of select"./@number"/>)<xsl:value-of select"."/>
</h2>
</xsl:when>

<xsl:when test="./@depth=’PetitX’ ">
<h2>
<xsl:value-of select"./@number"/>)<xsl:value-of select"."/>
</h2>
</xsl:when>

<xsl:when test="./@depth=’Lettre’ ">
<h2>
<xsl:value-of select"./@number"/>)<xsl:value-of select"."/>
</h2>
</xsl:when>

</xsl:choose>
</xsl:template>

Ca marche, mais dès que la programmation sera plus complexe (séparation entre le titre et le corps du paragraphe, ou boutons de controle), alors le corps de chaque choix se remplira, ce qui n’est pas bien beau. On pourra utiliser <xsl:apply-templates/>, mais là encore, l’imbrication multiples de ces balises n’est pas conseillée si ce code doit être lu par des collègues non expert en XSLT.

Comme la balise choisie est variable, nous allons tout logiquement utiliser une variable, et créer un element dynamiquement.

<xsl:template match="paragraph">

<xsl:variable name="baliseVar">
<xsl:choose>

<xsl:when test="./@depth=’GrandX’ ">h2</xsl:when>
<xsl:when test="./@depth=’PetitX’ ">h3</xsl:when>
<xsl:when test="./@depth=’Lettre’ ">h4</xsl:when>
<xsl:otherwise>h4</xsl:otherwise>

</xsl:choose>
</xsl:variable>

<xsl:element name="{$baliseVar}">
<xsl:value-of select="./@number"/>)
<xsl:value-of select"."/>
</xsl:element>
</xsl:template>

On ne gagne pas immédiatement en nombre de lignes, mais beaucoup en clarté, car les deux problèmes sont clairement disjoints. Attention toutefois à l’utilisation des accolades dans <xsl:element name="{$baliseVar}"> , car contrairement au PHP, "$baliseVar" ne sera pas traité par le processeur XSLT comme une variable, mais comme un texte normal.

L’utilisation des variables en XSLT est très efficace pour se sortir des sentiers tortueux d’XPATH. Mais XSLT a ses limites, et je conseille fortement de faire les opérations les plus complexes avec un langage comme Java & JDOM.