Tous les générateurs supportent désormais des variables dans leur configuration, qui peuvent être utilisées dans les différents paramètres. Par exemple :
Les variables sont nécessairement des strings et ne peuvent donc être utilisées que dans des paramètres de type string. Il n'est pas exclu par la suite de gérer par la suite les nombres et les booléens, mais pour rester simple dans un premier temps ils ont été exclus.
Les variables peuvent faire l'objet de transformations (:upper, :pascal, :camel...) de la même façon que les variables des templates dans les domaines et décorateurs.
Variables par tag
Un générateur peut choisir d'implémenter des variables qui ont des valeurs différentes selon le tag du fichier. De ce fait, un fichier ayant plusieurs tags résultant en des valeurs de paramètres différentes sera à priori généré plusieurs fois pour correspondre à chacune des valeurs possibles.
Seul le générateur JS implémente cette fonctionnalité pour l'instant : #158 a implémenté une version réduite avec une variable {tag} qui avait automatiquement la valeur du tag, et cette PR permet de généraliser ce fonctionnement via des variables par tag. Par exemple :
tagVariables permet pour un tag de définir une liste de variables qui ne seront appliquées que lors de la génération de fichiers avec ce tag-là. Toutes les propriétés du générateur ne supportent pas les variables par tag. Pour le générateur JS, il s'agit de modelRootPath, apiClientRootPath, resourceRootPath, fetchPath et domainPath (remarque importante : les deux derniers paramètres ont été renommés et représentent désormais un chemin relatif depuis outputDirectory).
On distingue donc des variables globales et des variables par tag. Une variable globale peut être surchargée par une variable par tag, mais dans ce cas cette variable devient une variable par tag (et par conséquent n'est plus supportée dans les champs qui ne peuvent pas avoir de variables par tag). Une variable par tag existe dès lors qu'elle est définie par au moins un tag, et si un tag ne renseigne pas une variable par tag définie dans un autre tag, alors sa valeur pour ce tag sera automatiquement renseignée à "" (ce qui effacera effectivement la variable lors de la résolution de valeur du paramètre).
modgen affichera un warning s'il trouve une variable non définie dans un paramètre (et précisera qu'il cherche une variable globale dans un paramètre qui ne supporte pas les variables par tag). Les variables non définies seront gardées telles quelles dans la génération.
Toutes ces variables s'ajoutent aux variables prédéfinies {app}, {module} et {lang} qui sont utilisées dans certains paramètres. Idéalement, il ne faudrait pas les redéfinir (elles sont renseignées d'une manière qu'il n'est pas possible de reproduire avec la solution présentée), mais en théorie, puisque les variables de générateurs sont résolues en premier, une redéfinition agirait comme une surcharge.
Cette PR permettra d'implémenter #138 sur les générateurs C# et Java.
Ah, et un truc qui n'a rien à voir, mais le schéma du fichier de config est désormais réellement vérifié au parsing, qui sera en erreur s'il n'est pas respecté.
Tous les générateurs supportent désormais des variables dans leur configuration, qui peuvent être utilisées dans les différents paramètres. Par exemple :
Les variables sont nécessairement des strings et ne peuvent donc être utilisées que dans des paramètres de type string. Il n'est pas exclu par la suite de gérer par la suite les nombres et les booléens, mais pour rester simple dans un premier temps ils ont été exclus.
Les variables peuvent faire l'objet de transformations (
:upper,:pascal,:camel...) de la même façon que les variables des templates dans les domaines et décorateurs.Variables par tag
Un générateur peut choisir d'implémenter des variables qui ont des valeurs différentes selon le tag du fichier. De ce fait, un fichier ayant plusieurs tags résultant en des valeurs de paramètres différentes sera à priori généré plusieurs fois pour correspondre à chacune des valeurs possibles.
Seul le générateur JS implémente cette fonctionnalité pour l'instant : #158 a implémenté une version réduite avec une variable
{tag}qui avait automatiquement la valeur du tag, et cette PR permet de généraliser ce fonctionnement via des variables par tag. Par exemple :tagVariablespermet pour un tag de définir une liste de variables qui ne seront appliquées que lors de la génération de fichiers avec ce tag-là. Toutes les propriétés du générateur ne supportent pas les variables par tag. Pour le générateur JS, il s'agit demodelRootPath,apiClientRootPath,resourceRootPath,fetchPathetdomainPath(remarque importante : les deux derniers paramètres ont été renommés et représentent désormais un chemin relatif depuisoutputDirectory).On distingue donc des variables globales et des variables par tag. Une variable globale peut être surchargée par une variable par tag, mais dans ce cas cette variable devient une variable par tag (et par conséquent n'est plus supportée dans les champs qui ne peuvent pas avoir de variables par tag). Une variable par tag existe dès lors qu'elle est définie par au moins un tag, et si un tag ne renseigne pas une variable par tag définie dans un autre tag, alors sa valeur pour ce tag sera automatiquement renseignée à
""(ce qui effacera effectivement la variable lors de la résolution de valeur du paramètre).modgenaffichera un warning s'il trouve une variable non définie dans un paramètre (et précisera qu'il cherche une variable globale dans un paramètre qui ne supporte pas les variables par tag). Les variables non définies seront gardées telles quelles dans la génération.Toutes ces variables s'ajoutent aux variables prédéfinies
{app},{module}et{lang}qui sont utilisées dans certains paramètres. Idéalement, il ne faudrait pas les redéfinir (elles sont renseignées d'une manière qu'il n'est pas possible de reproduire avec la solution présentée), mais en théorie, puisque les variables de générateurs sont résolues en premier, une redéfinition agirait comme une surcharge.Cette PR permettra d'implémenter #138 sur les générateurs C# et Java.
Ah, et un truc qui n'a rien à voir, mais le schéma du fichier de config est désormais réellement vérifié au parsing, qui sera en erreur s'il n'est pas respecté.