Discussion Gestion:Tâches/Liste/69

À propos de ce flux de discussion

Non modifiable

Rendu des diagrammes dans l'éditeur visuel

4
Antoine Mercier-Linteau (discussioncontributions)

Les diagrammes n'apparaissent pas dans l'éditeur visuel et donc leur mise à jour ne s'effectue pas lorsque les paramètres changent.

Selon moi, c'est juste l'histoire de coder un petit hook qui lance le rendu une fois le chargement de l'éditeur fait et lorsque le modèle du diagramme est modifié.

Le gadget MediaWiki:Gadget-visual-editor-page-transclusion-support.js pourrait servir d'inspiration. Pour la liste de tous les gadgets, voir MediaWiki:Gadgets-definition.

@Charles-Éric Noël Laflamme, tu possèdes une bonne connaissance de l'éditeur visuel côté JS. Peux-tu nous prêter assistance?

On pourra ensuite donner la patch aux développeurs de l'extension Mermaid.

Antoine Mercier-Linteau (discussioncontributions)
Antoine Mercier-Linteau (discussioncontributions)
Michaël St-Gelais (discussioncontributions)

Oui ça fonctionne bien.

Contenu des noeuds en HTML?

1
Antoine Mercier-Linteau (discussioncontributions)

@Mattéo Delabre, je croyais que Mermaid pouvait prendre en charge du HTML arbitraire dans ses noeuds. Il semblerait que ça se limite à certains tags comme b, i, etc.

J'ai codé une fonction de parsage dans MediaWiki et je l'appelle depuis le module Lua:

table.insert(lines, string.format(nodes_shapes[shape], id, escape_quotes(frame:callParserFunction('#wikicodeToHtml', name))))

(désactivé pour ne pas briser les graphiques)

Malheureusement, ça brise le rendu. Aurais-tu une idée de comment passer outre cette limite sans trop se casser la tête?

Sinon on peut simplement stocker tout ça dans un div caché et aller placer les bouts de HTML une fois le rendu du graphique terminé.

Intégration d’une bibliothèque déclarative avec une couche d’abstraction en Wikicode

19
Mattéo Delabre (discussioncontributions)

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 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, ce qui nous rapproche de la solution mermaid-cli.

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.

Antoine Mercier-Linteau (discussioncontributions)

Embêtant...

Mermaid Graphviz
+
  • Extension simple et compatible avec MW 1.34
  • Positionnement automatisé
  • Support pour tout le HTML, incluant onClick en JS
  • Syntaxe simple
  • Rapide
  • Très flexible
  • Projet bien établi en activité depuis 2003
-
  • Interprétation de la syntaxe en JS
  • Utilisation headless possible, mais lourde
  • Extension incompatible avec MW 1.34
  • Une partie du positionnement est manuelle
  • Support pour un sous-ensemble réduit du HTML

J'ai l'impression que Mermaid est potentiellement la meilleure solution, principalement pour:

  • Support HTML: nous allons pouvoir lui fournir du wikicode arbitraire
  • Positionnement automatisé: on ne peut pas s'attendre à ce que les éditeurs soient en mesure de régler eux mêmes le positionnement
  • Syntaxe simple: la génération de graphes complexes sans passer par la couche d'abstraction en wikicode sera plus accessible
  • Nous demandera moins de travail d'intégration, car l'extension est d'emblée fonctionnelle et la syntaxe simple

J'ai testé mermaid-cli pour le rendu sur le serveur et c'est relativement rapide. Après, il serait possible ultérieurement d'améliorer l'extension pour qu'elle puisse faire du rendu sur le serveur et passer les SVG au client.

Tu en penses quoi? @Jppialasse?

Jppialasse (discussioncontributions)

graphviz fonctionnait pas mal avant l'update en 1.34. C'est un peu complexe comme syntaxe pour quelq'un faisant de l'édition visuelle, mais ce pense pas inapprochable. vous pouvez encore trouver des exemples sur mon ancienne page : https://wikimedi.ca/wiki/Utilisateur:Jppialasse/Archive

J'aurais juste précisé le point 5 du cahier des charges : par backend je pense que tu voulais dire pas de deamon complexe à installer à coté ou une myriade de librairies nodejs. En effet je suis vraiment pour que la génération se fasse coté serveur avec une librairie php ou quelque chose que php puisse utiliser directement sans avoir un service qui tourne pour cela. (eg l’éditeur visuel actuel, la génération de pdf)

Ainsi, je suis contre la génération coté client via JS: - on ne connais pas et on ne peut pas maitriser les capacités du client et donc garantir le résultat de l'affichage sur la diversité de client. Si quelqu'un désactive JS, ou se fait filtrer certaines url de librairies JS rien ne s'affiche ou n'importe comment. Idem probablement si on utilise un système comme Kiwix pour un acces hors ligne.


