`postSave()` et `postAjax()`

[Michel_F]

Bonjour,

Mon setup de dev :

Pour le plugin-mymodbus, jusqu’à il y a quelques semaines, l’envoi de la nouvelle configuration des équipements au démon était faite dans postAjax() et ça fonctionnait :

  public function postAjax() {
    log::add(__CLASS__, 'debug', __CLASS__ . '::' . __FUNCTION__);
    self::sendNewConfig();
  }

La raison pour laquelle j’ai déplacé l’appel de sendNewConfig() dans postSave() était pour que la désactivation/activation d’un équipement par un scénario soit prise en compte. postAjax() n’est pas appelée dans ce cas-là.

Maintenant, je me retrouve avec le même problème que mon prédécesseur : une sauvegarde d’équipement doit être faite 2x pour que la dernière version de la configuration des commandes de l’équipement soit effectivement envoyée. Pour la config de l’équipement pas de problème.

D’après ce que j’ai compris du code du core :

• postSave() est lancée à la fin de la mise à jour en DB. Donc cette fonction est systématiquement appelée, que ce soit via UI ou pas à moins que je ne me trompe.
• postAjax() est exécutée à la fin de la fonction php ajax lors de l’enregistrement d’un eqLogic. C’est lancé par le js, je suppose donc que ce n’est fait que lors d’une sauvegarde via UI.

Au final, c’est quoi la différence entre ces 2 fonctions postSave() et postAjax() ?

Si les 2 fonctions appellent ma fonction sendNewConfig(), la bonne configuration n’est envoyée que par postAjax().

Le problème que je rencontre vient du cache ? Il ne serait pas rafraichi lors de l’appel de postSave() ? Comment corriger ? Il y a une fonction de eqLogic qui soit appelée après la sauvegarde de toutes les commandes lors d’une sauvegarde et ce depuis l’UI ou un scénario ?

Est-ce que ce phénomène existe pour d’autres plugins ? Je n’en ai pas testé d’autres, là il est un peu tard pour ça…

A+
Michel

[Mips]

Salut,

Tu as probablement / peut-être vu dans le code eqlogic.ajax, que c’est le save de l’eqlogic en premier (donc ton postSave ce fait juste après), ensuite le save des commandes

l’info qu’on a pas: sendNewConfig() va chercher la config où? dans les « commandes » de ton équipement?
si oui, tu auras déjà fait le lien => au moment de ton sendNewConfig() les commandes ont les anciennes données à ce moment; voila pourquoi il te faut 2 save pour avoir la bonne config.

ligne 605 tu vois le postAjax, fait lorsque les commandes sont déjà sauvées

@Michel_F

Le problème que je rencontre vient du cache ? Il ne serait pas rafraichi lors de l’appel de postSave() ?

Non, pas de problème de cache, c’est bien « la DB qui n’est encore pas à jour »

@Michel_F

Il y a une fonction de eqLogic qui soit appelée après la sauvegarde de toutes les commandes lors d’une sauvegarde et ce depuis l’UI ou un scénario ?

le postAjax est littéralement la première chose qui est faite juste après la sauvegarde de toutes les commandes.
un changement d’activation de l’équipement n’est effectivement pas géré par cette méthode (c’est pas un « action »==« save »)

@Michel_F

Comment corriger ?

je vois deux options vite fait mais il y en a surement d’autres:

• tu changes ta structure de données (et tu sauves tes configs dans une attribut configuration de ton équipement par exemple, cf. quelques plugins officielles qui font ça, comme plugin-mode de mémoire, je pense qu’il est publique); plus de boulot
• tu gardes ton postAjax mais pour gérer le cas de l’activation/désactivation tu gères plutot un preSave() dans lequel tu dois détecter si l’eqlogic est activé/désactivé (hint: $this c’est le nouveau, $old = eqLogic::byId($this->getId()); c’est l’ancien ) et tu agis en conséquence sur ton démon juste pour cette partie pour activer/désactiver ce qu’il faut (sans te préoccuper de toute la config)

[Michel_F]

Merci Mips, je testerai le preSave et ferai un retour.

[Michel_F]

C’est peut-être vulgaire, mais c’est ce à quoi j’ai pensé quand j’ai testé ta solution et qu’elle fonctionne aux petits oignons !

Juste l’audio

T' es un genie