Hello,
Quelques tests rapides et ça me semble plutôt concluant 
Parfait, ça évitera de devoir modifier tous les widgets et on y gagne en évitant les timeouts et les doublons de js comme actuellement !
Hello,
J’ai pas tout compris de vos échanges. Au final la modification du core proposé par @Phpvarious permettrait de ne plus avoir à utiliser de setTimeout et sans utilisation de la fonction de @noodom ou bien il la faudra quand même ?
C’est bien ça :
- Les widgets actuels peuvent rester identiques avec des includes classiques de js :
<script src="core/php/getJS.php?file=3rdparty/highstock/modules/solid-gauge.js"></script> - Si tu as plusieurs équipements lié à un même widget (ou même différents widgets qui incluent les fichiers js) dans ton dashboard ou ton design, tu n’auras pas les fichiers js ajoutés dans ta page courante Jeedom autant de fois que tu as d’équipements liés à ce(s) widget(s), mais un seul include par fichier js.
- Tu n’as plus besoin de déclarer un timeout (avec un délai arbitraire et « aléatoire ») pour attendre le chargement du fichier js avant d’afficher ton équipement lié au widget
- Tu pourras ta passer du jquery pour les includes des fichiers js
Merci pour le résumé, c’est très clair.
Restera à bien arriver à suivre quand cette proposition de code finira par passer en stable histoire de modifier son plugin en conséquence puisque pour ma part j’ai commencé (et vais bientôt finir) à incorporer ta fonction 
Oui, il risque d’y avoir quelques transitions à gérer…
Avec les users sur d’anciennes versions de jeedom ou de widgets… 
L’avantage de la modification côté core, c’est que ça ne modifie pas les widgets actuels. L’avantage de la modification côté widget, c’est que ce n’est pas dépendant du core (mais ça reste plus court terme).
On peut pas tout avoir et tout compatible en même temps
Hello,
En faite, j’ai pas PR pour le moment, car j’aurai préféré que la team se manifeste sur ce sujet.
Même si cela fonctionne, j’ai tout de même l’impression que j’ai fait un bricolage, mes connaissances me permette pas de faire plus « propre ».
@noodom a bien résumé ce qu’apporterai cette modif, en revanche, il est possible que cela ralentisse l’affichage du design, car tout devient synchrone.
N’utilisant que très peu les design, je peux pas le constater.
Et il y a aussi la fonction domUtils.DOMparseHTML, qui est utilisé seulement en design, me fait pensé quelle a été créée pour une raison bien spécifique, et qu’il y a peut-être un truc qui m’échappe…
Bonjour
Je découvre des sujets au fur et à mesure…
Je vous invite à lire mon approche ici
[edit 29/11] approche testée et validée, je publie prochainement [/edit]
[edit 06/12] pour information, evohome 0.6.0 publiée [/edit]
A bientôt
Hello,
Merci pour ce retour, j’ai regardé ton approche…
c’est du lourd 
, c’est carrement une lib le truc 
.
Pour ma part, vu que je suis plus dashboard que design, j’ai abandonné l’idée d’utiliser des imports dans mes design.
Dommage que la team ne se soit pas manifesté sur ce point…
1 « J'aime »
Une microlib alors, c’est juste le pattern publish/subscribe dédié et simplifié 
Cela garantit un seul include par JS et une séquence d’initialisation ultra optimisée et universelle.
- avant 4.4, le premier widget déclenche le load qui a lieu immédiatement et son subscribe termine l’init.
Les autres s’init sans délai avec la lib marquée comme déjà chargée - à partir de 4.4 (ou disons le problème de load différé) , le 1er widget déclenche le load, souscrit, et reste en attente ; les autres widgets ne refont pas le load et se contentent de souscrire. Lorsque le JS est loadé, sa dernière instruction appelle le publish, et tous les widgets qui ont souscrit voient leur init se terminer.
Un peu plus subtil dans les faits vu que j’ai 2 includes mais c’est le principe.