<graphviz caption="Hyponatrémie" alt="algorithme hyponatrémie" format="png" border='frame'> digraph hyponatremie {

node [shape=plaintext];
X0 [shape=point,label=""];
X1 [label="-Hyperglycémie\n-Mannitol"];
X2 [label="-Hypertriglycéridémie\n-Hyperprotéinémie"];
Euv1 [label="*Polydipsie primaire\n*Potomanie"];
Euv2 [label="*SIADH\n*Hypothyroidie\n*Insuff. surrénalienne\n(glucocorticoïdes)"];
Hypo1 [label="*vomissements\n*Diarrhée\n*3e espace\n*cutané\n*pulmomaire"];
Hypo2 [label="*Thiazides\n*Insuff surrénalienne\n(mineralocorticoïdes)\n*diurèse somotique"];
Hype1 [label="*Insuff. cardiaque\n*Insuff Hépatique\n*Sd néphrotique"];
Hype2 [label="*IRA\n*IRC"];
Extra_rénales [label="Extra-rénales"];
Euv1lab [label="Na(u)> 20mEq/L(variable)\n Osm(u) < Osm(P)"];
Euv2lab [label="Na(u)> 20mEq/L(variable)\n Osm(u) > Osm(P)"];
Hypo1lab [label="Na(u)< 10mEq/L(variable)\n Osm(u) > Osm(P)\n FE Na < 1%"];
Hypo2lab [label="Na(u)> 0mEq/L(variable)\n Osm(u) = Osm(P)\n FE Na >2%"];
Hype1lab [label="Na(u)< 10-20mEq/L(variable)\n Osm(u) > Osm(P)"];
Hype2lab [label="Na(u)> 0mEq/L(variable)\n Osm(u) = Osm(P)"];


Hyponatrémie->Isoosmolaire->X2
Hyponatrémie->Hypoosmolaire->X0
X0->Euvolémique->Euv1->Euv1lab
Euvolémique->Euv2->Euv2lab
X0->Hypovolémique->Rénales->Hypo1->Hypo1lab
Hypovolémique->Extra_rénales->Hypo2->Hypo2lab
X0->Hypervolémique->Hype1->Hype1lab
Hypervolémique->Hype2->Hype2lab
Hyponatrémie->Hyperosomolaire->X1


} </graphviz>

Antoine Mercier-Linteau (discussioncontributions)

Exact pour le backend! Également, la contrainte de la consultation du wiki offline en est une bonne et il faudra y penser bientôt.

Ceci dit, le support très limité pour le HTML dans graphviz (on a même pas accès aux liens, il faut passer par une image map...) est pour moi pas un killer. Tout comme le positionnement approximatif.

Mermaid nous permettrait d'avancer rapidement sur cette fonctionnalité et dans le futur, nous pourrons faire de la génération de diagrammes sur le serveur pour ne pas dépendre des clients.

Antoine Mercier-Linteau (discussioncontributions)

