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

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.