Bonjour à tous.
Je n’ai pas bien compris la stratégie à suivre lorsqu’on développe un plugin tiers au niveau des widgets avec la sortie de la V4.
Je m’explique: si je regarde les (quelques) plugins que j’ai déjà développés, je me rend compte qu’un certain nombre des widgets que j’y ai inclus pourraient aisément être remplacés par un widget créé avec l’outil widget inclus dans la v4.
Comment devra-on faire dans le futur ? Pourra -ton inclure dans un plugin tiers le json obtenu par l’export d’un widget créé avec cet outil (ou un autre moyen) de façon à s’éviter d’avoir un widget personnalisé dans le plugin (et donc plus à le maintenir !) et la certitude qu’il sera toujours à jour dans le futur tout en évitant à l’utilisateur tout souci lors de l’installation.
Bonjour,
C’est deja possible voila un exemple a mettre dans la class de ton équipement :
public static function templateWidget(){
$return = array('info' => array('string' => array()));
$return['info']['string']['state'] = array(
'template' => 'tmplmultistate','test' => array(
array('operation' => '#value# == 2','state' => '<i class="icon maison-vacuum6"></i>'),
array('operation' => '#value# == 3','state' => '<i class="fa fa-pause"></i>'),
array('operation' => '#value# > 3 || #value# < 2','state' => '<i class="fa fa-home"></i>')
)
);
return $return;
}
Ensuite juste a affecter le widget neato::state, comme ca :
$etattech->setTemplate('dashboard','neato::state');
$etattech->setTemplate('mobile','neato::state');
neato étant l’id du plugin dans mon exemple
Bonjour,
ça me semble pratique, mais en gros, ça remplace la fonction toHtml ?
Si oui, l’exemple ne me permet pas personnellement de comprendre la finalité.
Est-ce que ça sera fonctionnel uniquement sur la v4 ?
Merci
C’est uniquement v4 oui et ca permet dans certain cas d’eviter le toHtml.
Pour l’exemple ici en fonction de la valeur de la commande il affiche une icone voulu
Ok, donc je reste sur le toHtml car j’ai pas besoin d’une version spécifique V3 pour le reste du plugin. Je me pencherai sur le sujet quand la V3 n’existera plus, ça me laissera le temps d’assimiler les choses.
Merci
Loic,
Je vais prendre des pincettes car sinon tu vas encore mal le prendre, mais pourquoi ne pas avoir parler de cette fonction avant ?? Depuis le début, on le dit, la v4 ce qui morfle c’est les widgets. Des points ont été présentés, mais pas cette nouvelle fonction.
Et comme prévu, les seuls retours de la RC v4 que je me prend dans les pattes c’est les widgets qui ont mangé cher. Alors j’ai envie de faire comme sur Mitsubishi : tout virer du widget.
Là je vois que t’as créer une fonction basée sur le nouveau système, pourquoi pas. Mais aurais-tu plus d’info ? Une doc ? Ou l’exemple complet ? Apparemment ca vient de neato, mais il est payant donc pas d’accès au github.
Est-ce que les widgets doivent exister de base sur le jeedom ou ca le créer ? J’ai l’impression que $return[‹ info ›][‹ string ›][‹ state ›] créer un widget pour les commandes string qui s’appelle state (d’où le neato::state ensuite). Mais les mots clef template et test, leur usage ?
J’ai simplement pas encore eu le temps d’en parler j’ai tellement a faire avec les critiques a me battre tout le temps que je ne trouve ni le temps d’en parler et encore moins d’en faire une doc ou explication…
Loic,
Merci c’est tout à fait ce que je cherchais. Je n’ai pas regardé en détail mais je pense que çà va me permettre de supprimer pratiquement tous les widgets que j’avais fait pour le plugin Elm Touch.
Pour le plugin Sure PetCare c’est un peu moins sûr car pour les animaux j’ai un widget spécifique d’eqLogic et je ne vois pas bien comment m’en passer mais bon à priori il n’a pas mauvaise allure en v4
Lunarok,
En fait j’ai regardé le code du plugin Neato et il n’y a rien d’autre que ce que Loic a mis, son exemple est complet: dans la fonction templateWidget on définit ses widget basés sur des templates et ensuite on les attache à ses commandes comme avant par un setTemplate mais avec nomdeClasse::nomDeWidget
Comme tu l’as dit il faut définir $return[‹ type ›][‹ subtype ›][‹ nomDeWidget ›]
Pour ce qui est des arguments, le premier c’est ‹ template › => ‹ nomdutemplate › a choisir parmi ceux qui sont dans core/template/dashboard et core/template/mobile et ensuite çà dépend du template en question, par exemple pour le template utilisé par le plugin neato qui est https://github.com/jeedom/core/blob/alpha/core/template/dashboard/cmd.info.string.tmplmultistate.html il attend une array test qui sera mise à la place du tag #test# et on peut avoir une idée du contenu à mettre pour cette array en regardant dans la classe cmd la fonction getWidgetTemplateCode.
Pour d’autre templates au lieu de l’array test, il faut passer une array replace avec les icones pour le on et le off
Loic j’ai une question: si pour certains templates je ne trouve pas d’icône adaptée et que je désire utiliser des images, quelle est à ton avis la meilleure place pour les mettre dans l’arborescence du plugin ? Peut-être que çà n’a pas d’importance ? A moins qu’on les copie dans data/img lors de l’installation du plugin pour faire comme les widgets construit par l’outil de façon à permettre une personnalisation par l’utilisateur ?
J’ai essayé de me retenir, mais quand meme. On ne fait pas que des critiques, on remonte des points. Mais ton attitude tout le long de la v4 a été d’imposé ton point de vue, si il faut en renvoyant vers une décision plus tard avec l’équipe. Mais c’était avant tout pour alerter.
Pareil pour les bugs remontés ici, parfois ignorés ou pas traitable.
Mais une fois mis en RC sur le forum, là il y a le temps pour traiter des problèmes remontés ici mais vu làbas comme nouveaux. Les deisgns défoncés corrigés à la main, ca demande au moins autant de temps que de documenter une nouvelle fonction pour les devs. Le thème qui change tout seul, remonté ici et écarté d’un « c’est normal, c’est pas permanent le switch thème ». Parceque oui, si il n’y a plus de réponses sur un sujet des BT, c’est parfois pour la meme raison que quand il y en a plus de ta part (ou kiboost) : fatigue et sentiment d’inutilité
Personnellement, je te foutrais la paix pour les prochaines versions, je remonterais plus rien. Partenaires aura été une tentative de plus qui échoue pour la relation BT/dev (j’ai mon propre canal de test, et heureusement encore, parceque j’ai rien eu de remonté d’utile ici sur mes plugins)
Le thème pas permanent faut arrêter, ça fait des mois qu’on a mit en place un cookie pour que ça le soit. Et en l’occurence Le changement automatique en fonction de l’heure te re bascule dans le thème principal, logique. Et ça je ne me souvient pas que ça est été discuté ou alors j’avais mal compris. Cela dit, même en heure auto on va faire en sorte que si on bascule, on y reste. Plus logique. La bascule coupe l’automatisme.
Pour le reste c’est ton point de vue, on a changé pas mal de choses en fonctions de vos remontées, je me suis par exemple arraché les cheveux sur le déplacement de tuiles avec zoom dans les designs (alors que perso je m’en sert pas), mais tu ne vois que le négatif, easy …
je fais un simple constat :
Je vais dans la catégorie BugReport core V4 puis en face j’ai la possibilité de mettre les résolus et les non-résolus.
Et j’obtiens énormément de résolus ( je regarde dedans a chaque vois c’est des vrais resolutions ) je ne les ai pas tous fait. et il reste c’est vrai des non-résolus mais ça a l’air d’être en cours de resolution et autre.
la ou tu a raison c’est qu’il n’y a pas de doc pour les Dev pour cette nouvelle fonction de creation de widget etc… nous allons remédier a ce point.
Partenaire fonctionne plutôt bien pour le core Jeedom, mais moins pour les plugins Tiers etc… si tu a une idée pour faire vivre mieux cette partie je t’en pris donne nous l’idée, partenaire demande qu’a être plus facile et plus utilisé par tout le monde.
J’avais remonté dans les premiers les gros problèmes sur les designs lors des premières v4.
Vous m’aviez indiqué que c’était aux concepteurs de widgets ou plugins tiers des widgets de les adapter, j’ai donc attendu et je teste en moyenne toutes les 2 semaines une migration v3 vers v4. N’ayant jamais constaté de changement je patiente. Comme évoqué les nouvelles limitations sur le design m’avaient frustré, mais je me disais bon cela peu évoluer.
En lisant que le plugin widget disparaissait et que les widgets devraient s’appuyer sur la nouvelle fonction du core, je m’interroge sur la liberté de conception des widgets. En gros serons-nous limité à l’utilisation des paramètres disponibles dans la nouvelle fonction. Après comme cette dernière n’est pas présentée, nous nous inquiétons peut êtes pour rien.
Quand j’essaye de regrouper les différents usages faits dans les widgets, on retrouve :
- Gestion de plusieurs états qui change l’image du widget (ex radiateurs avec plusieurs modes/ HGel/Confort/Confort+/Arret…)
- Widgets dynamiques (gestion des volets avec positionnement en fonction du %; gestion des ouvrants avec les différents modes cumulés bâtant droit ouvert/fermé, bâtant gauche ouvert/fermé, position des stores/oscilo bâtant et tout cela cumulé …)
- changement de la couleur du texte en fonction de la valeur d’une info
- idem avec la couleur de la tuile
- j’ai en tête aussi les deux widgets qui gère sur les cmd et l’autre l’info avec une bibliothèque de plusieurs dizaines d’équipements pour avoir le On/Off (switch, router, frigo, biberon
en gros tout et n’importe quoi). - il y a aussi les différentes jauges dynamiques
et il doit y avoir encore beaucoup d’usage des widgets que j’ai omis.
Cette nouvelle fonction pas encore présentée si j’ai bien compris pourra-t-elle couvrir une partie ou totalité de ce que certains utilisateurs ont développé en v2 puis v3 ?
Quand on voit la section design du forum, certains sont aller très loin dans la customisation. Quelle sera la réponse apportée par Jeedom en v4 pour eux. Je me compte dedans dans une certaine mesure.
Edit : si j’ai rien compris aux changements sur les widgets, c’est le moment de nous éclairer (je ne penses pas être le seul a essayer de comprendre la nouvelle orientation)
Bonjour,
Je vais faire une doc la dessus mais c’est plus pour les dev. Pour les utilisateurs ya 2 possibilité :
- comme avant écrire directement dans le code du widget comme dans le plugin widget. C’est moins pratique mais ya exactement les même possibilité vu que c’est le code brute
- passer par le système de template (c’est le même principe que ce que fait le code plus haut, juste en mode interface graphique). C’est basique mais répond déjà a plusieurs cas que tu as exprimé
Pour les autres cas l’idée c’est qu’on en gère plus au niveau des widgets core. Mais ça se fera petit a petit au fil des versions
Bonjour,
La doc est en ligne (voir article du blog)
Voilà quelques corrections (autographe, syntaxes etc), il en reste peut-être encore
La page widgets vous permet de créer des widgets personnalisés et uniques pour votre Jeedom.
Il y a 2 possibilités :
- Soit en cliquant sur le bouton code et directement écrire votre code en html pour votre widget (ce n'est pas forcement ce que nous conseillons car lors des mises à jour de jeedom votre code peut devenir incompatible avec jeedom)
- Soit en faisant un widget basé sur un template que l'on fournit
# Mais c'est quoi un template ?
Pour faire simple c'est du code (ici html) où l'on a prédéfini certaines parties que vous allez pouvoir configurer comme vous le voulez.
Dans les cas des widgets, on vous propose souvent la personnalisation des icônes ou de mettre les images que vous voulez.
# Les templates
Il y a 2 types de templates :
- Les "simples" : type une icône/image pour le "on" et une icône/image pour le "off"
- Les "multistates" : cela vous permet de définir par exemple une image si la commande a pour valeur "XX" et une autre si > à "YY" et encore si < à "ZZ". Ou même une image si la valeur vaut "toto", une autre si c'est "plop" et ainsi de suite.
# Comment faire ?
Une fois sur la page Outils -> Widget il vous faut cliquer sur "Ajouter" et donner un nom à votre nouveau widget.
Ensuite :
- Vous choisissez s’il s'applique sur une commande de type action ou info
- En fonction de votre choix précèdent, vous allez devoir choisir le sous type de la commande (binaire, numérique, autre...)
- Puis enfin le template en question (nous envisageons de pour vous mettre des exemples de rendus pour chaque template)
- Une fois le template choisi, jeedom vous donne les possibilités de configuration de celui-ci
## Remplacement
C'est ce que l'on appelle un widget simple, ici vous avez juste à dire que le "on" correspond à telle icone/image (avec le bouton choisir), le "off" est celui-là ec. Ensuite en fonction du template, il peut vous être demander aussi la largeur (width) et la hauteur (height). Ce n’est valable que pour les images.
>**Note**
>
>Nous sommes désolés pour les noms en anglais, il s’agit d’une contrainte du système de template. Ce choix permet de garantir une certaine rapidité et efficacité, aussi bien pour vous que pour nous. Nous n'avons pas eu le choix
## Test
C'est ce que l'on appelle la partie multistates, vous avez souvent comme pour les widgets simples le choix de la "hauteur"/"largeur" pour les images uniquement puis en dessous la partie test.
C'est assez simple. Au lieu de mettre une image pour le "on" et/ou pour le "off" comme dans le cas précèdent, vous allez avant donner un test à faire. Si celui-ci est vrai alors le widget affichera l'icône/l'image en question.
Les tests sont sous la forme : #value# == 1, #value# sera automatiquement remplacé par le système par la valeur actuelle de la commande. Vous pouvez aussi faire par exemple :
- #value# > 1
- #value# >= 1 && #value# <= 5
- '#value#' == 'toto'
>**Note**
>
>Il est important de noter les ' autour de #value# et du texte à comparer si la valeur est un texte
>**Note**
>
>Pour les utilisateurs avancés, il est possible ici d'utiliser aussi des fonctions javascript type '#value#'.match("^plop"), ici on test si le texte commence par plop
Super merci, je viens de le mettre en alpha