Alors tu peux aussi essayer de la remettre au début en enlevant core/php/getJS.php?file= :
<script src="3rdparty/highstock/modules/solid-gauge.js"></script>
<div class="cmd cmd-widget" data-type="info" data-subtype="numeric"....>
// et le reste de ton code actuel à la suite
Le souci n’est peut être même pas là, je cherche mais ne crois pas me souvenir d’avoir eu de problèmes sur les designs quand j’avais testé ça.
@Salvialf ça ne change rien en enlevant core/php/getJS.php?file=
Après ça vient peut-être de modifs dans le core au niveau des design. il y a quelques soucis avec le passage en 4.4 (cf mon souci d’erreur 401 qui a été debug hier et sera publié dans la prochaine version) donc peut-être des corrections à venir qui feront remarcher cette partie.
Petit test intéressant
j’ai remplacé type: 'solidgauge', par type: 'gauge', dans le code et je n’ai plus l’erreur dans la console, le graph s’affiche bien au F5 même si il est très moche par rapport à celui de solidgauge.
Donc ça doit venir de 3rdparty/highstock/ dans le core qui à du être MAJ et qui n’est plus complet ou bien un paramètre qui manque maintenant dans l’appel de Highcharts.
Je vais essayer de regarder la doc de Highcharts et faire des essais
j’ai ajouté ces lignes dans desktop/custom/custom.js
var script = document.createElement("script"); // create a script DOM node
script.src = "3rdparty/highstock/modules/solid-gauge.js"; // set its src to the provided URL
document.head.appendChild(script); // add it to the end of the head section of the page
et le graph fonctionne même au F5.
Donc je pense que les includes de <script> dans la page des design ont changés et n’inclus plus solid-gauge.js donc bien un souci dans le core selon moi
Je ne connais pas bien l’environnement de dev de Jeedom, tu as probablement raison.
en tout cas mon script marche, c’était donc un <script> manquant dans le <header> qui bloquait au refresh
Bonjour
Problématique récurrente et , sauf erreur, sans solution claire de la part de la Team Jeedom.
Pour les besoins du plugin evohome, je suis en train de finaliser une approche d’import dynamique (document.head.appendChild) combiné à un système Publish (en fin du JS importé) / Subscribe (dans le HTML d’appel ayant besoin des fonctions du JS importé).
Peu pour moi de mettre un timeout avec une durée au doigt mouillé, ce ne peut être une solution pérenne.
J’avais tenté document.body.appendChild, mais très curieusement cela fait planter Jeedom qui part en 100% IO et quasi 100 en cpu !!
Test à venir sur la conf d’un user en 4.4 (n’ayant pas encore pris le temps de migrer).
A suivre 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]
Salviaf : pas un problème core ?
Tu m’en vois très surpris.
Passer de 4.3 à 4.4 provoque très clairement une bascule en loading asynchrone (defer ? asynchrone ?) des JS effectués par un include standard, sans que l’on voit ce genre d’attribut dans la ligne d’inclusion de la page html rendue.
C’est assez déconcertant…