Dans tous les cas, il nous faut une couche d'abstraction que l'on choisisse Mermaid ou GraphViz. J'ai donc créé les page suivantes pour prendre cela en charge:

  • Modèle:Flowchart (plutôt que diagrammes, car nous allons potentiellement en créer d'autres types, comme les pie charts): ne fait surtout que rediriger au module afin de le rendre disponible dans l'éditeur visuel et bien le documenter
  • Module:Flowchart: module Lua dont la tâche sera d'adapter les paramètres du modèle Flowchart dans le langage de la librairie de visualisation
Mattéo Delabre (discussioncontributions)

J’ai repris le travail sur cette tâche après un hiatus de deux mois. Antoine vient de se charger de l’installation de l’extension Mermaid. Voici quelques éléments que j’ai relevés en programmant le module Lua.

  • Mermaid ne semble pas fournir une façon simple de forcer le niveau auquel un nœud est placé ou de demander à ce que deux nœuds soient au même niveau, pour obtenir des nœuds configurés de la même manière que l’exemple suivant donné par Antoine : . Une telle fonctionnalité est demandée dans cette issue et cette issue. Dans cette dernière, une solution de contournement est proposée à base de nœuds invisibles intermédiaires, à voir s’il est possible de générer automatiquement de tels nœuds dans le module Lua.
Mattéo Delabre (discussioncontributions)

Je viens d’ajouter une première version du Modèle:Flowchart. Voici par exemple comment pourrait être reproduit un flowchart que j’ai trouvé au hasard parmi les fichiers téléversés sur Wikimedica.

Version originelle

Version avec le modèle

Code

{{Flowchart
| non catég = Fichier<br>non catégorisé
| non catég.shape = rounded
| non catég -> perm inconnue = Ajout d’une description et<br>d’une condition d’utilisation

| perm inconnue = Fichier<br>de permission<br>inconnue
| perm inconnue.shape = rounded
| perm inconnue.style.fill = #ff9900
| perm inconnue -> peut utiliser ?

| peut utiliser ? = Ce fichier peut-il<br>être utilisé<br>sur Wikimedica?
| peut utiliser ?.shape = diamond
| peut utiliser ? -> perm inconnue = Je ne sais pas

| peut utiliser ? -> utilisable = Oui
  | utilisable = Fichier utilisable<br>(ou autre)
  | utilisable.style.fill = #00cc00

| peut utiliser ? -> académique ? = Non
  | académique ? = Ce fichier est-il<br>utilisé dans un<br>cadre académique?
  | académique ?.shape = diamond
  | académique ? -> exempté = Oui
    | exempté = Fichier exempté
    | exempté.shape = rounded
    | exempté.style.fill = #ff6666

  | académique ? -> remplaçable ? = Non
    | remplaçable ? = Est-il possible de<br>remplacer le fichier ?
    | remplaçable ?.shape = rounded
    | remplaçable ? -> à remplacer = Non
      | à remplacer = Fichier à remplacer
      | à remplacer.shape = rounded
      | à remplacer.style.fill = #ff6666

    | remplaçable ? -> remplacement = Oui
      | remplacement = Remplacer le fichier
      | remplacement.shape = rounded
      | remplacement.style.fill = #729fcf
}}

Rendu


J’ai pris un certain nombre de libertés avec la syntaxe des paramètres, j’ai essayé de faire quelque chose qui ne soit ni trop difficile à écrire ni trop difficile à parser. Une fois qu’on se sera accordé sur une syntaxe, je prendrai le temps d’écrire une documentation plus fournie du modèle. Dans l’état actuel, quatre types d’arguments sont possibles :

  • Paramètres du flowchart
    Préfixés d’un caractère $, ils se rapportent à l’apparence générale du flowchart.
    • $orientation=... définit la direction du flowchart, parmi to bottom (par défaut), to right, to top, to left.
    • $theme=... sélectionne un thème Mermaid, parmi neutral (par défaut), default, forest, dark.
    • $debug active le mode débogage dans lequel des informations sur la représentation interne et sur le code Mermaid généré sont affichées.


  • Définition d’un nœud du flowchart
    Sous la forme id nœud=Étiquette à afficher pour le nœud, quasiment tous les caractères sont autorisés dans l’identifiant du nœud, sauf ceux utilisés pour déclarer un lien, un paramètre général ou un groupe. On peut en plus définir des propriétés pour les nœuds, telles que :
    • id nœud.shape=... spécifie la forme du nœud, parmi rectangle (par défaut), rounded, circle, flag, diamond.
    • id nœud.group=... définit le groupe de nœuds auquel appartient ce nœud, par défaut aucun.
    • id nœud.style.fill=... couleur de remplissage du nœud, par défaut c’est celle du thème Mermaid actif.
    • id nœud.style.stroke=... idem pour la bordure du nœud


  • Ajout d’un lien entre deux nœuds
    Sous la forme id nœud d’origine -> id nœud d’arrivée, ou id nœud d’origine -> id nœud d’arrivée=Étiquette du lien pour ajouter une étiquette. Comme pour les définitions de nœuds, on peut définir des propriétés pour le lien, telles que :
    • id nœud d’origine -> id nœud d’arrivée.shape=... spécifie la forme du lien, parmi curve (par défaut), linear, step, step before, step after.
    • id nœud d’origine -> id nœud d’arrivée.ending=... peut valoir arrow pour ajouter une flèche au bout du lien (par défaut), ou plain pour ne rien y mettre.


  • Définition d’un groupe de nœuds
    Les nœuds sont ajoutés à un groupe en affectant leur propriété .group=id du groupe. On peut en plus spécifier l’étiquette du groupe avec la syntaxe group id du groupe=Étiquette du groupe (préfixé de group).
    Quelques remarques supplémentaires :
  • Les flowcharts Mermaid ne chargent pas dans l’éditeur visuel. On dirait un problème avec l’extension Mermaid.
  • Vue la nature dynamique des noms des arguments du modèle, je ne suis pas sûr qu’on puisse le documenter avec TemplateData, et ça risque de ne pas être évident à saisir depuis l’éditeur visuel. Voyez-vous une façon de modifier la syntaxe des arguments du modèle pour faciliter cela ?
  • À cause d’une limitation technique de Lua, l’ordre des paramètres du modèle (et donc des nœuds) n’est pas nécessairement préservé dans le flowchart. Peut-être qu’il serait possible de rajouter un paramètre du type order prenant une valeur numérique pour fixer l’ordre des nœuds, mais je pense que Mermaid aussi a tendance à réordonner les nœuds à sa guise.
  • Comme mentionné dans mon message précédent, il ne semble pas être possible de forcer le rang d’un nœud pour faire en sorte par exemple que deux nœuds apparaissent à la même hauteur. Ça se passe au niveau de bibliothèque de layout utilisée par Mermaid, Dagre.

Quel est votre avis là-dessus ?

Antoine Mercier-Linteau (discussioncontributions)

Excellent travail, voici mes commentaires:

  • J'irais avec la forme rounded par défaut.
  • L'intégration avec l'éditeur visuel n'est pas triviale, il va sûrement falloir coder un hook pour que le flowchart soit regénéré après chaque modification du modèle associé.
  • Pour la documentation des paramètres, on peut se contenter de les documenter de manière à afficher un exemple de départ.
    • Ensuite, il est simple de créer des paramètres arbitraires avec l'éditeur visuel alors je crois que ça va aller.
    • Reste qu'il y aura une petite courbe d'apprentissage dans l'utilisation de l'outil. Je m'occuperai d'écrire une page d'aide avec des exemples.
    • Pour les très gros Flowcharts, les éditeurs n'auront virtuellement pas le choix de passer par le wikicode.
  • Je crois que la syntaxe présente est très adéquate et suit la logique du Wikicode.
  • D'après mon analyse rapide, la génération de noeuds invisibles pour forcer le niveau d'un noeud est facilement codable. Je me suis d'ailleurs appliqué à le faire, mais ce n'est pas encore fonctionne.
Mattéo Delabre (discussioncontributions)

Merci pour ton retour Antoine.

  • Je suis d’accord pour rounded, j’ai modifié le défaut en ce sens.
  • Concernant l’éditeur visuel, je vais me renseigner, ce sera une bonne occasion pour moi d’en apprendre davantage sur son fonctionnement.
  • OK pour la documentation.
  • Merci pour les nœuds invisibles. J’ai fouillé un peu dans la bibliothèque sous-jacente qui s’occupe du layout, Dagre, et il y a un paramètre minlen qui permet de forcer un nombre d’« étages » minimum que doit occuper un lien. Seulement, ce paramètre n’est pas exposé par Mermaid, je vais voir si je peux contribuer un patch pour permettre ça. Je pense que ce serait une solution plus robuste à long terme que les nœuds invisibles.
Mattéo Delabre (discussioncontributions)
Antoine Mercier-Linteau (discussioncontributions)

Wow! Merci infiniment, je te donne mes commentaires bientôt. J'ai brûlé tout mon temps de codage sur la recherche d'une solution pour faire fonctionner les flowcharts dans les discussions. Il semble que ce soit un conflit entre l'extension Flow (pour la discussion) et Mermaid où Flow interfère avec les librairies chargées par Mermaid.

Afin de pallier à ce problème, j'ai forcé le chargement de l'extension dans MediaWiki:Common.js. Très bancale, vu que c'est exécuté pour chaque page. Et en plus, ça ne fonctionne même pas à tout coup. Un bogue a été soumis auprès des développeurs de l'extension.

Mattéo Delabre (discussioncontributions)

Merci d’avoir pris le temps de regarder ça ! Je ne sais pas si c’est lié à mon setup, mais on dirait que le texte du flowchart ne charge pas sur les pages de discussion. Voici comment ça s’affiche chez moi :

Antoine Mercier-Linteau (discussioncontributions)

Oui, j'ai vu ça à quelques reprises. De mon côté, avec un refresh ça finit par s'afficher correctement, ce qui laisse présager un problème de timing. D'autant plus que ça semble s'améliorer en ajoutant un délai sur l'exécution du code. Bref, ma solution est vraiment bancale. En espérant que les développeurs pourront régler le bogue. Entre-temps, j'ai fait passer le délai de 1 à 3 secondes, est-ce que ça corrige le problème chez toi?

Ceci dit, ce n'est pas très handicapant pour le moment vu que seulement les pages de discussion sont affectées. Je vais quand même garder un oeil ouvert.

Mattéo Delabre (discussioncontributions)

Malheureusement, le délai ne corrige pas le souci chez moi, en fait il n’y a que deux résultats que j’observe : soit rien ne s’affiche, soit le flowchart s’affiche sans les étiquettes — je n’ai jamais le rendu correct. Effectivement, comme tu le soulignes, ce n’est pas un bogue urgent à résoudre.

Mattéo Delabre (discussioncontributions)

Je viens d’envoyer un patch pour Mermaid qui permet de définir la longueur d’un lien entre deux nœuds (en termes du nombre de niveaux qu’il traverse), et donc de contrôler la hauteur des nœuds sans recourir à la solution de contournement qui utilise des nœuds invisibles intermédiaires. Si le patch est accepté, lorsqu’il paraîtra dans une prochaine version de Mermaid, et lorsque cette nouvelle version sera intégrée dans l’extension MediaWiki, nous pourrons donc ajouter une option supplémentaire dans le script Lua pour définir la longueur des liens.

Antoine Mercier-Linteau (discussioncontributions)

Excellent! J'ai codé le support de longueur entre les noeuds dans notre module Lua avec la technique de contournement. Malheureusement ça bogue. Il faut que je me penche dessus. Si tu as 2 secondes j'apprécierais que tu y jettes un oeil.

Mattéo Delabre (discussioncontributions)

Merci d’avoir programmé ça ! Je viens de passer en revue le code et j’ai trouvé les bogues suivants :

  • Ligne 240 : nodes.tonodes[to].
  • Ligne 242 : Condition inversée, doit être and au lieu de or.
  • Ligne 267 : La variable i n’est pas accessible hors de la boucle.

En l’état, l’utilisation d’une valeur de 1 pour la propriété level causait l’insertion de deux nœuds invisibles, une valeur de 2 en causait trois, etc. Je pense que ce n’était pas voulu, alors j’ai réduit ça pour que 1 insère zéro nœuds, 2 insère un nœud, etc. Voici un petit exemple d’utilisation de la propriété :

Code

{{Flowchart
| $orientation = to right
| N0 -> N1 = 1
| N1.level = 1
| N1 -> N2 = 2
| N2.level = 2
| N2 -> N3 = 3
| N3.level = 3
| N0 -> P1
| P1 -> P2
| P2 -> P3
| P3 -> P4
| P4 -> P5
| P5 -> P6
}}

Rendu

Concernant le nommage de la propriété level, j’ai quelques réserves. On pourrait croire qu’avec elle, on contrôle le niveau absolu du nœud, alors qu’en fait on contrôle la longueur minimale de tous les liens qui amènent à ce nœud (liens entrants). Peut-être qu’un nom comme distance (comme « distance aux nœuds parents ») serait plus clair ?

Il nous faut également faire le choix entre une propriété level/distance au niveaux des nœuds contre une propriété length au niveau des liens qui permettrait de régler leur longueur individuellement. Avec la première propriété, il n’est pas possible dans certains cas de contrôler la longueur d’une arête individuelle. À l’inverse, avec la seconde, le code peut être plus verbeux si on veut en effet contrôler la longueur de tous les liens entrants. Je serais personnellement pour la seconde car elle offre plus de flexibilité.

PS. Entre temps, le patch a été accepté et fusionné dans Mermaid ! On peut donc espérer voir arriver une solution plus directe pour implémenter les propriétés en question à l’avenir.

Antoine Mercier-Linteau (discussioncontributions)

Merci! Je suis d'accord aver toi pour renommer le paramètre à distance.

Toutefois, j'ai du mal à imaginer ce que différentes longueurs de lien entrants pourrait représenter. En construisant ce genre de graphique, la conception se fait davantage au niveau des boîtes que des liens (je ne sais si je suis clair). Je crois que de pouvoir régler la longueur des liens risque de plus être mêlant pour les utilisateurs.

Est-ce que les deux options sont mutuellement exclusives?

Mattéo Delabre (discussioncontributions)

Effectivement, je ne vois pas non plus de cas où la longueur des liens pourrait être porteuse d’une information sémantique. En revanche, il y a des cas où on peut vouloir aligner des boîtes sur le même niveau, comme avec l’exemple ci-dessous que tu avais trouvé sur le web :

http://guidelines.diabetes.ca/app_themes/cdcpg2018/images/Ch13-Fig1A-management-of-hyperglycemia.png

Ici, si on veut recréer une structure similaire, on peut obtenir ça :

{{Flowchart
| Start -> A
| A -> A2
| A2 -> End
| Start -> B
| B -> End
| Start -> C
| C -> C2
| C2 -> End
}}

Sauf que par défaut, B se retrouve au niveau de A2 et C2, alors qu’on voudrait qu’il soit au niveau de A et C. Une solution pour forcer ça est de faire en sorte que le lien entre B et End soit de longueur 2. Dans ce cas, on veut bien contrôler uniquement la longueur du lien de B vers End, mais pas celle des autres liens qui vont vers End.

Cela dit, comme tu le soulignes très justement, les deux options sont compatibles, on peut voir distance comme un raccourci qui définit length pour tous les liens entrants sur la boîte où la propriété est appliquée.

Antoine Mercier-Linteau (discussioncontributions)

@Michaël St-Gelais, @Mattéo Delabre, voici des cas d'usage de diagrammes. Michaël a pris des photos des textbook de dermatologie. Pour des raisons de droit d'auteur, je n'irai pas les reproduire ici. À notes que ce ne sont pas tous des algorithmes cliniques. Plusieurs diagrammes sont trop complexes et devront être définis comme images. Sont particulièrement d'intérêt: 1, 2, 3, 24 (ACLS).

Sinon voici de mes exemples trouvés sur le web:

Michaël St-Gelais (discussioncontributions)

Des aspects importants :

  • pouvoir changer la direction des flèches ;
  • pouvoir diriger une flèche vers n'importe quel champs ;
  • pouvoir intégrer des images simples (pas comme dans certaines images du lien sync ci-haut) ;
  • pouvoir changer les couleurs et la mise en page des bulles et du texte.

Merci infiniment Matteo pour ton aide. Je l'apprécie énormément et je t'en suis très reconnaissant.

Mattéo Delabre (discussioncontributions)

Avec plaisir ! Merci pour tes précisions et photos qui nous seront fort utiles dans le choix de la solution à mettre en place.

Antoine Mercier-Linteau (discussioncontributions)

@Alexandre Beaulac, peux-tu regarder les cas d'usages mentionnés ci dessus et voir si tu en connaîtrait d'autres?

Alexandre Beaulac (discussioncontributions)

Salut! Je crois que c'est pas mal complet, mais il faudrait penser à rajouter également deux graphiques/diagrammes classiques : celui des articulations (le bonhomme allumette avec les ronds) et aussi celui de l'abdomen divisé entre quatre quadrants. J'ai pris la peine de vérifier et c'est sans droit d'auteur; au pire des cas, on peut en confectionner de par nous-mêmes. Il faudrait aussi rendre disponible (si ce ne l'est pas déjà) les diagrammes en rond (pour montrer les étiologies par exemple selon leur « pointe de tarte » respective). C'est particulièrement utile pour résumer.

