Relation entre gabarits

[fduchatea]

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 :

"compose_relational_schema": "\\begin{{mld}}\n{relations}\n\\end{{mld}}"

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 :

"gabarit_parent": "latex.json",
"compose_relational_schema": "\\begin{{mld}}\n{relations}\n\\end{{mld}}"

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 :

• quel comportement si on redéfinit une liste (ex, "transform_attribute") ? Est-ce qu'on remplace la liste du gabarit parent par celle de l'enfant, ou on concatène les 2 listes ?
• doit-on gérer les relations parent sur plusieurs niveaux (ex, gab3 a pour parent gab2, qui a pour parent gab1) ? Ca me semble pas forcément très utile, mais à voir à l'usage.

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.

[laowantong]

Ç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 :

• Quand on rencontre une clé associée à None, on la supprime.
• Quand on rencontre une clé associée à un type scalaire, on la crée ou on la met à jour.
• Quand on rencontre une clé associée à une liste de dictionnaires, à voir, effectivement on peut imaginer beaucoup de choses (remplacer, étendre, insérer). L'idiome Python 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.

[laowantong]

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.

[fduchatea]

Quelques commentaires sur ces propositions :

• avec JSONpatch, il y a la dépendance, le nouveau format à comprendre/utiliser pour écrire des patchs. Mais ça limite la redondance et c'est ok pour définir et maintenir ses propres templates. Ok pour le partage de templates. Davantage de fichiers, mais facilement différenciables des templates.
• "une seul gabarit avec parties optionnelles" : nouvelles clés à créer/connaitre, et la limitation actuelle sur la maintenance (quand un gabarit Mocodo change, on doit mettre à jour ses gabarits qui en sont des copies adaptées) serait toujours présente avec cette solution, car on ne peut pas ajouter dans Mocodo toutes les variantes de gabarits voulues par les utilisateurs. Plus difficile de partager un template (besoin de modifier le gabarit de base). Mais on garde 1 seul fichier par format de sortie.
• "fichiers = gabarits normaux" : presque ok pour la maintenance (si une clé change de nom, on doit la modifier dans son template perso, même pour les clés que l'on n'adapte pas). Un peu de redondance (au niveau des clés du JSON associées à une valeur None). Partage ok. Mais davantage de fichiers templates (importance du nommage).
• "fichiers = gabarits avec juste les modifications" : ok pour la maintenance (sauf évidemment pour les éléments qu'on adapte). Pas de redondance. Partage ok. Mais davantage de fichiers templates (importance du nommage).

La dernière solution me semble moins contraignante (sous réserve de ne pas créer trop de variantes).

[laowantong]

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 :

• un gabarit enfant ne se distingue d'un gabarit sans parent que par l'ajout d'une clé "parent" ;
• pas de nouvelle dépendance ;
• héritage récursif ;
• future proof : les mises à jour des gabarits de la distribution ne devraient en général pas obliger l'utilisateur à mettre à jour les siens.

[fduchatea]

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 ?).

[laowantong]

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.

[laowantong]

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.