Sujet sur Discussion Gestion:Tâches/Liste/69

Pour reprendre ce que tu as dit @Antoine Mercier-Linteau dans le fil sur mxGraph:

Je propose donc d'y aller avec une librairie déclarative comme Mermaid (ou autre). Cette librairie serait appelée par un module (en Lua) qui s'occuperait de traduire le wikicode en la syntaxe comprise par la librairie. Cette petite couche d'abstraction supplémentaire nous permettra d'éventuellement changer de librairie si le besoin se fait sentir. La courbe d'apprentissage sera un peu plus abrupte pour les éditeurs, mais il pourront voir à même l'Éditeur Visuel le résultat de leurs manipulations.

Les paramètres passés au modèle pourraient avoir l'air de ceci:

{{Diagramme
          |Boîte 1<!-- Supporte du HTML arbitraire. -->
          |1_lien_1= Oui <!-- Supporte du HTML arbitraire. -->
          |1_lien_3=
          |groupe_1=1,2
          |2=Boîte 2
          |2_lien_3=
          |3=Boîte 3
          |raw=Passe la syntaxe directement à la librairie
          }}

Les éditeurs iraient donc construire les diagrammes en spécifiant des paramètres à un modèle à même l'éditeur visuel.

En syntaxe Mermaid:

 graph TD
  subgraph 1
  A[Boîte 1] -->|Oui|B(Boîte 2)
  end
  A --> |Non|C
  B --> C(Boîte 3)

Pour ce qui concerne spécifiquement Mermaid, il semblerait que ce soit une bibliothèque qui fonctionne uniquement côté client, ce qui imposerait de servir aux lecteurs les diagrammes sous forme de syntaxe Mermaid brute avec un script JS qui s’occupe de faire la transformation en SVG côté client. On avait déjà discuté d’un cas similaire précédemment et on était arrivés à la conclusion que ce n’était pas optimal que du JS soit nécessaire pour seulement voir les diagrammes.

Il y a bien mermaid-cli qui permet de convertir côté serveur la syntaxe Mermaid en SVG/PNG/PDF, mais (il faut bien se tenir) elle fonctionne en lançant sur le serveur une instance de Chromium, en chargeant la bibliothèque Mermaid dans ce navigateur et en exportant le résultat. Ça me semble loin d’être optimal, et je n’ai rien trouvé d’autre pour convertir du Mermaid côté serveur. Bien sûr, ce serait possible de développer notre propre solution pour faire cette conversion, ce qui serait sans nul doute utile à la communauté, mais ça va prendre pas mal de temps.

Sinon, il nous reste GraphViz, mais le support de cette bibliothèque pour le HTML est pour le moins limité. Cela peut se comprendre puisqu’il devient d’autant plus difficile de calculer les dimensions externes d’une boîte (nécessaires pour savoir où placer chaque boîte) que le nombre de fonctionnalités HTML supportées croît. Finalement, pour supporter tout HTML, GraphViz aurait à réimplémenter tout un moteur de rendu HTML d’un navigateur.

Voici quelques ressources intéressantes relatives à GraphViz :

Si on voulait reproduire ton exemple fait avec Mermaid, voici ce que ça pourrait donner :

digraph {
    node[color="#9370DB", fillcolor="#ECECFF", fontname="Liberation Sans"];
    edge[fontname="Liberation Sans", color="#333333", arrowsize=.7];

    node[shape="box", style="filled"]; A;
    node[shape="box", style="rounded, filled"]; B; C;
    node[group="G1"]; A; B;

    A[label="Boîte 1"];
    B[label="Boîte 2", group="G1"];
    C[label="Boîte 3", group="G1"];

    A -> C [
        headlabel=<<TABLE BGCOLOR="#ECECFF" BORDER="0" CELLPADDING="0"><TR><TD>Non</TD></TR></TABLE>>,
        labeldistance=7, labelangle=0
    ];

    B -> C;

    subgraph cluster1 {
        label="1";
        style="filled";
        color="#AAAA33";
        fillcolor="#FFFFDE";

        A -> B [
            headlabel=<<TABLE BGCOLOR="#ECECFF" BORDER="0" CELLPADDING="0"><TR><TD>Oui</TD></TR></TABLE>>,
            labeldistance=2, labelangle=0
        ];
    }
}

Avec GraphViz, il n’est pas aisé de contrôler l’agencement des différentes boîtes, ce qui est lié au compromis qui est fait entre l’approche de Draw.io où tout le positionnement est fait à la main et l’approche déclarative où le positionnement est calculé par un algorithme.