Antoine Mercier-Linteau (discussioncontributions)

Bonne idée pour les pointes de tartes, cette fonction est d'emblée disponible dans la librairie graphique choisie, alors la faire fonctionner ne représentera pas trop de travail.

Michaël St-Gelais (discussioncontributions)

Tu as d'excellentes idées. Pour les articulations, pour la localisation cutanée et pour les quadrants abdominaux, ce sera probablement des modèles séparés. Qu'en penses-tu @Antoine Mercier-Linteau ?

Antoine Mercier-Linteau (discussioncontributions)

Effectivement, les diagrammes avec des graphiques complexes comme des images d'abdomen, de bonhommes allumettes relèvent plus du graphisme et seraient compliqué à coder avec ce système et demanderont donc un modèle séparé. Il nous sera possible par contre d'automatiser leur présentation sans trop de difficultés techniques.

Résumé par Mattéo Delabre

mxGraph/Draw.io n’est pas la solution la plus adaptée pour les algorithmes cliniques car elle n’a pas de dimension sémantique, est incompatible avec Wikicode et ne permet pas de garantir une apparence uniforme des diagrammes. Par ailleurs, la bibliothèque sera difficile à intégrer avec MediaWiki et son état de maintenance est douteux.

Mattéo Delabre (discussioncontributions)

