Gus06 : Framework de développement Java

Accueil Documentation Base de connaissances Article : Gus Script : dépendances entre scripts
Article rédigé par gus le 12/02/2016 pour le projet Moteur de script Gus


Les balises include et extends introduisent des dépendances entre les scripts gus, exactement de la même manière qu'il existe des dépendances entre les entités, dans la programmation gus06. La référence au script appelé est ainsi passé à la balise sous la forme d'un objet File ou d'une chaîne de caractères indiquant le chemin du fichier, lequel peut être absolu ou relatif.

Pour rendre ces dépendances paramètrables, on aura recours à l'objet de traitement file_mapper (stocké dans le contexte), qui permet d'instaurer un mapping entre fichiers au sein d'un répertoire racine. Ce mécanisme n'est pas trivial, aussi nous allons tenter de l'aborder sans bruler les étapes... undecided

 

Premier exemple simple

Dans un répertoire root, nous allons créer les 4 scripts suivants :

  • init.gus
  • main.gus
  • script1.gus
  • script2.gus

Les scripts script1.gus et script2.gus contiendront du texte pour indiquer qu'ils sont appelés par le script principal :

script1 has been called

script2 has been called

Le script main.gus se chargera d'appeler script1.gus et script2.gus d'une manière nouvelle, comme vous pouvez le constater:

Attention : si vous essayez d'exécuter ce script directement, il plantera !

Le script init.gus se chargera d'appeler main.gus après avoir préalablement configuré le fameux objet file_mapper :

En fait, init.gus se contente d'indiquer à file_mapper qu'il doit utiliser comme répertoire root, le répertoire parent du script actuel, et comme mapping la map vide qu'il vient de créer.

A première vue, les balises include du script main.gus fonctionnent de manière tout à fait classique, et on aurait pu se contenter d'écrire :

{include 'script1.gus'}

{include 'script2.gus'}

Sauf que l'usage de l'expression script._mapper.'\script1.gus' à la place de 'script1.gus' rend la balise correspondante dépendante du mapping géré par notre objet file_mapper !! Dans notre deuxième exemple, nous allons introduire du mapping pour vous permettre de comprendre ce qu'il en retourne.

 

Deuxième exemple : ajout de mapping

Nous allons ajouter un 5ème script qui jouera le rôle d'une variante de script1.gus : script1a.gus

Ensuite, nous modifions puis exécutons le script init.gus comme ceci :

Nous avons spécifié une règle de mapping entre scripts qui impose que lorsque le script /main.gus appelle le script /script1.gus, c'est sa variante /script1a.gus qui est appelée à la place.

'/main.gus@/script1.gus' = '/script1a.gus'

Et effectivement, dans le console, nous constatons que c'est bien le script script1a.gus qui se fait entendre depuis le script main.gus.

Nous noterons que le chemin '/script1a.gus' indique un fichier qui se trouve dans le répertoire racine de file_mapper. Si ce fichier s'était trouvé dans un sous-répertoire dir1, le chemin aurait été : '/dir1/script1a.gus'

 

Les identifiants de script

Lorsque le paramètre "main" est initialisée dans l'objet file_mapper, les fichiers dont le nom correspond à sa valeur String ('script.gus' dans notre exemple) sont identifiés non plus par leur chemin relatif mais par "un identifiant de script". Cet identifiant nettement plus concis correspond au chemin relatif du répertoire du fichier, dans lequel chaque séparateur a été remplacé par un point.

Dans cette nouvelle version du script init.gus, en plus de l'initialisation du "main" dans le file_mapper, nous avons ajouté une deuxième règle de mapping qui impose que lorsque le script /main.gus appelle le script /script2.gus, c'est le script identifié par 'gus.tools.script1' qui est appelée à la place.

Vous aurez remarqué que seul le caractère slash / placé ou non au début permet de différencier les deux types d'identification.

  • Si vous écrivez 'gus.tools.script1', vous obtiendrez le fichier /gus/tools/script1/script.gus
  • Mais si vous écrivez '/gus.tools.script1', vous obtiendrez le fichier /gus.tools.script1

Par ailleurs, il va de soi que ce système de mapping s'applique à n'importe quel fichier sans aucune restriction, et pas seulement aux fichiers de script.

 

Granularité des règles de mapping

Jusqu'à présent, nous n'avons utiliser que des règles de mapping spécifiques, faisant intervenir un fichier appelant et un fichier appelé, de la manière suivante : <id-appelant>@<id-appelé> = <id-cible>

Nous allons voir qu'il est possible de spécifier des règles plus générales qui agissent sur plusieurs fichiers appelants (voir tous les fichiers appelants).

Dans ce nouvel exemple, nous avons définis 3 scripts commençant par gus.page, et 2 scripts commençant par gus.tools. Chacun de ces 5 scripts se contente de se présenter puis d'appeler le script identifié par 'lib1.a'. Quant au script main.gus, il appelle chacun des 5 scripts précédents. Voici ce que produit cette configuration lorsqu'aucune règle de mapping n'est définie :

 

Commençons par ajouter une première règle ( gus.page.login = gus.page.logout ) qui a pour effet de remplacer gus.page.login par gus.page.logout partout ou celle-ci est appelée. Résultat : le script gus.page.logout est appelé 2 fois de suite par main.gus

 

Pour finir, ajoutons la règle ( gus.page@lib1.a = lib1.b ) qui a pour effet de remplacer lib1.a par lib1.b uniquement lorsque l'identifiant du script appelant commence par 'gus.page...'. Nous remarquons que 3 scripts sont impactés par cette nouvelle règle.

On peut donc ajouter des règles de mapping avec divers niveaux de granularité. Lorsque l'objet file_mapper doit résoudre un mapping à partir d'un fichier appelant et d'un identifiant, celui-ci recherche la règle là plus spécifique qu'il peut appliquer, et en dernier recours, il renvoie le fichier correspondant à l'identifiant transmis. Cet identifiant joue ainsi le rôle d'identifiant par défaut utilisé lorsqu'aucune règle de mapping n'est disponible.

 

Les opérateurs _mapped et _mapper

L'opérateur _mapped permet de vérifier si un fichier est contenu dans le répertoire root défini par l'objet file_mapper, et donc s'il peut être ou non mappé. L'opérateur _mapper (déjà utilisé précédemment) permet quant à lui d'appliquer un mapping à partir d'un fichier particulier en passant ensuite la clé de correspondance. Plus précisément, l'opérateur _mapper renvoie un objet de transformation T à partir d'un File, lequel va vous permettre d'obtenir des objets File à partir de String. Nous noterons par ailleurs que cet opérateur s'utilise le plus souvent sur le fichier du script courant (la variable script).

Dans l'exemple ci-dessous, nous disposons de 2 fichiers init.gus et main.gus dans un répertoire C:\GUS\root et nous exécutons le script init.gus qui définit la régle de mapping suivante : /main.gus@page.page.home=gus.page.home2

 

Les opérateurs _file_to_id et _id_to_file

Les opérateurs _file_to_id et _id_to_file permettent de convertir un fichier en identifiant de mapping et inversement.

 

Les balises include1 et extends1

Pour finir, il existe des balises qui permettent de simplifier l'écriture des includes et des extends avec du mapping de scripts : include1 et extends1. En effet, la balise include1 utilisée avec un identifiant ID produit le même effet que {include script._mapper.ID ... }. Et de même, la balise extends1 utilisée avec un identifiant ID produit le même effet que {extends script._mapper.ID ... }

Par la suite, nous serons amené à exploiter ces deux balises très souvent, particulièrement quand il s'agira de définir la structure d'un site web.