Closed fduchatea closed 1 year ago
Ça me paraît une excellente idée, pour mocodo offline en tout cas.
Si on le fait sur deux niveaux, ce n'est pas plus compliqué de le faire sur $n>2$. Il suffit de lire les fichiers en succession.
Les fichiers pourraient tous être des gabarits normaux :
None
, on la supprime.a[start:stop] = b
couvrant toutes les possibilités, on pourrait par exemple ajouter deux clés "start"
et "stop"
pour spécifier le traitement. Mais cela demanderait à faire référence aux indices de la liste initiale, c'est contraignant.Une autre approche serait de distinguer deux types de fichiers, les gabarits et les patches. Il y a une RFC pour ça, cf. https://jsonpatch.com. C'est peut-être le plus simple, mais cela demande à introduire une dépendance.
Une troisième approche serait de garder un seul gabarit, mais d'introduire des parties optionnelles qui seraient sélectionnées en fonction d'un suffixe de la clé, p. ex. :
"compose_relational_schema": "\\begin{{mld}}\n{relations}\n\\end{{mld}}",
"compose_relational_schema/no_env": "{relations}",
Pour les listes de dictionnaires, l'option ou les options seraient spécifiées par un champ supplémentaire :
"transform_relation": [
{
"options": ["foo", "bar"],
"comment": "Replace the missing data types with an arbitrary default.",
"search": " None,\n",
"replace": " VARCHAR(42),\n"
},
{
"comment": "Replace the boolean data type placeholders.",
"search": " BOOLEAN,\n",
"replace": " NUMBER(1) DEFAULT 0 NOT NULL,\n"
},
Dans ce dernier cas cela éviterait d'avoir à faire référence à des indices pour l'insertion ou la suppression, ce qui n'est pas très naturel en JSON.
Quelques commentaires sur ces propositions :
La dernière solution me semble moins contraignante (sous réserve de ne pas créer trop de variantes).
Aucune des solutions proposées précédemment n'étant pleinement satisfaisante, j'en ai implanté une autre qui a requis l'ajout d'une numérotation par pas de 100 dans les listes de dictionnaires des gabarits de la distribution. L'utilisateur qui crée des gabarits enfants peut insérer, supprimer et mettre à jour à n'importe quelle position. Les propriétés de cette solution sont :
"parent"
;Super, je teste prochainement l'héritage de gabarits. A-priori la mise à jour n'impactera effectivement pas (sauf si un gabarit de la distribution ajoute un élément au milieu d'une liste peut-être ?).
Pas d'impact non plus a priori pour peu que l'utilisateur utilise des numéros d'ordre non divisibles par 10, cf. documentation.
Je dois encore donner la possibilité de placer les gabarits-utilisateurs ailleurs que dans le dossier de gabarits de la distribution. J'essaie de finaliser ça aujourd'hui.
C'est fait dans la version 3.1.0 qui vient d'être publiée.
Par rapport à notre discussion, j'ai décidé d'éviter le terme « héritage » qui peut induire à confusion avec l'héritage d'entités. Je parle de gabarits dérivés.
L'utilisation des gabarits est très pratique et flexible (bien que cette partie de la documentation ne soit pas la plus facile à appréhender).
Les gabarits proposés sont déjà très diversifiés, et mes besoins concernent juste des adaptations mineures. Par exemple, pour le gabarit Latex, je ne veux pas que la sortie produise la définition de l'environnement
mld
(que je stocke dans une macro à part). Cela me permet de faire directement un\input{mon_mld.tex}
sans avoir besoin d'aller y supprimer la définition. Du coup mon gabarit Latex est identique à celui de base de Mocodo, sauf la ligne :Idem pour certains gabarits SQL, la seule modification concerne la suppression de(s) ligne(s) permettant la création de la base de données.
Pour ces adaptations mineures, on obtient donc 2 gabarits avec beaucoup de code redondant. Pour limiter cette redondance, pourrait-on définir un "gabarit parent" pour un nouveau gabarit ? Par exemple, mon gabarit
latex-perso.json
pourrait ressembler à ça :On ne redéfinit que les propriétés pertinentes (ici "compose_relational_schema"), et les autres propriétés ("extension", "transform_attribute", etc) sont chargées/récupérées dans le gabarit parent.
Quelques réflexions :
En plus de l'avantage de limiter la redondance de code, ça simplifie les mises à jours (si un gabarit de base est modifié, comme entre la v2 et la v3 de Mocodo, il faut fusionner correctement les mises à jour avec les gabarits qu'on a définis). Et ça permet de proposer des gabarits légèrement différents (ex, cas du SQL avec ou sans la création de la BD), ce qui répond à des besoins différents.