@Antoine Mercier-Linteau Je poursuis dans ce fil notre discussion spécifique à l’intégration de mxGraph. Bien qu’il soit tout à fait vrai que cette librairie est en mesure d’exporter les graphiques en format SVG, il me semble qu’elle n’est pas capable de charger un diagramme existant qui serait stocké au format SVG. Au contraire, elle semble utiliser un format XML qui lui est spécifique.

Donc je crois qu’il va être nécessaire d’ajouter au moins une légère couche de backend pour pouvoir l’intégrer : on pourrait stocker le diagramme sous forme de XML dans le Wikicode de la page, et faire une extension qui s’occupe de convertir ce XML en SVG pour l’affichage, ou de le charger dans l’éditeur visuel pour la modification.

Antoine Mercier-Linteau (discussioncontributions)

Je crois que tu as raison. D'ailleurs, je crois que l'extension DrawioEditor fonctionne de cette manière. Elle utilise cependant un service externe pour l'édition des diagrammes. Veux-tu que je l'installe pour qu'on la teste?

En stockant le diagramme au format XML et en le convertissant en SVG nous pourrions y intégrer du wikicode qui serait interprété lors de la génération.

Mattéo Delabre (discussioncontributions)

Oui, je pense que ça vaut le coup de tester DrawioEditor, au moins pour se faire une idée de son fonctionnement.

