Je vous propose un remplacement de la fenêtre actuelle permettant de sélectionner un bloc de scénario Jeedom permettant d’ajouter un bloc en 2 clics au clavier depuis un scénario :
Ouverture de la fenêtre de sélection : Ctrl + Alt + A (ou Cmd + Opt + A sur macOS)
Validation d’un code de scénario avec la saisie du chiffre associé (de 1 à 8)
Pour cela, j’ai remplacé le code de cette modale au niveau du Core de Jeedom.
Testé sur Jeedom 4.6.1 et develop.
Avant de détailler l’installation, je précise que celle-ci modifie directement des fichiers du Core Jeedom. Un mécanisme de sauvegarde est intégré afin de permettre un retour à l’état original. Mais, toute mauvaise manipulation pouvant entrainer un mauvais fonctionnement de votre Jeedom tient de votre responsabilité. Je vous engage donc à faire une sauvegarde avant installation.
Actuellement, on a cette modale pour sélectionner une commande Jeedom :
Testé ce matin (méthode d’installation par scénario) sur mon image Jeedom de test sous docker, c’est nickel !
Bien plus propre, plus moderne, sécurisé (désinstallation facile) et tellement plus pratique…
Pour ma part je suis à 100% pour l’intégrer sans modération dans les prochaines versions de Jeedom !
Bravo et merci pour ce partage !
Bonjour,
J’ai installé via scénario pour tester.
C’est très sympa comme fonctionnalité, par contre lorsque je clique pour faire un nouveau scénario sur + il n’y a aucune action et je dois recharger la page pour que le champ Nom du scénario apparaisse. Idem si je vais dans le menu scénario pour reprendre un scénario existant, aucune action d’ouverture en cliquant dessus, il me faut recharger la page.
Cordialement
Core 4.6.1 et Debian 12.15 (thème light)
Bonjour,
Si cela peut aider, je n’ai rien constaté de tel de mon côté…
La création / modification d’un scénario se passe sans problème, et je n’ai nul besoin de recharger la page à aucun moment.
Hummm…
Je l’ai installé hier, donc postérieurement au 06/09 19:46. Aussi je pense avoir la dernière version de ce fichier.
Et dans le répertoire ../desktop/js, je retrouve bien ce fichier scenario.js ainsi que la sauvegarde en .bak du fichier d’origine, créé lors de l’installation.
Donc à priori…
Je confirme que c’est bien ce fichier modifié avec la déclaration de constantes à la place des variables :
Remplacer par des var va corriger l’erreur car JavaScript va laisser faire, mais c’est à mon avis cacher le problème sous le tapis.
var est déjà beaucoup trop utilisé dans Jeedom et peut potentiellement créer des problèmes.
Pour cette partie de code, const est adapté car ces affectations ne sont pas modifiées.
Le souci, c’est que Jeedom ne recharge pas chaque toute la page du navigateur pendant la navigation et donc on se retrouve à vouloir redéclarer les const (contrairement à var qui peut être redéfini à volonté).
Par contre, j’avais fait un test rapide ce midi et j’avais fini par reproduire, mais là je ne reproduis plus
Avant de réfléchir à une correction, je voulais bien évidemment reproduire,. Sinon, ça finira en var.
Si vous avez un scénario systématique, je suis preneur
EDIT : finalement, je reproduis systématiquement sur save.
J’ai déjà eu ce cas à gérer dans mes plugins, du chargement multiples des modales, j’ai, comme toi, souhaité utiliser des const en lieu et place des var.
Le soucis vient de la navigation Jeedom de type SPA (il recharge pas tout lorsqu’on navigue de page en page ou d’onglet en onglet, mais il recharge les scripts JS), et pour ne pas avoir le soucis, il faut passer en syntaxe IIFE dans le javascript.
Un exemple :
// Protect against multiple script loads (Jeedom SPA navigation, cache, etc.)
(() => {
'use strict'
const SELECTORS = Object.freeze({
TABLE_CMD: '#table_cmd',
EQ_ID: '.eqLogicAttr[data-l1key=id]'
})
// Event delegation attaché une seule fois même si le script est réinjecté
if (!window.monitoringOpenLocationAttached) {
window.monitoringOpenLocationAttached = true
document.addEventListener('click', (event) => {
const target = event.target.closest('.pluginAction[data-action=openLocation]')
if (target) {
event.preventDefault()
window.open(target.getAttribute('data-location'), '_blank', null)
}
})
}
})() // End of IIFE protection
Pour reproduire, ferme et ouvre la modale correspondante plusieurs fois, ou change d’onglet dans la navigation jeedom (dans un plugin, passer de l’onglet d’un équipement vers ses commandes et revenir et rouvrir la modale : cela déclenche le soucis et les erreurs.
tu peux regarder le code de mes plugins (ttscast, monitoring, etc…) ils utilisent cette technique.
par exemple pour Monitoring : ICI (avec gestion aussi de l’unicité des listeners pour éviter qu’à chaque reload de la modale les listeners se mutliplient et crament des ressources pour rien, car au bout de 5 min, tu peux en avoir des dizaines de listeners chargés en mémoire
j’en étais effectivement arrivé à cette conclusion et c’est la solution sur laquelle j’allais partir,
mais sans reproduire, je ne voulais pas corriger dans le vide
Pour les listeners, en effet, le problème reste présent même avec IIFE. J’avais géré ce genre de problème sur JeeMate (et je les avais remplacé par des onClick de mémoire).
Je vais regarder ton exemple sur monitoring.
Je corrige ce que j’ai avancé avant-hier, ayant dû corriger pas mal de scénario hier, j’ai constaté aussi les mêmes comportements un peu bizarres :
La modification d’un scénario et sa sauvegarde ramène à la page principale des scénarios. Les modifications sont toutefois bien prises en compte (et heureusement !..).
Aucune action à une tentative d’ouverture d’un scénario pour édition, obligation de rafraichir la page.
Mais c’est loin d’être systématique et reproductible à chaque fois, d’où le fait que je n’avais pas constaté ce phénomène lors de mes premiers tests.
Je vois néanmoins que @TiTidom a sans doute une solution palliative à ce petit souci (merci à lui !), mais je préfère préciser quand même pour ne pas laisser de doutes sur le fait que ce problème est finalement général…
J’ai en effet prévu de mettre à jour au plus vite le github avec ce contournement pour ne pas bloquer ceux qui testent et utilisent la nouvelle fenêtre. Hélas, j’ai pas eu trop de temps de m’y remettre depuis. Je vois ce soir.
Les premiers essais de correction avec IIFE ne sont pas concluants pour l’instant. Je dois mal m’y prendre.
pou une vue plus globale tu peux regarder le code du plugin mode , mode.js . je l’ai pris comme référence depuis que j’ai repris le code de mes plugins.
Bon, je viens de comprendre ce qui posait problème dans mes tests : un simple « ; » manquant devant la déclaration IIFE : ;(function() { !
Ce qui fait que c’était interprété comme la suite du AddEventListener précédent (dû au fait que Jeedom ne met pas de ; en fin de ligne)
J’ai donc pu remettre les déclarations par des const et de mon côté, ça semble ok.
Je regarde ce soir pour supprimer les var restants pour le reste du code Jeedom initial.
Avant de détailler l’installation, je précise que celle-ci modifie directement des fichiers du Core Jeedom. Un mécanisme de sauvegarde est intégré afin de permettre un retour à l’état original. Mais, toute mauvaise manipulation pouvant entrainer un mauvais fonctionnement de votre Jeedom tient de votre responsabilité. Je vous engage donc à faire une sauvegarde avant installation.
Actuellement, on a cette modale pour sélectionner une commande Jeedom :
et merci pour ce partage ! 
