Introduction à Xtext

La première ligne contient le texte :

hidden (WS, ML_COMMENT, SL_COMMENT)

Cela énumère les éléments de la grammaire qu'Xtext ne prendra pas en compte dans les analyses syntaxiques et sémantiques. Typiquement, les commentaires sur une ligne (SL_COMMENT) et sur plusieurs lignes (ML_COMMENT). De même les espaces et les retours chariot (WS) n'ont pas d'importance sémantique.

La règle SL_COMMENT a une importance toute particulière : en s'assurant de sa présence dans votre grammaire, vous débloquerez automatiquement la fonctionnalité Eclipse pour commenter/décommenter un bloc, grâce au raccourci Ctrl+Maj+C ou à un clic droit puis « Toggle Comment » dans l'éditeur.

Xtext définit aussi une manière générique de décrire un identifiant (de variable par exemple) grâce à la règle ID. Il propose aussi une définition pour les entiers (INT) et pour les chaînes de caractères (STRING). Tous ces éléments sont des éléments dits « terminaux ». Leur nom est systématiquement en majuscules et ils ne peuvent contenir d'affectation. Ce sont des valeurs brutes caractérisées par une suite de caractères ou un intervalle délimité par des expressions (caractérisé par '->', dans ML_COMMENT). On peut par contre spécifier le type de données qu'auront ces terminaux dans le modèle généré. Regardons par exemple :

terminal INT returns ecore::EInt:

Cette instruction signifie que les terminaux INT auront une valeur de type EInt, élément définissant les entiers dans le métamodèle ECore. L'utilisation de ECore est permise par l'instruction :

import "http://www.eclipse.org/emf/2002/Ecore" as ecore

On peut aussi si on le souhaite inclure ecore dans notre propre grammaire afin d'utiliser les types de données proposés. Notons que les cardinalités des différents éléments dans ces terminaux sont données par des expressions de type EBNF : Extended Backus-Naur Form. De fait les cardinalités suivantes peuvent être exprimées :

• exactement un (par défaut) ;
• un ou zéro (opérateur '?') ;
• indéfini (opérateur '*') ;
• au moins un (opérateur '+').

Au sein des terminaux, on peut utiliser différents mécanismes tels que les intervalles de caractères ('0'..'9'), les intervalles de texte (grâce au caractère '->'), les « wildcards » ('f'.'o' va reconnaître fAo, fOo, f_o…) et les négations exprimées grâce à '!'. Il est important de noter que l'ordre des terminaux est essentiel. En effet lors de la lecture du fichier, Xtext s'arrête dès qu'il a trouvé un terminal correspondant au texte lu. Dès lors, les terminaux de la grammaire peuvent se masquer les uns les autres. Il est donc recommandé si possible d'utiliser des éléments de type DataType.

Ces éléments sont décrits comme des règles standards sauf que, comme les terminaux, aucune assignation ne peut être effectuée. Voici par exemple la déclaration d'un flottant utilisant cette technique :

Double returns ecore::EDouble : INT('.'INT)?;

Notons que si aucun type de retour n'est indiqué, Xtext retournera par défaut un ecore::EString.

Il est possible de construire des énumérations. Par exemple, la visibilité d'un package en Java serait décrite sous la forme d'une énumération (trois états : private, public, protected). Dans notre grammaire, le type de motorisation se prête bien à une énumération : regardons la règle R6 des motorisations.

Nous définissons ici une énumération à deux éléments, PROPELLER ou ENGINE. L'utilisation dans le modèle de ces éléments sera effective suivant le texte rentré par l'utilisateur, respectivement 'HELICES' ou 'PROPULSEURS'.

Lors de la construction des règles de notre grammaire, nous pouvons assigner les règles et les valeurs entrées dans l'éditeur à des variables qui seront présentes dans notre modèle. Ces assignations peuvent être de trois sortes :

• affectation simple : du type maVariable = Regle : ici l'objet recevra simplement la valeur retournée par la règle. Dans notre grammaire, cela est visible par exemple dans la règle R3 : « Avion name=ID ». Ici la variable « name » aura la valeur de l'ID entré dans l'éditeur. Notons à ce sujet que les variables nommées « name » ont une signification particulière dans Xtext : le framework assimilera automatiquement cette variable au nom de l'objet, qui sera affiché dans la vue Outline par exemple ;
• affectation multiple : du type maListe += Regle : ici l'objet maListe sera une liste de Regle. Autant de fois la règle apparaîtra dans le document, autant il y aura d'éléments dans la liste. Par exemple, dans la règle R1 « includes+=Includes », la variable « includes » contiendra la liste de tous les fichiers déclarés comme inclus dans ce fichier ;
• affectation conditionnelle : du type monBooleen ?= 'TEXTE' : ici le booléen recevra vrai ou faux suivant la présence ou non du texte indiqué à droite du signe '='. Par exemple dans la règle R5 « regular?='REGULIERE'';' », la variable « regular » recevra « true » si l'utilisateur entre 'REGULIERE' dans son fichier.

