Souci dans l'order des commandes

Bonjour,

J’ai un petit souci dont je n’arrive pas à comprendre la logique.
Je set l’order sur mes commandes.
Cependant pour l’une d’entre elle (et uniquement une), elle ne se met pas dans l’ordre indiqué.
J’ai vérifié dans la ma $cmd avant le save() si l’order était bien setté. C’est le cas.

Log de debug : https://gist.github.com/mguyard/d75d56a543c6680323f0acc22e7a213e

Dans mon debug, je vois bien que le ‹ order › est bien séquentiel comme il faut et que ma commande launch_scenario (Lancement Scenario) a bien l’order 5.
Cependant, dans mon interface comme dans la liste sur un scenario, il arrive en dernière position.

51

Je suis perdu.
Est-ce que l’affichage joue sur un critère complémentaire au ‹ order › ?

Merci d’avance

Bonjour,

Personne n’a d’idée ? Me suis-je mal expliqué ?
Je viens d’ajouter dans mon code une nouvelle commande, et elle n’a pas pris sa position (mais l’order est bon) mais elle ne s’est pas mise à la fin des commandes comme launch_scenario.
J’ai beaucoup de mal a comprendre :frowning:

Le code source est ici : https://github.com/mguyard/Jeedom-Diagral_eOne
Sur la branch dev

Merci de votre aide.

Salut,

Je n’ai pas testé pour reproduire mes voici mes commentaires en lisant ton code:

  • ++$key incrémente vraiment $key avant de retourner la valeur; donc après la ligne ou tu fais cela, $key vaut 1 de plus que sur la ligne précédente, hors c’est une valeur d’index de ton tableau, géré par le for.
    Tu n’es pas sensé y toucher si tu veux garder un code propre; c’est de plus très dangereux si plus tard tu veux utiliser la valeur, tu penserais naturellement qu’elle vaut l’index initial.
    Alors pour l’instant tu n’utilises pas $key ailleurs dans la boucle donc cela n’a probablement pas d’impact mais …
  • l’ordre des commandes commence à 0 pour se terminer à n-1 si tu as n commandes.
    Hors tu définis toujours ++$key, donc ton premier aura un order de 1 et le dernier de n, je suppose que dans ce cas, l’orde final est incertain et que c’est pour cela que ton « launch_scenario » se retrouve à la fin; je n’ai pas analysé le code du core pour en être sûr, simple supposition.

Tu pourrais probablement régler les 2 points en faisant un $cmd->setOrder($key);
Par contre je me demande si c’est nécessaire? j’aurais supposé que l’ordre des commandes serait par défaut l’ordre de création, donc ne pas définir l’ordre va par défaut rajouter la commande à la fin de la liste actuelle.

Bonjour,

Tout d’abord merci d’avoir pris le temps de me répondre.

  • Mon ++key est du au fait que mon tableau commence à 0 alors que l’order doit commencer à 1. C’est pour cela que j’incremente avant. Sauf si tu me dit que l’order peut commencer à 0. Au départ j’utilisais $key directement. J’ai changé pour essayé de corriger ce souci.
  • Désolé mais j’ai du mal a comprendre ta seconde phrase.

En effet, le order n’est pas nécessaire car il les met dans l’ordre naturellement. Mais dans mon contexte, je crée certaines commandes, uniquement après que l’utilisateur est configuré une valeur dans l’équipement car sans cette valeur, je ne peux me connecter au cloud Diagral pour récupérer les champs possible que je positionne dans le select.
Je ne crée donc pas les commandes dans l’ordre que je le souhaite.
Ce qui fait que pour certains je modifie l’order Afin de les mettre finalement dans l’ordre voulu.

Aujourd’hui, je me suis reconnecter et j’ai l’impression que c’est un cache du navigateur qui fait ca. Cependant, j’avais deja testé de purger mon cache.
Je pousser une analyse de ce coté là.

Ma deuxième phrase dit que l’ordre des commandes commencent à 0.
Si tu as 5 (n) commandes, l’ordre de celles-ci ira de 0 à 4 (n-1);
regarde la config avancée de la première commande de n’importe quel équipement.

Bonjour,

En effet mais comme le setOrder attribue l’order dans l’ordre que j’ai placé mes commandes dans mon json, je suis certains de toujours les avoir dans l’ordre voulu. Je ne specifie pas statiquement le numéro d’order.

Pour faire simple, j’ai mon json de commandes. A la création auto de l’équipement, seulement quelques commandes sont crées, toutes avec un order les uns à la suite des autres.
Puis quand la configuration nécessaire dans l’équipement, au save, des nouvelles commandes sont crée.
Mais pour cela, je reparcours toutes mes commandes dans mon json et re-set l’order des commandes existante, ce qui aura pour effet de mettre toutes les commandes (nouvelles et ancienne) avec un order maîtrisé les une à la suite des autres.