Je suis un peu partagé sur le fait que ça crée une dépendance sur Draw.io. Une question notamment à laquelle je n’ai pas encore de réponse : est-ce que l’extension stocke les diagrammes en local et utilise Draw.io uniquement pour l’édition, ou bien est-ce qu’elle s’en remet totalement à ce service pour l’enregistrement des diagrammes ?

Dans ce dernier cas, je pense que ce n’est pas une bonne solution, puisqu’on prend le risque que les pages utilisant des flowcharts soient illisibles lorsque Draw.io est en panne, voire de perdre les données si un jour le service vient à être arrêté.

Très intéressant ta remarque sur le wikicode, effectivement je pense que ça doit marcher, et si c’est bien le cas ça ouvre des possibilités attrayantes, on peut penser par exemple à faire des liens vers d’autres pages du Wiki dans les diagrammes.

Mattéo Delabre (discussioncontributions)

J’ai effectué des tests de l’extension sur mon instance locale et voici quelques informations supplémentaires :

  • Les diagrammes sont stockés en local sur le wiki. Il n’y a pas de dépendance sur Draw.io pour leur affichage mais uniquement pour leur édition.
  • L’extension définit un tag {{#drawio:NomDuDiagramme}} qui prend en paramètre un nom devant être unique à travers tout le wiki. Ce nom définit le nom du fichier dans lequel le diagramme est enregistré dans le répertoire des images. Avantage : On peut facilement réutiliser un même diagramme sur plusieurs pages en utilisant simplement le même nom. Désavantage : Il faut prendre soin de ne pas créer de collision sur les noms.
  • Il ne semble pas y avoir d’intégration avec l’éditeur visuel. Pour invoquer l’éditeur Draw.io, il faut cliquer sur un lien « Modifier » à côté de l’encart du diagramme sur la page de lecture.
  • À moins d’ajouter l’extension NativeSvgHandler (qui injecte les images SVG directement dans le corps des pages au lieu de faire un rendu PNG préalable), je n’arrive pas à éditer les diagrammes après leur création initiale.
  • Sur Firefox, j’ai un bogue d’affichage des diagrammes quand ils sont affichés directement en SVG : le texte n’apparaît pas. En revanche, quand les diagrammes sont affichés sous forme de PNG (en l’absence de l’extension NativeSvgHandler, donc), il n’y a pas de problème.
Antoine Mercier-Linteau (discussioncontributions)

Bon réflexe d'avoir testé si l'affichage des graphes était dépendant du service Draw.io. Je crois qu'on peut déployer un MxGraph en local. Draw.io semble être l'équivalent délocalisé.

Il y aurait moyen de modifier l'extension pour que le diagramme soit entièrement intégré à la page. Ceci dit, je suis vraiment ambivalent... l'intégrer à la page et fournir toutes les fonctions d'édition à partir de là est plus intuitif pour les éditeurs. En revanche, considérer le diagramme comme un fichier est plus conforme à la manière de faire wiki.

Comment l'extension s'y prend pour créer un nouveau diagramme?

Mattéo Delabre (discussioncontributions)

Je crois qu'on peut déployer un MxGraph en local. Draw.io semble être l'équivalent délocalisé.

Veux-tu dire déployer un serveur spécifique pour MxGraph et modifier l’extension DrawioEditor pour faire pointer vers ce serveur au lieu du serveur https://draw.io ? Ça devrait être possible. Mais j’ai l’impression que ce serait peut-être moins de charge au niveau infrastructure si on intégrait directement la bibliothèque MxGraph dans la partie interface d’édition de l’extension.

Comment l'extension s'y prend pour créer un nouveau diagramme?

Voici les différentes étapes nécessaires à la création d’un diagramme avec l’extension DrawioEditor en l’état actuel.

1. Ajout d’une balise {{#drawio:…}}, portant un nom unique, dans une page.

2. Un bloc de substitution apparaît à l’endroit où a été insérée la balise dans la page, portant un lien “Modifier”.

3. En cliquant sur ce lien “Modifier”, on accède à l’interface d’édition du site https://draw.io, chargée à travers une <iframe>

4A. Après sauvegarde, le diagramme apparaît sur la page…

4B. …et un fichier portant le nom choisi pour le diagramme est créé, avec pour contenu le diagramme au format SVG.

Il y aurait moyen de modifier l'extension pour que le diagramme soit entièrement intégré à la page. Ceci dit, je suis vraiment ambivalent... l'intégrer à la page et fournir toutes les fonctions d'édition à partir de là est plus intuitif pour les éditeurs. En revanche, considérer le diagramme comme un fichier est plus conforme à la manière de faire wiki.

Que manquerait-il selon toi pour que le diagramme soit entièrement intégré à la page ? Veux-tu parler d’une intégration à l’éditeur visuel ? Dans l’état actuel, il semble que l’extension fournisse un compromis intéressant entre les deux voies que tu soulignes, puisque le diagramme est considéré comme un fichier et qu’il est possible d’éditer le diagramme depuis les pages qui l’utilisent. (D’ailleurs, je trouve dommage qu’on ne puisse pas éditer le diagramme depuis la page du diagramme en lui-même.)

Mattéo Delabre (discussioncontributions)

J’ai pris quelques heures cet après-midi pour fouiner dans le code source de mxGraph et étudier la possibilité de l’intégrer directement dans une extension MediaWiki afin que tout se fasse en local.

C’est tout de même une grosse machine, avec environ 50 000 lignes de JavaScript écrites selon les standards JavaScript de 2012 (notamment, beaucoup de variables globales qui fuitent) et avec une documentation assez lacunaire. Une intégration en l’état dans MediaWiki, qui a ses propres mécanismes incompatibles pour la gestion du JavaScript, me paraît donc complexe. De ce que j’ai pu voir sur le web, il y a beaucoup de demande pour une bibliothèque équivalente plus “moderne”, mais je n’ai rien trouvé d’existant et la compagnie qui chapeaute le développement de mxGraph (JGraph) n’a pas l’air intéressée par cette démarche.

Donc, si on veut poursuivre avec mxGraph sans dépenser ce qui serait plusieurs dizaines d’heures dans une intégration au sein de MediaWiki, je pense que ton idée de déployer mxGraph sur un serveur séparé et de le charger à travers un <iframe> est la meilleure piste que nous ayons à notre disposition. Ça tiendrait juste à modifier légèrement l’extension DrawioEditor pour pouvoir modifier l’URL du serveur et à vérifier que tout fonctionne, ce que je vais essayer de faire sous peu.

Antoine Mercier-Linteau (discussioncontributions)

Merci pour l'analyse! Nous n'aurions donc pas vraiment le choix de passer par un service dédié, l'option de l'avoir directement dans MediaWiki est comme tu le dis demandera trop de travail d'intégration, sans compter le fait qu'il sera désormais difficile de tenir la librairie à jour car il faudra merger le code à la main.

Ceci dit, je commence à douter que l'utilisation de MxGraph/Draw.io soit la meilleure manière de procéder. Voici les raisons:

  • Tel que mentionné ci-dessus, d'avoir les graphiques stockés comme fichiers est la manière wiki de faire, mais cela nous empêchera de leur appliquer le même niveau de contrôle éditorial que sur les pages. À mesure que l'information contenu dans les diagrammes deviendra critique (algorithmes, dosages, etc.), cela deviendra problématique.
    • Pour la réutilisation ailleurs sur le wiki, nous pourrions passer par les inclusions.
  • J'ai l'impression que dans le futur, nous allons être pris au dépourvu avec une cessation du support pour la librairie ou des incompatibilités.
  • Le suivi des modifications (historique) sur les fichiers est fait pour les images. On peut accéder aux différentes versions, mais les comparer ensemble et savoir qui a modifié quoi est très difficile.
  • L'utilisation de MxGraph va rajouter un workflow supplémentaire aux éditeurs.
  • C'est complètement incompatible avec le wikicode.
  • MxGraph offre une interface WYSIWYG et génère des beaux diagrammes, mais l'intégration d'éléments sémantiques, liens, images etc à l'intérieur sera problématique.
  • Nous allons avoir besoin d'un contrôle très strict sur l'apparence des diagrammes afin qu'elle soit uniforme sur toute la plateforme. MxGraph donne potentiellement trop de latitude aux éditeurs.

Il y aura possiblement une place pour MxGraph sur la plateforme, mais pas pour les algorithmes cliniques. Ces derniers demandent trop de formalisme.

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)

Michaël et moi allons également passer en revue plusieurs diagrammes en médecine afin d'établir les cas d'utilisation.

Mattéo Delabre (discussioncontributions)

Je suis d’accord avec tes points. L’idée de monter en abstraction au niveau de la syntaxe est très bonne.

Résumé par Mattéo Delabre

Utilisation de Draw.io ou de la bibliothèque mxGraph utilisée par Draw.io.

Antoine Mercier-Linteau (discussioncontributions)

@Mathieu Salaün, voici la tâche dont je te parlais. Elle est facile à accomplir, car elle n'implique aucune programmation. Pour le moment, il s'agit de faire une recherche afin de trouver un module qui pourrait être intégré tel quel (une extension MediaWiki) ou qui pourrait être modifié.

J'ai précisé les besoins du module dans la description de la tâche. Tu peux aussi consulter l'archive de discussion ci-dessous.

Mathieu Salaün (discussioncontributions)
Antoine Mercier-Linteau (discussioncontributions)

Merci Mathieu!

En passant, tu n'as pas besoin de taguer les gens lorsque tu leurs réponds directement :) Autrement, ne perds pas ton temps à rechercher la solution que WikEM a adopté, c'est hautement amateur.

Sinon, j'ai fait une petite recherche rapide et j'ai colligé ça dans un tableau sur la page, tu pourras ajouter tes conclusions. MxGraph (la base de draw.io) semble très prometteur et ils offrent un éditeur à même le navigateur.

Tout ce qui est basé sur D3.js, bien que super pour la visualisation de données, ne semble pas être fait pour créer des diagrammes. À garder en tête cependant pour d'autres fonctionnalités.

Antoine Mercier-Linteau (discussioncontributions)

@Mattéo Delabre, voici l'un des projets que j'ai suggéré dans nos échanges courriels. Il n'implique pas vraiment de programmation et te permettra de te familiariser avec la plateforme. À en juger par le travail que tu avais fait (navigation interactive du diagnostic différentiel), je crois que tu pourrais nous être d'une grande utilité dans notre choix d'une bonne librairie d'édition d'algorithmes cliniques. Je t'ai mis un exemple tiré de la page sur l'embolie pulmonaire (PNG) à droite.

Dans la description de la tâche, tu trouveras les besoins que cette librairie devra remplir. Tous ne sont pas obligatoires sauf l'intégration avec l'Éditeur Visuel. Il existe déjà plusieurs extensions permettant la création de graphiques, mais toutes fonctionnent uniquement avec du Wikicode.

Moi et Mathieu avons listés quelques options ci-dessus, je ne sais pas si tu en connais d'autre?

Mattéo Delabre (discussioncontributions)

Je n’ai pas connaissance d’autre option pour faire des flowcharts similaires à celui que tu as joint. La première qui m’est venue à l’esprit est Mermaid, mais je vois dans l’archive de discussion ci-dessous que tu l’as déjà mentionnée — et malheureusement je pense comme toi qu’il n’existe pas d’éditeur graphique pour Mermaid.

Pour moi, si on veut respecter la contrainte 5 (pas de backend), il faudrait que le langage de sortie soit du SVG ou du HTML, les seuls qui ont l’avantage d’être compris nativement par la quasi-totalité majorité des navigateurs (pour SVG, 95% des utilisateurs selon caniuse). Autrement, on va devoir ajouter une couche de JS sur toutes les pages qui contiennent de tels graphiques pour pouvoir convertir leur forme textuelle en forme visuelle. Cela contraindrait les lecteurs et lectrices du wiki à activer JavaScript pour pouvoir voir les figures (et non pas seulement pour les éditer), et il est possible que les moteurs d’indexation aient plus de mal à accéder à ce contenu que s’il était sous forme de SVG. Je ne sais pas ton opinion là dessus, mais ça ne me semble pas souhaitable.

Antoine Mercier-Linteau (discussioncontributions)

J'abonde dans le même sens que toi. Nous devrions privilégier une solution SVG.

Je me suis un peu repenché sur la question et c'est vrai que Mermaid est plutôt élégant comme solution. Si nous avions affaire à un public habile avec la technologie, c'est la librairie que j'aurais choisi.

Je crois donc que Draw.io / MxGraph est la meilleure solution. Également, on devrait pouvoir l'intégrer sans trop de difficulté à l'ÉditeurVisuel.

Mattéo Delabre (discussioncontributions)

J’ai trouvé une page sur le site de MediaWiki qui liste les extensions existantes pour créer des diagrammes, dont j’ai repris la table dans la description de cette tâche en l’adaptant pour enlever les extensions qui ne correspondent pas à nos besoins (par exemple il y a des extensions pour générer des diagrammes de jeux d’échecs ou de Go) et ajouter quelques infos supplémentaires. Il y a notamment Cognitive Process Designer qui semble intégrer un éditeur visuel si on en croit sa documentation (je ne l’ai pas encore testée).

Antoine Mercier-Linteau (discussioncontributions)

Belle trouvaille ce Cognitive Process Designer. C'est une manière beaucoup plus formelle de créer des diagrammes et ça l'irait très bien s'intégrer avec la structure sémantique de Wikimedica. L'outil semble complexe d'approche pour un néohpyte, donc le besoin pour un outil de génération de diagrammes simple demeure, mais Cognitive Process Designer pourrait être utilisé à terme pour générer des workflows complexes.

Mattéo Delabre (discussioncontributions)

Tout à fait—je pense qu’on est d’accord sur le fait de partir sur Draw.io/mxGraph pour la génération de diagrammes, je vais donc marquer ce fil comme résolu.

Il n’y a aucun sujet plus ancien