Il est aussi possible d'écrire des règles sans assignation. Par exemple :

Regle : RegleA | RegleB | RegleC;

Il est parfois nécessaire de forcer l'instanciation d'un objet du modèle. Par exemple, si vous entrez la règle suivante :

Regle : (regle=Element)?;

Xtext vous affichera alors l'avertissement suivant :

The rule 'Regle' may be consumed without object instantiation. Add an action to ensure object creation, e.g. '{Regle}'.

Il suffit alors comme suggéré d'ajouter « {Regle} » juste après les ':', ce qui permettra d'avoir toujours une instance de Regle créée, même si aucun texte n'a été entré pour cette règle :

Regle : {Regle}(regle=Element)?;

Xtext est capable de créer directement les hyperliens entre la déclaration des variables de votre DSL et leur utilisation dans les fichiers. Pour cela, un mécanisme de déclaration de références est utilisé, signalé par le positionnement de l'objet à lire entre crochets. Il est important de retenir que :

• seule la référence est entre crochets, pas la déclaration elle-même ;
• l'élément entre crochets fait référence à un objet de type EClass et non à une règle grammaticale ! ;
• par défaut, le terminal de l'élément entre crochets est considéré comme ID. Le terminal indique en fait le texte qui va être concrètement remplacé par le lien. On peut spécifier un autre terminal en ajoutant un pipe ('|') derrière l'élément, suivi du terminal désiré.

Dans notre grammaire, deux types de références existent : les références aux codes OACI des aéroports et aux noms des avions. Observons d'abord le cas le plus simple : les avions. La règle R3 « Plane » va implicitement créer le type Plane qui comporte un identifiant de type ID. Nous pouvons alors dans la déclaration des lignes aériennes créer une référence vers le type Plane grâce à l'instruction « 'Avion'':'plane=[Plane]';' ». Comme mentionné précédemment, inutile de spécifier un type particulier car par défaut le type cherché est 'ID'.
Dans le cas des aéroports, le terminal n'est pas ID mais de type OACI. Il faut donc préciser le type de terminal qu'Xtext doit rechercher afin de créer les liens entre données, sous la forme « airport=[CodeOACI|OACI]; » :

Xtext fournit des outils pour gérer les imports de fichiers. À ce titre, le framework est capable de gérer les références que nous venons de décrire au travers de plusieurs fichiers, grâce à un mécanisme d'import de fichiers par leur URI. Pour indiquer à Xtext quels éléments correspondent à des imports, il suffit de les marquer avec l'attribut « importURI », comme dans notre règle R2 « '%include''<'importURI=INCLUDE'>;' ». Parfois ce mécanisme nécessite d'être affiné mais cela sera étudié dans le prochain article.

D'autres règles existent, en plus de celles citées dans les paragraphes précédents. Tout d'abord, on peut spécifier que l'ordre des règles est indéfini, mais que les règles doivent apparaître au moins une fois. Dans l'ensemble de nos déclarations par exemple, la liste des paramètres n'a pas un ordre défini, mais tous doivent être présents. Cela est réalisé en séparant les règles par le symbole '&'. Un autre exemple simple est celui des préfixes de méthodes et d'attributs en Java : on peut écrire 'public static final' ou 'final public static'.

Enfin, on peut aussi forcer la reconnaissance d'une règle pour lever par exemple une indétermination. En effet, dans le cas de conditionnelles imbriquées telles que :

if (condition()) 
    if (autreCondition()) 
    maMethode();
    else 
    autreMethode();

Dans un cas tel que celui-ci, impossible de prédire avec précision à quel 'if' appartient le 'else'. Xtext propose de spécifier au parser quelle règle doit être consommée en priorité, comme le montre l'exemple ci-dessous :

Nous avons vu dans cette partie les éléments essentiels à la construction d'une grammaire Xtext assez fournie et complexe. Pour toute référence supplémentaire, je ne peux qu'à vous enjoindre de consulter directement la documentation officielleXtext Documentation : The Grammar Language, plus fournie. Une fois notre fichier créé, il est temps de passer à la génération de la grammaire.

