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

Voici un lien permanent vers une version unique de ce message. Cette version a été créée 24 mai 2020. Vous pouvez voir les différences depuis la version précédente, ou bien afficher d’autres versions sur la page d’historique du message.

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.