Il me semble bien que c’est ce que j’ai quand j’affiche toutes mes commandes avant le save. Sauf si tu vois un truc dans mon code qui cloche.
La grande question après c’est est-ce que le setOrder doit commencer à 0 ou 1. Il me semble quand avant mon ++$key la commande était set avec un order à 0 mais que du coup la commande avant le save contenais un order vide car je pense que 0 est vu comme vide dans le core.

on peut voir la propriété « order » et elle est à zéro.

En remplaçant le ++$key par $key, lors de la creation des premieres commandes, j’ai un order à 0,1,2,3,4,7,8.
Une fois ma configuration faite, les nouvelles commandes se créé et forme un 0,1,2,3,4,5,5,6,6.
Il faut que je regarde pourquoi mais le problème est bien la.
Merci @Mips

Bon ca reste nébuleux. :thinking:
Je suis donc repassé en $key au lieu de ++$key.

Voici les logs que j’ai généré : https://gist.github.com/mguyard/2703a8e4337a45206d5bd8c548669d0d
J’ai ajouté 2 logs dans ma fonction, une pour voir le $key et l’autre l’object $cmd avant le save :

private function createCmd() {
        // Definition et chargement du fichier de configuration globale qui inclus notament les commandes
        $filename = __ROOT__.'/core/config/config.json';
        $config = $this->loadConfigFile($filename, 'commands');

        foreach ($config['commands'] as $key => $command) {
            $newCmd = false;
            $cmd = $this->getCmd(null, $command['logicalId']);
            // Si la commande n'existe pas deja
            if (!is_object($cmd)) {
                $newCmd = true;
                $cmd = new Diagral_eOneCmd();
                $cmd->setName(__($command['name'], __FILE__));
            }
            // Le parametre JSON masterCodeNeed n'existe pas ou est à false ou bien que le MasterCode est rempli
            if (! isset($command['masterCodeNeed']) || $command['masterCodeNeed'] === false || ! empty($this->getConfiguration('mastercode'))) {
                $cmd->setOrder($key);
                log::add('Diagral_eOne', 'info', 'Debug souci order (cle dans setorder) ' . $key);
                $cmd->setEqLogic_id($this->getId());
                if( isset($command['configuration']['function'])) {
                    list($fieldType, $fieldFunction)= explode("::", $command['configuration']['function']);
                    log::add('Diagral_eOne', 'debug', 'postSave::UpdateContent::' . $command['logicalId'] . ' ' . $fieldType . ' with function ' . $fieldFunction);
                    if (is_callable(array(get_class($this), $fieldFunction))) {
                        log::add('Diagral_eOne', 'debug', 'postSave::UpdateContent::' . $command['logicalId'] . 'VerifyFunctionCallable ' . $fieldFunction . ' TRUE');
                        $contentField = call_user_func(array(get_class($this), $fieldFunction));
                        $parsedContent = "";
                        switch ($fieldType) {
                            case 'listValue':
                                $parsedContent = $this->generatePossibilitiesSelect($contentField);
                                break;
                        }
                        log::add('Diagral_eOne', 'debug', 'postSave::UpdateContent::GetReturnFunction ' . $parsedContent);
                        $command['configuration'][$fieldType] = $parsedContent;
                        unset($command['configuration']['function']);
                        log::add('Diagral_eOne', 'debug', 'postSave::UpdateContent::NewCommand ' . var_export($command, true));
                    } else {
                        log::add('Diagral_eOne', 'debug', 'postSave::UpdateContent::VerifyFunctionCallable ' . $fieldFunction . ' FALSE');
                    }
                }
                utils::a2o($cmd, $command);
                log::add('Diagral_eOne', 'info', 'Debug souci order (cmd object avant save) ' . var_export($cmd, true));
                $cmd->save();
                if ($newCmd === true) {
                    log::add('Diagral_eOne', 'info', 'postSave::createCmd '.$command['logicalId'].' ('.$command['name'].')');
                } else {
                    log::add('Diagral_eOne', 'info', 'postSave::updateCmd '.$command['logicalId'].' ('.$command['name'].')');
                }
            } else {
                log::add('Diagral_eOne', 'info', 'postSave::bypassCmd '.$command['logicalId'].' ('.$command['name'].')');
            }
        }
    }

A la premiere creation de commande, tout es ok. Le $key correspond à l’order que je retrouve dans l’object $cmd. Et quand je regarde les commandes dans l’interface elles ont bien le bon order.