Le fichier « GenerateAir.mwe2 » situé dans le même dossier que le fichier « Air.Xtext » définit la liste des fragments qui vont être utilisés par Xtext pour la génération de l'éditeur. Le tableau suivant récapitule certains fragments et leur fonction :

On peut choisir les fragments que l'on souhaite générer. D'autres fragments sont présents, par exemple pour le support des tests JUnit, le refactoring ou la génération d'un wizard de création de projets pour nos fichiers. Plus particulièrement, les sections qui vont nous intéresser sont les sections de gestion des imports et des liens.

Par défaut, les liens sont recherchés à travers tous les fichiers existants, ce qui pose problème pour une gestion claire et propre des fichiers inclus. Nous allons donc modifier cette section de la manière suivante, afin que la création des liens se fasse au sein d'un unique fichier et de ses imports :

Une fois ces deux fichiers préparés, nous pouvons lancer la génération de notre grammaire. Ceci peut se faire de deux façons :

• soit par clic droit sur le fichier Xtext > « Run As > Generate Xtext Artifacts »
• soit par clic droit sur le fichier MWE2 > « Run As > MWE2 Workflow »

Cette action va lancer la génération de tous les éléments nécessaires à notre éditeur. Cette étape peut être longue, suivant la taille de la grammaire. La première fois qu'on lance la génération, le message suivant apparaît dans la console Eclipse :

*ATTENTION* It is recommended to use the ANTLR 3 parser generator (BSD licence - http://www.antlr.org/license.html). Do you agree to download it (size 1MB) from 'http://download.itemis.com/antlr-generator-3.2.0.jar'? (type 'y' or 'n' and hit enter)

Il suffit de répondre 'y' et la génération continue. Ce JAR ne peut pas être inclus par défaut avec Xtext pour des problèmes de licence : le code généré par ANTLR et utilisé par Xtext n'est pas contraint en licence. Il n'utilise pas une « librairie/runtime » (par exemple) qui pourrait avoir une licence contaminante. À la fin de la génération, tous les dossiers « src-gen » de vos plugins devraient être fournis avec un certain nombre de classes. Dans le plugin « ui », le dossier « src » contient le package « org.Xtext.ui » qui nous permettra de personnaliser notre IDE.

Lorsque Xtext rencontre un problème lors de la génération de la grammaire, c'est quasiment systématiquement suite à la vérification de celle-ci par le parser ANTLR. Si la plupart des erreurs sont compréhensibles et donc assez faciles à corriger, il en est une qui revient très couramment mais pourtant n'est pas explicite. Cette erreur apparaît sous cette forme :

[fatal] rule MaRegle has non-LL(*) decision due to recursive rule invocations reachable from alts x,y. Resolve by left-factoring or using syntactic predicates or using backtrack=true option.

Les nouvelles versions d'Xtext savent détecter cette erreur dans l'éditeur directement. Ce n'était pas le cas avec des versions plus anciennes, auquel cas ce paragraphe pourra vous dépanner !

Cette erreur est levée par une expression comme celle-ci :

Pour corriger cette erreur, il suffit de factoriser la règle de cette manière :

Une fois notre grammaire générée, il est temps de la tester au sein d'un éditeur. Pour cela, une méthode simple est de faire un clic droit sur le projet « *.ui » et de choisir « Run As > Launch Runtime Eclipse ». Cette option va lancer une copie exacte de votre instance Eclipse en cours d'exécution, ce qui peut entraîner un temps de chargement assez long pour de simples tests. L'autre solution consiste à définir soi-même une configuration au sein du panneau « Run configurations » d'Eclipse et de ne sélectionner que les plugins nécessaires à l'exécution du plugin « *.ui » (bouton « Add required plugins »). Dans l'onglet « Main », l'option choisie dans la section « Program to Run » est « Run a product : org.eclipse.sdk.ide »

Une fois notre instance de test lancée, il suffit de créer un nouveau projet vide « File > New > Project », et de créer à l'intérieur de ce projet un nouveau fichier « .air ». Xtext vous proposera alors de configurer votre projet pour être utilisé avec Xtext :

Vous pourrez donc profiter de l'autocomplétion et des autres outils associés pour créer vos fichiers.

On peut d'ailleurs observer le résultat avec notre fichier d'exemple présenté en début de cet article. Xtext nous fournit bien un environnement convivial de travail, bien plus qu'un simple éditeur classique. Notez la présence de la Outline déjà configurée avec les attributs de la grammaire nommés « name » !