Inject script widget sur design

Salon des Bêta-Testeurs Core V4 (BugsReports)
1

Bonsoir,
Pas vraiment un bug, juste un constat.

je rebondit sur ce post :

J’ai effectué quelque test et il semble qu’il ne faut plus rien mettre avant ou après
<div class="eqLogic-widget " ...></div>
sinon une erreur se produit :

image
image1776×95 5.46 KB

Exemple pour pour le plugin thermoAlternateView, il charge :
<script type="text/javascript" src="plugins/thermoAlternateView/core/template/script2.js"></script> avant le div se qui a effet de ne pas charger le script

Autre chose que j’ai remarqué ,
on dirait que les js ne sont pas injecté dans l’ordre codé dans le widget, c’est aléatoire.
Exemple : un $(document).ready(function () {... ne semble pas s’exécuter après chargement de la page…

J’ai laissé quelque trace que j’ai numéroté dans le widget :
image

2

On a essayé d’y pallier en hackant la fonction jquery en effet. Les js sont bien injectés de manière synchrone et dans l’ordre. Mais comme on n’utilise plus les appels ajax de jQuery, il est perdu le pauvre, donc sont $(document).ready() ou $(function(…)) sont paumés.

Si tu a envie de fouiller, le hack : core/desktop/common/js/utils.js at alpha · jeedom/core · GitHub

Tu peut essayer d’augmenter le timeout, sait ton jamais… le Core 4.4 va trop vite…

Et le domeutils ready : core/core/dom/dom.utils.js at alpha · jeedom/core · GitHub

Un cas d’utilisation : core/desktop/js/scenario.js at alpha · jeedom/core · GitHub
Y’en a que 2 dans tout le core, comme le load des js est synchrone et ordonné, y’en a plus vraiment besoin.

3

Etonnant car les console.log ne sont pas dans l’ordre dans mes tests :thinking:

4

Tu est en pur js partout ?

Si tu veux fouiller :

5

non je part de l’exemple de thermoAlternateView que j’ai, mais on peut penser que plusieurs plugins chargent du Js, donc sa cassera les widget quand la 4.4 sortira.

6

Dans le Hijack j’ai passé la tempo a 1000

a chaque actualisation du design, c’est encore aléatoire, des fois je tombe dans la 1ere condition :

if (domUtils._DOMloading <= 0) {
      console.log('utils.js : domUtils._DOMloading <= 0');
      jeedomUtils.$readyFn.apply(this, arguments)
    }

et $(document).ready est exécuté aussitôt, alors que le reste du document ne semble pas encore chargé :
image

et des fois je tombe dans le setTimeout :

image

et j’ai bien $(document).ready qui intervient après la tempo.

7

J’avoue que j’aime pas trop ces méthodes je préfère les callback ou gérer dans les success des ajax. Si tu vois des choses à améliorer n’hésite pas.

Pour info comme Jeedom est en one page il n’y a plus aucun événement navigateur du style domcontentloaded etc après le 1er load.

8

Yop, tu pourrai me dire comment reproduire ?

Meme en changant le template d’un plugin, faut ajouter une lib externe en fait ?

J’ai peu etre une piste …

9

J’ai repris un template de mon plugin qivivo

si je met çà :
<script type="text/javascript" src="plugins/qivivo/core/template/dashboard/test.js"></script>
dans la div eqlogic, avant ou apres le script standard, le js est bien loadé (un simple console)

Si je le met apres, en dehors de la div, il est pas loadé.

le responsable est là je pense : domUtils.parseHTML()

Par contre dans aucun cas je n’ai l’erreur que tu met au début de ton 1er msg

10

En faite lerreur intervient car en fin de widget dans $(document).ready il y a un appel a une fonction qui est load dans le fichier script, hors comme je l’ai dis précédemment, l’ordre semble aléatoire, donc des fois lappel a la fonction est inité avant la fonction, donc erreur js en sortie.

11

Et c’est bien que sur un design ?

12

Oui que sur design.

13

C’est lui le probleme, lui n’est à mon avis pas synchrone/ordered, pas prévue pour. Mais c’est la fonction utilisé par le js du design.

Ce qui fait dire m…e, mais corrigeable :sneezing_face:

14

Tu me met le doute :sweat_smile:, en faite je croit pas que jai vérifier si le soucis est que en design… je test en fin de journée si tu veux.

15

Je confirme, aucun soucis en dashboard.

16

Oui faut que je me penche dessus.
Par contre un tag script en dehors de la div, je pense que çà ne marchera pas …

17

@Phpvarious

Je viens de pousser un fix qui devrait:

  • Supporte les templates qui ne commencent pas par la div
  • Attends la fin du loading avant de déclencher les dom ready

:face_with_head_bandage:

18

essai concluant :+1:

on dirait que $(document).ready(function () est appelé 2x, il déclenche donc 2 fois le contenu, exemple :

$(document).ready(function () {
      console.log('ready')
    });

image

19

Oui c’est par sécurité mais les fonctions enregistrées s’exécutent qu’une fois. Normalement.

20

Ah non je viens de voir ton console. Je vais regarder mais c complexe et vraiment une m… ce truc faudrai pas utilisé ça encore un truc de jquery qui masque tout le fonctionnement et la compréhension du système.