Widget V3-V4 comment faire?

Utilisation du core de Jeedom Widgets
41

je comprends tout à fait @Loic, je bosse aussi dans l’IT :slight_smile:

mais il faut aussi se mettre à notre place, nous avons investie du temps dans jeedom.
le plugin WIDGET était un plugin officiel, vous avez fait le choix de revoir entièrement cette partie pour l’intégrer dans un outil, c’est bien mais il faudrait que ce soit un minimum transparent pour les utilisateurs qui on passer du temps sur la V3

là je suis à me demander si j’ai envie de passer des heures à tout refaire ou revenir en V3.
revoir ou refaire quelques widgets c’est une chose mais me retaper toutes les affectations des commandes, je sais pas trop quoi faire

Après si je suis le seul à avoir ce type de soucis et à les remonter, je comprendrais que vous ne vouliez pas investir plus de temps :wink:

42

C’est bien pour ça que la V3 est maintenu justement pour pas vous imposer nos choix (je suis pas sur que toute les sociétés fassent ça…) Et maintenir la V3 nous demande énormément de temps mais en faisait la v4 on savait que la migration serait lourde on l’a jamais caché et c’est clairement impossible qu’on fasse mieux que ce que tu as eu la. On peut pas gérer tout les cas chaque widget est particulièr et demanderai un traitement juste pour lui donc a moins que pour chaqu’un d’entre vous on le fasse a la main ya pas d’autres solutions que ce qu’on a mis en place.

43

oui mais la V3 vous n’allez pas la garder à vie, et vous ne faite plus d’amélioration dessous ou de modification non critique, donc on va devoir forcement passer à la V4

après, avec les modifications de @jpty et la modification dans la base pour les templates
on se retrouve avec un fonctionne pas trop mal mais nous obligeant à garder le PLUGIN WIDGET

si c’est pas un soucis pour vous et qu’il risque pas d’être supprimé un jour, ca peut être une alternative

et perso, je préfères 100x le PLUGIN WIDGET que la partie CORE de l’OUTIL WIDGET

44

Pourtant la on va reporter le nouveau backup cloud et monitoring en V3, ainsi que pas d’autre évolutions mais oui elle va disparaitre mais on la maintiendra au maximum pour vous impact le moins possible.

Et non faut surtout pas laisser le plugin widget en v4 il fait planter jeedom et peut causer de grave soucis

45

OK

une dernière question, pour bien comprendre

car l’autre solution, si il faut absolument arrête le plugin WIDGET, c’est d’utiliser la partie CODE

donc pour cela faut modifier dans template pour mettre « customtemp » au lieu de « widget » afin qu’il pointe vers le code de la partie CODE, ca ok

mais pourquoi quand je fais NOUVEAU dans CODE et que je mets un nom qui n’existe pas, il me créé bien une nouvelle entrée dans l’affichage d’une commande

alors que si je remets un nom déjà existant d’un ancien widget plugin, il récupère le code mais ne s’ajout pas dans l’affichage d’une commande ?

46

Je vais reprendre :

  • tu copie tous les code de widget dans data/customTemplates
  • tu changes tout les truc de type widget en customtemp
  • tu editer tout tes codes de widgets pour prendre en compte le nouvelle emplacement (c’est pour ca qu’on peut pas le faire en automatique car on ne sait pas faire cette partie automatiquement)

Après ca on ne recommande vraiment pas de faire ça mais plutôt d’utiliser la partie template du nouvelle outils ca c’est nous qui maintenons vous etes sur donc que ça marchera toujours sans rien avoir a faire (v5/v6 et autre). La partie code la vous aurez TOUJOURS du boulot a faire au fil des versions du core.

47

les codes des widgets sont copiés par le migration dans le data/customtemplates, pas besoin de le faire

changement des type OK

modification du code OK, mais ca ne semble suffisant, car sauf erreur de ma part, tous les codes qui sont dans data/customtemplates, n’apparaisent pas dans la liste des widgets Custom

et utiliser les templates je veux bien, pour les widgets avec des images ou des icones

mais comment tu fais pour un widget de ce type, qui est l’équivalent d’un BADGE mais sur du string et sur une seule ligne, pas trop le choix si il n’est pas dans les widgets CORE

<div class="cmd cmd-widget #history#" data-type="info" data-subtype="string" data-template="badgeline" data-cmd_id="#id#" data-cmd_uid="#uid#" data-version="#version#" data-eqLogic_id="#eqLogic_id#">
  <span class="title #hide_name#">
    <span  class="cmdName">#name_display# </span>
  </span>
    <span class='label label-info state'></span>
  <script>
    jeedom.cmd.update['#id#'] = function(_options){
      $('.cmd[data-cmd_id=#id#]').attr('title','Date de valeur : '+_options.valueDate+'<br/>Date de collecte : '+_options.collectDate)
      $('.cmd[data-cmd_id=#id#] .state').empty().append(_options.display_value +' #unite#');
    }
    jeedom.cmd.update['#id#']({display_value:'#state#',valueDate:'#valueDate#',collectDate:'#collectDate#',alertLevel:'#alertLevel#'});
  </script>
</div>
48

Bonjour @jpty

