Organisation des fichiers

Le DIML apparaît rapidement comme un SSI (Server Side Include) étendu, c'est à dire, comme une manière de construire du Web par inclusion de morceaux de HTML. Le SSI tel qu'implémenté dans les serveurs Web posait cependant un problème majeur : seule l'inclusion du fichier complet pouvait se faire.

Pour un webmaster faisant largement appel à la capitalisation de code, un site géré en SSI voit le nombre de ses fichiers augmenter en proportions considérables. La gestion de tous ces petits fichiers d'inclusion devient vite fastidieuse.

L'une des toutes premières motivations du DIML a été de pouvoir rassembler dans un seul fichier plusieurs "granules" de HTML indépendants qui auraient des fonctions proches. C'est la base de la notion de "templates", non pas pris au sens de "modèle" mais au sens de "portion".

Le fichier standard "globals.dim"

La factorisation de code et de valeurs fait apparaître certaines valeurs comme étant d'utilité permanente à travers le site. Ces variables ou morceaux de HTML récurrents peuvent être rassemblés dans un fichier unique, dont l'importation devient un élément de la méthodologie de construction de site. Ce fichier est appelé "globals.dim" et est une banque de templates généraux utiles dans toutes les pages (ou suffisamment de pages du site pour justifier leur globalisation).

Appel

Il sera courant de trouver en première ligne d'un fichier la commande DIML suivante :

<%import file="chemin_relatif/globals.dim#*" %>

Cette instruction charge l'ensemble des templates contenus dans le fichier globals.dim désigné en mémoire du processeur. Le chemin d'accès doit être un chemin relatif par rapport à la position courante du fichier DIML. Ceci permet :

• de chercher des templates globaux dans le site, notemment dans des super répertoires de chapitre ou de section.
• de différentier les templates globaux du site (globals.dim dans la racine absolue), de templates récurrents à une sous partie (globals.dim situé dans un répertoire).

Par exemple, si un fichier DIML était situé dans un sous réperoire de troisième niveau (section, partie, chapitre), on pourrait envisager le début suivant pour le source :

<%import file="globals.dim#*" %>
<%import file="../globals.dim#*" %>
<%import file="../../globals.dim#*" %>
<%import file="../../../globals.dim#*" %>

Cette en-tête chargerait alors les définitions communes pour chaque niveau. Dans la pratique, tous les niveaux hiérarchiques d'un site ne sont pas exploités pour cette globalisation. Mais ce principe est très utile.

Utilisation

L'utilisation du fichier "globals.dim" peut être très variée. Il existe cependant deux principales applications que la pratique plebiscite :

• La définition de routes globales d'accès aux ressources
• La définition d'écrans d'erreur ou de messages génériques.

Ce qui suit décrit la première de ces applications, directement liée à l'organisation des fichiers dans un site.

DIML et organisation des sites

Lors de la construction d'un site Web complexe, se pose toujours le problème de l'organisation des fichiers et des ressources. De cette organisation dépendra la facilité de maintenance du site, et sa "transmissibilité" à une autre équipe de développeurs.

Il existe de façon commune des ressources classables par genre et par usage :

• les fichiers documents, en HTML, DIML, PHP, ASP, etc...
• les fichiers images
• les scripts Javascript externes
• les feuilles de style CSS
• les scripts CGI
• les librairies de templates
• d'autres fichiers tels que animations, objets Flash, applets, etc.

Par ailleurs, l'observation des structure des sites Web nous amène à un constat de 3 principes d'organisations :

• le site plat
  Pas de structure visible, tous les fichiers sont au même niveau, les types de fichiers sont mélangés et les accès sont réduits à l'appel de fichier simple.
  
  
• le site mono-hiérarchique
  Une seule hiérarchie d'organisation thématique du contenu est visible. Chaque noeud de hiérarchie dispose de ses sous-répertoires locaux de ressources annexes.
  
  
• le site hiérarchique parallèle
  Chaque type de ressource est rangé dans une organisation hiérarchique similaire à celle des documents principaux.
  
  

Les trois types exposés ci-dessus sont bien entendus des caricatures théoriques. Mais chacune d'entre elle a été constatée sur des sites Web actifs, et correspond à des pratiques réelles ou des tactiques de certains éditeurs.

Le premier est évidemment le plus difficile à maintenir dès que le site prend un tant soit peu d'ampleur : les structures hiérarchiques de répertoires forment tout de même un principe de classement efficace ! Mais cela ne signifie pas qu'il n'est jamais exploité. Des petits sites, réalisés rapidement, ou des "sites-applications", parfaitement délimités dans leur usage sont parfois réalisés ainsi.

