Nous avons des problèmes de performances à l’ouverture des gros modèles (une centaine de nodes) : ça prend environ 20 secondes, les utilisateurs commencent à cliquer partout et ça plante le navigateur.
La latence est entre le open du SVG et le callback, à la sortie du ok() mais je n’arrive pas à aller plus loin dans l’analyse.
Est-il possible de faire quelque chose ? Car en l’état on peut difficilement utiliser le moteur SVG, nos modèles vont être de plus en plus gros.
C’est un code front en JS, l’ouverture du modèle même en mode silencieux commence par synchroniser les données de chaque node : ça va faire N requêtes Ajax que tu dois pouvoir observer au debugger du navigateur / network. Ca doit prendre un certain temps de traitement, même en asynchrone et finir par bloquer le navigateur s’il y en a trop.
Les diagrammes n’ont pas été conçus pour afficher des 100aines d’objets, mais plutôt des modèles métier humainement lisibles.
Un modèle est un fichier SVG standalone = qui contient tous les libellés fonctionnels. Il n’y a pas de mise à jour au fil de l’eau des libellés quand on met à jour la base. Le modeleur actualise donc à l’ouverture le modèle tout ce qui est affiché (1 requete par node).
Il faudrait à mon avis faire évoluer le modeleur :
ajouter une option d’ouverture sans re-synchronisation, mais avec le risque de ne plus avoir les bons libellés.
ça implique alors de revoir la mise à jour des SVG en back quand un objet est lié à des modèles, il faut mettre à jour les SVG au fil de l’eau.
et avoir du coup des API en back pour manipuler un modèle SVG = plus besoin de le faire en front, tu pourrais ajouter un Node dans un postSave et le supprimer dans un postDelete
Je peux regarder ça en V5, mais pas sur qu’on puisse le backporter en V4.
Un passage en V5 est il prévu ?
En effet je serais très intéressée par la possibilité de mettre à jour le SVG en back à chaque fois qu’on modifie un élément car nos modèles n’étant pas standard, actuellement je vérifie les ajouts et suppressions à l’ouverture ce qui ajoute du délai. On est justement en train de passer en V5
Ok merci pour ton retour,
on va reprioriser ce besoin car ça fait longtemps qu’il revient périodiquement.
En soit, on peut déjà manipuler le modèle en back car ça reste un fichier SVG textuel.
Mais ça reste un effort de dev important, donc autant le mutualiser avec des API simples de mise à jour.
pour ajouter / déplacer / actualiser / retirer un objet ou un container + algo de positionnement…
On peut livrer l’option “d’ouvrir sans actualiser” rapidement côté front. Pour les API back, ce sera un peu plus long à développer.
D’accord, tu aurais une estimation du délai de livraison pour le code back ? Pour qu’on voie si ça vaut le coup de faire le dev de notre côté en attendant car c’est un peu bloquant, on est en phase d’onboarding et ça impacte nos démos.
Ca sera suffisant dans un premier temps pour avoir des perfs acceptables lors d’une mise à jour avec ouverture silencieuse du modèle. Par contre il y aura toujours une latence à l’ouverture d’un diagramme sur la UI pour actualiser/dimensionner les 100 objets.
Pour la partie back, la difficulté sera de réimplémenter en Java la méthode SVG getBBox qui calcule la dimension d’un contenu SVG (text / rect…) et récursivement la taille d’un node, il doit surement exister des lib Java. Pour le reste ce sera facile car c’est de la manipulation de fichier XML pour insérer ou retirer des éléments. Donc je dirai courant Janvier pour avoir un premier niveau d’API. Tu auras de toute façon les même difficultés à l’implémenter à la main.
Top merci, courant Janvier c’est parfait, on aura migré en 5.2.
Est-ce que quand on clique sur le bouton rafraîchir du modèle ouvert sans synchro, cela lancera l’actualisation ?