J’ai migré en Janvier de V3 à V4 et revu tous mes widgets qui étaient passés en défaut.
Il me semble un moment avoir copié en mode bourrin les widgets de l’ex plugin vers data/customTemplates/dashboard
Maintenant j’aimerais sur la base de la phrase de @Salvialf ci-dessus. Lister mes widgets inutilisés mais existants dans la zone customtemp afin de faire le ménage dans cette zone.

Si j’ai été clair, as-tu une requête BDD pour ça ?

49

Normalement mais faut que le widget ait le bon nom

Pour ton widget pas le choix ou tu en met un autre on peut pas tout faire faut pas rever non plus.

50

Je vais résumer le soucis de base parceque je crois qu’on s’y perd…

Si j’ai bien suivi: (j’avais aussi eu le soucis mais je me rapelle plus bien)

A la migration: le widget est présent dans la liste en customTemp
Il est toujours appliqué à la commande (visuellement on le voit)
Mais dans les infos de la commande on voit qu’elle est sur le widget défaut (la sélection dans la liste ne correspond pas au visuel affiché)

Pour info: si on fait un backup/re store on se retrouve avec le widget défaut…

Ce n’est pas juste un soucis du nom de widget enregistré dans la base a la migration qui ne correspond pas à celui qui se met quand on le sélectionne?

Je suis bien d’accord qu’il faut ensuite retravailler ses widget pour les rendre compatibles v4 (via le core et non le plugin), mais il y a quand même une incohérence entre ce qui est affiché sur le Dashboard et ce qui est sélectionné dans la liste des widgets.

51

Bonjour à tous,

Exactement le nom dans la bdd est en custom:: alors que les fichiers nécessaires sont dans le répertoire du plugin widget. En mettant widget:: on récupère le nom correct au lieu de Défaut lors de l’assignation.

@Loic Il ne s’agit pas ensuite d’utiliser le plugin widget mais uniquement son espace de stockage.

Lors de l’assignation d’un widget à une commande quand il y a des widgets de même nom dans des répertoires différents: plugin, plugin widget, customtemp un seul est proposé. Quand le widget du plugin widget est adapté à la v4, il faut le supprimer du plugin widget pour qu’il soit sélectionnable dans les widgets Custom

52

Meme l’espace de stockage faut eviter aussi, je suis bien conscient que ya des soucis sur la v4 et que c’est pas facile pour vous l’équipe Jeedom est dessus et derriere vous pour aider un maximum (la preuve je bosse autant que d’habitude alors que je suis en vacance…) mais faut virer ce plugin.

53

Ya pas de souci. Je termine l’adaptation à la v4 des 2 derniers widgets qui restent et je supprime le plugin.
Mais je n’avais 1500 cmd avec des widgets perso comme @Nemeraud.

54

Ce n’est pas qu’une requête SQL, il faut aussi comparer avec la liste des fichiers présents dans data/customTemplates.
Ça donne un script que je n’ai pas.

Ça existait dans le plugin widget en v3. Dans la liste des widgets sur la gauche, il y avait pour chaque widget son nombre d’utilisation.

55

je suis désolé mais j’ai pas la même vision

suite à la migration, par défaut les commandes pointent vers le PLUGIN WIDGET et s’affichent correctement en effet mais l’info dans le template n’est pas bon, il affiche donc DEFAUT quand on veut voir l’affection du widget à la commande

+> cela se corrige dans la base SQL en modifiant « custom » par « widget »

mais dans ce cas, on pointe vers le PLUGIN WIDGET ce que l’on ne veut pas

Il faudrait donc, modifier dans la base le « custom » en « customtemp »

ca fonctionne pour l’affichage du widget mais là aussi l’affectation dans l’affichage de la commande n’est pas correcte, indique « DEFAUT », car tous les widgets qui ont été copiés dans la nouvelle arbo DATA ne sont pas connus par jeedom et même en faisant NOUVEAU dans la partie CORE, et en mettant le même nom qui est affichié dans le nom long, exemple « cmd.info.numeric.progressBar.html », je nomme mon nouveau widget « progressBar », le nouveau widget, d’apparait pas dans la partie CUSTOM si on veut l’affecter à une commande, alors que si je fais NOUVEAU que je mets un nouveau nom « progressBarNew » et que je colle le code, là ca fonctionne mais ca oblige a refaire de nouveau widget, il y a donc bien un soucis dans cette partie là

56

Il faut supprimer les anciens fichiers du plugin widget s’ils portent le même nom. Sinon le nouveau n’apparait pas pour affectation.

57

Je viens de pousser une correction pour les prochains qui vont faire le passage ou effectivement je mettais custom:: au lieu de customtemp::

1 « J'aime »
58

tu veux que je restaure et que je test ?

59

ok merci

donc il suffit de supprimer le plugin widget, en ayant fait le changement dans le base, tout va rester comme avant

60

A vérifier si la suppression du plugin widget résout tout après modif de custom:: en customtemp:: dans la bdd.
Vous avez écrit au dessus:

ca fonctionne pour l’affichage du widget mais là aussi l’affectation dans l’affichage de la commande n’est pas correcte, indique « DEFAUT »