Les sites importants prennent naturellement une des deux dernières formes. La deuxième est celle d'un site majoritairement réalisé par des outils intégrés de développement. La troisième est plus rare. La majorité des sites observés a une structure combinée entre ces deux principes.

Le deuxième principe privilégie la notion de volumes par sous-ensemble fonctionnel. Ainsi, une partie "intranet" et ue partie "internet" peuvent être dissociées sous forme de deux volumes indépendants contenant chacun toutes les ressources pour fonctionner.

Le troisième principe privilégie une organisation en resources, dans laquelle les différentes ressources peuvent être dissociées en volumes dans lesquels une ressource est rapidement accessible par une "position" conventionnelle (celle qui correspond au document qui l'utilise).

Politique d'écriture des URL

Dans de tels sites, la politique d'écriture des URL admise est soit :

• relative, où la ressource à lier est accédée par un cheminement relativement à la position courante
• absolue, où la ressource est accédée par son URI absolue à partir d'une racine connue (DocumentRoot par exemple).

Les deux politiques ont des avantages opposés :

• les liaisons relatives ne doivent pas être remises en question lorsque le volume c'est-à-dire un des super-répertoires au dessus est déplacé. Les chemins relatifs restent valides, ce qui a rendu cette pratique la plus utilisées sur le Web. Elle correspond à une organisation de fichiers selon le second principe d'organisation. Par contre, ces liaisons figent la structure du contenu. Lorsqu'un sous-volume est déplacé, les liens "sortants" sont cassés (le chemin relatif ne tombe plus sur la ressoruce liée), ainsi que les liens entrant (la ressource déplacée n'est plus à l'endroit connu par l'appelant). Il faut effectuer une révision complète des liens du site.
• à l'opposé, les liaisons absolues restent valides quelle que soit la position du document. Il est possible alors de déplacer le volume ailleurs sans remttre en cause les liens "sortants". Les liens "entrants", quant à eux seront cassés, et demanderont un réajustement. Il faut effectuer une révision complète des liens des ressources en dehors du sous-volume déplacé.

Le DIML va permettre une gestion efficace et méthodique de ces problèmes d'organisation en minimisant le nombre d'interventions lorsqu'on reconsidère la structure d'un site.

Le principe consiste à identifier des volumes (soit par thème d'une mono-hiérarchie, soit par type de ressources) et de créer une variable DIML qui sera préfixée aux URL relatives.

L'exemple qui suit est l'écriture de l'appel à la première figure de cette même page. Ce site utilise le troisième principe d'organisation, et dispose d'un volume d'images indépendant. Une variable IMAGES_ROOT_URL est utilisée pour préfixer tous les appels aux images du site.

<IMG SRC="<%%IMAGES_ROOT_URL%%>tutorial/flat.jpg" VSPACE=10>

Le préfixe IMAGES_ROOT_URL est défini dans le fichier globals.dim situé à la racine du site.

On remarquera dans ce fichier un template nommé SITE_ROOT_URL et qui sert de préfixe aux liens portant vers cette même page :

<A HREF="<%%SITE_ROOT_URL%%>tutorial/parcours1/files_fr.dim" >

Par cette méthode, les liens "sortants" du volume ne cassent plus lorsque le volume est déplacé, et les liens "entrants" peuvent être rapidement reroutés en modifiant le préfixe du volume lui-même. Dans le cas de ce site, les documents sont organisés en un seul volume absolu, derrière le préfixe SITE_ROOT_URL.

Cette méthode d'organisation a tellement fait ses preuves en production que des variables "standardisables" sont apparues. Vous entrouverez les définitions dans le chapitre Les noms réservés de ce parcours.

De telles variables ont particulièrement leur place dans le (ou les) librairies de variables "globals.dim" répartis à travers la hiérarchie du site. Elles permettent alors des manipulations de volumes puissantes comme la répartition de charge ou le "mirorring".

L'exemple qui suit implémente un miroir sélectif pour les ressources images en fonction de la plage d'IP. Il consiste à définir un template IMAGES_ROOT_URL conditionnel :

<TEMPLATE ID="IMAGES_ROOT_URL" INLINE>
<%if (%ENV::HTTP_ACCEPT_LANGUAGE% =~ /^fr/) "http://fr.foo.com/images" 
%else "http://std.foo.com/images" %endif %>
</TEMPLATE>

Un tutorial approfondi des templates conditionnels est présenté plus loin dans ce parcours.

Résumé

Le DIML facilite grandement la gestion de sites complexes au niveau de l'organisation des ressources.

Le fichier "globals.dim" sert à disposer de variables générales valables dans tout les site.

L'utilisation de variables DIML peut préfixer les URL d'appel pour bénéficier des avantages de la politique d'adressage absolue et relative.

On peut organiser un site complexe en volumes de ressources, ou en grandes sections relocalisables.