Par contre a la creation de la seconde série de commande après la configuration dans l’équipement, j’ai le $key qui correspond à mon order. Donc tout semblais ok mais en regardant les commandes, je vois que les commandes force_groups_refresh_json et force_scenarios_refresh_json ont respectivement les order 5 et 6. Alors que dans le $cmd ces commandes avait le bon order.

Si je resave mes commandes encore, la j’ai tout les id à la suite 0 à 8 mais pas dans l’ordre indiqué dans mes logs (qui sont bons).

Donc il se passe quelque chose après le save qui motifiie set les order différemment de ce que l’on donne dans l’object $cmd.
@Loic une idée de ce qui peut se passer ? Un bug ou je fais mal une chose ?

Salut,
J’ai rien suivi je suis désolé, un bug dans jeedom j’en doute pour moi c’est soit :

  • quand tu save ben l’ordre reprend celui de l’interface de l’onglet commande
  • regarde les id des commandes voir si tu fais pas une recreation
  • regarde ton fichier json si ya un order dedans

Salut Loic,

Avec tout ce que vous avez à faire c’est pas étonnant :blush:
Je te fais le résumé court.
Mon plugin créé les commandes en 2 lots.

  • Premier lot : A la creation de l’équipement, les commandes génériques sont créées
  • Second lot : Après l’ajout d’une conf dans l’équipement en postsave (car les commandes du second lot sont des select avec le listValue généré en interrogeant le cloud. Et je ne peux interroger le cloud que quand une valeur a était configuré dans l’équipement).

Je fixe l’order des commandes à partir de l’ordre de mon JSON. Je n’ai pas la commande order dans le JSON (j’ai essayé mais ca changé rien au problème).
Mon second lot de commande, on un order au miilieu des commandes du premier lot.
Le premier lot doit prendre 0,1,2,3,4,7,8
Le second lot doit prendre 5,6

Statut actuel :
Le premier lot d’ajoute bien comme il faut avec les bon id.
Quand j’ajoute le second lot, les order 7 et 8 passe en 5 et 6. Ce qui fait que je me retrouve avec 0,1,2,3,4,5,5,6,6
Pourtant avec le $cmd->save, l’objet $cmd a bien les bon order. Mais une fois save, ce n’est plus le cas (cf. gist plus haut)

En effet, si je save l’équipement sans rentré le config nécessaire dans l’équipement (donc créé pas les commande du lot 2), il me réorganise les orders des commandes.
Mais quand la configuration est placé, je setOrder toutes les commandes pour renforcer l’ordre de l’ensemble des commandes. Donc normalement, il devrait prendre ce nouveau order non ?
C’est comme si je n’arrivais pas a modifié un order d’une commande (ou que je le fais pas comme il faut, mais a part le setOrder je vois pas.

Les commandes garde le meme id entre le lot 1 et le lot 2.
Si je refais un save par l’interface après le lot 2, les order se suive bien, mais plus dans l’ordre que j’avais configuré mais bien celui de l’interface

J’en ai pas. J’utilise les clés du tableau JSON pour fixer les order.
Mais j’ai testé en mettant l’order dans le JSON, pas mieux :sleepy:

Honnêtement je vois pas doit avoir un soucis dans ton code mais comme ça c’est dur de dire ou…

C’est bien le setOrder qui le change ma seule explication c’est que c’est ecraser par l’ui je vois comme ca

Ok merci.
C’est de l’esthétique donc je vais laisser comme ca pour le moment.
Si quelqu’un passe par là avec une idée, je suis preneur :blush:

Oui, et surtout, si un des utilisateurs n’est pas content de l’ordre, il peut le changer lui-même dans la liste par un glisser/déposer de la commande…

Oui je sais mais j’aime bien quand ma chambre est bien rangée :grinning:

Bonjour à tou
je me permet de poser une question sur ce fil. Sur un plugin que je développe, je n’ai pas accès au glisser déplacer des commandes pour modifier l’ordre. Ou peut on activer cette fonctionnalité dans le code d’un plugin ?
Merci

Il n’y a rien à faire pour cela si vous avez utilisez le plugin template c’est géré par le core.

Salut Loic69,

Tu ne peux pas glisser/déposer ou ça ne conserve pas l’ordre une fois le save passé?

Est ce que tu as bien dans un script : ( dans le template plugin à « plugin/desktop/js/plugin.js ») avec :

$("#table_cmd").sortable({
  axis: "y",
  cursor: "move",
  items: ".cmd",
  placeholder: "ui-state-highlight",
  tolerance: "intersect",
  forcePlaceholderSize: true
})

avec l’id de la table, à dupliquer pour d’éventuelles autres tables (et ou paramétré différement au besoin)

C’est réglé. Mon fichier classe.js n’était pas à jour…
J’en ai profité pour le mettre à jour depuis le nouveau template de plugin
Sujet clos pour ma part

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.