Data Injection Markup Language

Auteur : V.G. FREMAUX
E.I.S.T.I. / Cergy, France
Laboratoire de Recherche Appliquée
Nouvelles Technologies de l'Information et de la Communication

Version : 1.0 / Décembre 2004

0. Objet de ce document

Ce document a pour but d'expliquer le fonctionnement interne du processeur DIML.

1. Introduction

Le processeur DIML est un parseur récursif utilisant de façon très exhaustive les expressions régulières POSIX. Il est bâti sur un jeu de trois fonctions :

• le scanner : Cette fonction a pour but de séparer les instructions DIML (parsable) du reste du document (non parsable, #CDATA + HTML + contenus de script client).
• l'interpréteur : Cette fonction a pour but de reconnaitre et de traiter l'instruction DIML unitaire, pour en calculer une contrepartie dans le document.
• le translateur : Cette fonction a pour but de translater une entrée symbolique résolue par l'interpréteur en une valeur. Le translateur peut également procéder à une mise en forme de la valeur après translation.

Le processeur proprement dit est une fonction de transformation travaillant sur un tampon de code source. L'obtention du fichier est donc antérieure à l'invocation du processeur. Dans les applications CGI, c'est le script lanceur (ESSI.pl) qui se charge d'ouvrir le fchier source.

Le processeur procède par étapes. Le détail de ces étapes de traitement est :

1. - INITIALISATION DES STRUCTURES UTILITAIRES ET VARIABLES GLOBALES
2. - EXTRACTION DES PARAMETRES CGI (si appelé en mode standalone par redirection d'action sur type mime x-application/x-essi-parsed)
3. - EXTRACTION DES TEMPLATES
4. - VERIFICATION DE STRUCTURE CONDITIONNELLE DU CORPS PRINCIPAL
5. - PREPARATION DES TEMPLATES (en-têtes, précompilation)
6. - RESOLUTION DU CORPS PRINCIPAL
7. - RECOMPOSITION DE L'EN-TETE DE DOCUMENT
8. - FINALISATION
9. - NETTOYAGE FINAL

Cinq des étapes les plus importantes sont expliquées ci-après.

2. Première phase : le fichier d'entrée.

Le fichier d'entrée est un fichier d'extension .dim ou .diml ou tout autre fichier de type de contenu x-application/x-essi-parsed. Sa structure peut être variable, mais on reconnaît à l'usage deux types de fichiers DIML :

• Le "document dynamique DIML" : Il s'agit d'un fichier très proche d'un document HTML. Il en adopte la structure générale, mais peut contenir accessoirement des templates pour construire dynamiquement une partie de son contenu. Le contenu de ces templates est une séquence de source DIML, c'est à dire, une succession de code HTML littéral et d'instruction DIML.
  
• La "librairie de templates" : Ce type de fichier ne contient que des templates. Il est une collection de fragments rangés en librairie selon une certaine cohérence (celle que veut bien lui conférer l'auteur). Une telle librairie est en général utilisée via des instructions d'import ou des appels de templates distants. D'ailleurs, leur résolution directe ne donne qu'un document vide, à moins que des commentaires ne soient laissés dans le corps principal du fichier.
  

La première opération importante effectuée par le processeur est la séparation de la trame principale du document et des templates qui s'y trouvent répartis. Le fichier d'entrée est un source DIML tel que lu du système de fichiers local.

L'opération de séparation permet d'obtenir un tampon linéaire de code source DIML, contenant le "document", et des fragments réutilisables et appelables dans un catalogue de ressources. Ce catalogue est l'espace de données DIML qui constitue la réserve de symboles connus par la page en cours de construction.

Pendant la récolte des templates s'opère également une récolte de leur éventuelle en-tête. Les en-têtes (HEAD) de templates servent à adjoindre au template des éléments d'en-tête HTML qui doivent être capitalisés dans l'en-tête HTML finale, tels que des styles, des scripts, des x-liens ou des métas.

4. Troisième phase : La précompilation

La précompilation est une optimisation qui permet d'établir une valeur définitive pour certains templates dits "statiques". A l'origine identifié comme une optimisation possible, la pratiqaue montre que ces templates ne sont que très peu utilisés, ou demandent une inspection spécifique du code source des documents en vue de procéder à cette optimisation. Les templates déclarés STATIC sont résolus, avec la connaissance partielle de l'environnement DIML : Cette connaissance est réduite aux templates récoltés, ainsi qu'aux variables mises en place par les phases antérieures du processeur ou du lanceur, c'est-à-dire, peu de chose en fait (dans la grande majorité des cas, l'essentiel des données est en effet obtenu lors de la résolution principale du document).

Après précompilation, les templates statiques ne contiennent plus de balises DIML. Leur appel sera rapide et n'effectuera qu'une simple substitution de chaîne.

5. Quatrième phase : La résolution

La résolution est la phase la plus cruciale et la plus lourde. Elle crée en effet le véritable document de sortie en "exécutant" le corps principal de document.

La résolution est hautement récursive parce que :

• La résolution d'un symbole ou d'une instruction est stipulée fournir une contrepartie DIML, et donc peut à nouveau contenir des balises non terminales.
• Les attributs et paramêtres des instructions sont parfois reparsés, pour ajouter encore de la puissance paramétrique au langage lui-même.

La résolution commence par évaluer la séquence principale, c'est-à-dire, le corps de document obtenu après extraction des templates. Ce niveau d'évaluation est similaire à tous les niveaux d'évaluation plus imbriqués :

1. Les instructions DIML et les fragments intermédiaires de code HTML terminal sont isolés dans un tableau. Ce tableau contient alors alternativement des instructions et des "non-instructions" (potentiellement réduites à la chaîne vide)
2. Les non-instructions sont ignorées par le processeur.
3. Les instructions sont décodées et leur contrepartie est calculée, puis placée en remplacement du code d'instruction.
4. Le tampon final est réassemblé puis remis à l'appelant.

Une fois toutes les balises DIML éliminées, le document est finalisé en filtrant les lignes vides générées par les remplacements et en reconstituant l'en-tête de document à partir de l'en-tête HTML originale, additionnée de toutes les en-têtes collectées dans les templates.