En C#, les paramètres suivants peuvent accepter des variables par tag : persistantModelPath, persistantReferencesModelPath et nonPersistantModelPath (j'ai mis la doc du générateur C# à jour en conséquence)
En Java, il s'agit de modelRootPath, entitiesPackageName, daosPackageName et dtosPackageName.
J'en ai aussi profité pour mettre au propre la gestion des variables {app}, {module} et {lang}, en ajoutant une méthode générale sur la config ResolveVariables qui centralise tout ce qui n'est pas variable globale (donc celles là et les variables par tag). Concrètement, on peut donc utiliser des modifiers dessus comme les autres variables (:pascal, :camel...) et il y a des warnings si on utilise ces variables à des endroits où ce n'est pas supporté (en revanche, on vérifie pas dans les variables par tag, il faudrait vérifier plus tard à la résolution, ce qui n'est pas cohérent avec ce qu'on fait déjà. C'est déjà pas mal comme ça hein ;) )
J'ai mis à jour la doc de la config pour qu'elle explique bien tout ça (bon courage à ceux qui essaieront de la lire !).
J'ai ensuite passé pas mal de temps à ranger et à mutualiser nos usages de module, en déclinant dans l'objet Namespace la plupart des formes qu'on utilise (genre RootModule, ModulePath, ModulePathKebab...), dans l'objectif d'avancer sur #216 et voir ce qu'on peut faire là dessus (spoiler alert : on va probablement rien faire).
J'ai fait quelques fixes sur la génération qu'on peut voir dans la diff sur les samples. Dans tout mon boulot de rangement, j'ai changé la façon dont sont générés les mappers Java pour qu'ils soient regroupés par module et non par module racine : ce n'était pas cohérent avec mon implé C# ( :rofl: ), mais surtout pas cohérent avec le fait qu'on les génère au même endroit que les classes. On peut en discuter sur #216 ;)
Fix #138 (enfin en entier !)
persistantModelPath,persistantReferencesModelPathetnonPersistantModelPath(j'ai mis la doc du générateur C# à jour en conséquence)modelRootPath,entitiesPackageName,daosPackageNameetdtosPackageName.J'en ai aussi profité pour mettre au propre la gestion des variables
{app},{module}et{lang}, en ajoutant une méthode générale sur la configResolveVariablesqui centralise tout ce qui n'est pas variable globale (donc celles là et les variables par tag). Concrètement, on peut donc utiliser des modifiers dessus comme les autres variables (:pascal,:camel...) et il y a des warnings si on utilise ces variables à des endroits où ce n'est pas supporté (en revanche, on vérifie pas dans les variables par tag, il faudrait vérifier plus tard à la résolution, ce qui n'est pas cohérent avec ce qu'on fait déjà. C'est déjà pas mal comme ça hein ;) )J'ai mis à jour la doc de la config pour qu'elle explique bien tout ça (bon courage à ceux qui essaieront de la lire !).
J'ai ensuite passé pas mal de temps à ranger et à mutualiser nos usages de
module, en déclinant dans l'objetNamespacela plupart des formes qu'on utilise (genreRootModule,ModulePath,ModulePathKebab...), dans l'objectif d'avancer sur #216 et voir ce qu'on peut faire là dessus (spoiler alert : on va probablement rien faire).J'ai fait quelques fixes sur la génération qu'on peut voir dans la diff sur les samples. Dans tout mon boulot de rangement, j'ai changé la façon dont sont générés les mappers Java pour qu'ils soient regroupés par module et non par module racine : ce n'était pas cohérent avec mon implé C# ( :rofl: ), mais surtout pas cohérent avec le fait qu'on les génère au même endroit que les classes. On peut en discuter sur #216 ;)