1.2 - Compilation de règles

Attention : Ce tutoriel est ancien, incomplet, et n'est pas mis à jour. Il ne contient pas toutes les nouveautés du système de template de Gecko 1.9 / Firefox 3.0 qui est largement simplifié et permet d'utiliser sqlite ou xml comme source de données. Aussi est-il préférable d'aller consulter la version anglaise sur developer.mozilla.org.

Un gabarit XUL est construit sur la base d'une série de règles. Chaque règle contient deux choses, un jeu d'instructions pour naviguer à travers un graphe RDF et du contenu XUL à générer. A partir d'un point donné, le constructeur de gabarit va évaluer les instructions de navigation pour chacune des règles et générera une série de données intermédiaires correspondant à ces règles. Le contenu correspondant sera ensuite généré. Le mécanisme est en fait plus compliqué, mais c'est l'idée générale.

Il existe deux syntaxes pour la déclaration des règles, la syntaxe simplifiée et la syntaxe étendue (ou complète). Comme son nom l'indique, la syntaxe simplifiée est plus simple mais est limitée dans le type de données qu'elle peut parcourir. Elle peut être utilisée pour parcourir un et un seul arc (ou flèche) dans le graphe RDF. La syntaxe étendue permet de naviguer n'importe où dans le graphe. La syntaxe simplifiée sera presque toujours utilisée pour parcourir une série d'enfants d'un conteneur RDF tel qu'un Seq. Un élément Seq RDF est un conteneur dont les enfants sont disposés dans un ordre spécifique. Le gabarit générera ces résultats dans cet ordre.

La syntaxe simplifiée est une sous version de la syntaxe étendue, et en tant que telle, elle peut être réécrite en utilisant la syntaxe étendue. En fait, le constructeur de gabarit se charge de convertir la règle simplifiée dans une syntaxe étendue avant de l'utiliser. Quelque soit la syntaxe que vous préférez, vous devez utiliser celle qui vous semble la plus naturelle. Notez toutefois que la syntaxe simplifiée utilise une légère optimisation lors de l'emploi de plusieurs règles contrairement à la syntaxe étendue. Nous verrons cela dans le détail plus tard.

Chaque règle est déclarée en utilisant la balise rule que vous placerez directement à l'intérieur de l'élément template. Vous pouvez avoir autant de règles que vous le désirez ou une seule. Lors de l'emploi de la syntaxe simplifiée, vous pouvez omettre l'élément rule puisque vous ne pouvez en utiliser qu'une seule. La syntaxe étendue nécessite toutefois toujours un élément rule.

Voici le squelette externe de la syntaxe du gabarit à ce stade :

<vbox datasources="http://www.xulplanet.com/ds/sample.rdf"
         ref="http://www.xulplanet.com/rdf/A" flex="1">
  <template>
    <rule>
      -- Le contenu de la règle se place ici --
    </rule>
    <rule>
      -- Le contenu de la règle se place ici --
    </rule>
  </template>
</vbox>

Lorsque le constructeur de gabarit débute son processus, et après le chargement de la source de données, il commence à compiler les règles. Cette étape implique de travailler à travers les règles et de les lancer des processus internes. Ainsi, la modification dynamique des éléments rule n'aura aucun effet. Toutefois, la reconstruction du gabarit (en utilisant la méthode builder.rebuild) recompilera les règles et réappliquera de nouveau le gabarit. Cela signifie que vous pouvez modifier les règles grâce aux méthodes du DOM, reconstruire le gabarit, et obtenir des résultats différents.

Une fois que le constructeur de gabarits a compilé les règles, l'analyse des règles et la génération du contenu peut commencer. Le constructeur de gabarits génère le contenu de manière paresseuse, c'est-à-dire qu'il ne réalise un traitement que lorsque c'est nécessaire, et qu'il ne continue que si c'est nécessaire. Considérons par exemple le cas suivant :

<vbox datasources="http://www.xulplanet.com/ds/sample.rdf"
         ref="http://www.xulplanet.com/rdf/A" hidden="true">
  <template>
    ...
  </template>
</vbox>

La vbox est masquée comme indiqué par l'attribut hidden. Comme tout le contenu pouvant être généré ne pourrait pas être affiché, le constructeur de gabarits ne fait rien, en repoussant le travail à plus tard. Si maintenant, vous affichez la vbox en mettant l'état false sur l'attribut hidden, le constructeur de gabarits sera appelé et le contenu généré.

Est-ce que cela signifie que les gabarits ne peuvent pas être utilisés dans des endroits cachés de l'interface utilisateur ? Non, vous pouvez toujours encore le faire. La modification de l'état hidden d'un élément n'est pas le seul moyen pour provoquer la génération du contenu. L'appel d'une API DOM qui nécessite de récupérer le contenu généré, va relancer le constructeur de gabarits. Par exemple, l'appel du code suivant sur la vbox masquée ci-dessus va mettre en route le constructeur de gabarits :

var length = vbox.childNodes.length;

Cette requête demandant le nombre d'enfants de la vbox va obliger le constructeur de gabarits à traiter les règles et à générer le contenu. Ensuite, le nombre correct peut être retourné.

Tout cela est transparent pour le développeur XUL. Le moment où le constructeur de gabarits commence la génération est déterminé automatiquement sans rien faire de spécial. Cependant, il y a deux cas ou le contenu n'est pas généré automatiquement : les menus et les items d'un arbre.

Le contenu à l'intérieur d'un menu n'est généré que quand le menu est ouvert. Ce fonctionnement est logique puisque l'utilisateur ne peut pas voir le contenu tant qu'il ne l'a pas ouvert. Toutefois, cela signifie aussi que l'utilisation de l'API DOM, telle que d'essayer de connaître le nombre de noeuds enfants comme ci-dessus, n'inclura pas les items générés avant que le menu ne soit ouvert. Il s'agit d'une distinction importante. Elle signifie que vous ne pouvez pas espérer obtenir les items du menu généré avant que celui-ci ne soit ouvert. Un principe semblable s'applique aux items enfants d'un arbre. Les branches filles ne sont générées qu'une fois que l'utilisateur appuie sur le symbole d'exploration (NdT : twisty) pour ouvrir le conteneur, ou qu'un script n'ouvre une ligne.

La génération paresseuse est pratique pour les menus et les arbres notamment lors de traitements récursifs. Il serait trop long de générer une sortie pour chaque item d'un arbre, même ceux qui ne sont pas affichés, donc le constructeur de gabarits évite donc de le faire.

Le constructeur de gabarits est même plus paresseux que cela. Si le contenu généré contient des éléments masqués, ces éléments enfants ne seront pas générés tant ce que n'est pas nécessaire. Quand il construit le contenu, le constructeur parcourt les noeuds de l'arbre, en ne copiant et en ne construisant que ce qui est nécessaire.