La documentation indique que ces fonctions sont appelées lors de l’installation, la mise à jour ou la suppression du plugin.
Je pense que cette documentation est erronée car ces fonctions sont appelées lors de l’exécution de la méthode setIsEnable de la class plugin déclarée dans le fichier /core/class/plugin.class.php.
Comment puis déclarer une function qui soit appelée en début de procédure de désinstallation du plugin mais pas lors de sa désactivation?
J’ai un plugin un peu particulier qui nécessite l’usage de plusieurs types d’eqLogic. J’ai donc les classes
<pluginId>
<pluginId>_charger
<pluginId>_account
<pluginId>_account_model1
<pluginId>_account_model2
<pluginId>_vehicle
La classe <pluginId> est utilisée pour la gestion du deamon et des dépendances et comme « moteur » pour le fonctionnement du plugin. Il n’y a pas d’eqLogic créé avec cette classe.
Les classes <pluginId>_charger, <pluginId>_account et <pluginId>_vehicle héritent de <pluginId>
Les classes <pluginId>_account_model# héritent de <pluginId>_account
Le plugin n’est pas encore publiable mais les élément suivants fonctionnent correctement:
Panneau de configuration pour les eqLogics <pluginId>_charger + cmd associées
Panneau de configuration pour les eqLogics <pluginId>_account
Panneau de configuration pour les eqLogics <pluginId>_vehicle + cmd associées
Deamon multi-thread
J’ai pour le moment deux modèles de chargeurs
Un modèle qui correspond à mon charger
Un modèle virtuel qui pourra être « connecter » avec les chargeur de plugin tiers
Le code est écrit de manière à ce qu’il sera possible d’ajouter d’autres modèles si besoin.
Mon soucis (c’est pas le seul ) est que, lors de la désinstallation du plugin, le core ne supprime que les eqLogics de type <pluginId> (le type qui, dans mon cas, n’a pas d’eqLogic ) et pas les eqLogics de type <pluginId>_*
J’ai donc besoin de déclencher une procédure qui supprime les eqLogics <pluginId>_charger, <pluginId>_account, <pluginId>_vehicle et <pluginId>_account_* lors de la désinstallation du plugin.
Une alternative (mais c’est un peu une « usine à gaz ») serait
Créer un eqLogic <pluginId> lors de l’installation (ou de l’activation) du plugin tout en veillant à ce qui n’en existe qu’un seul.
Cet eqLogic devrait être invisible dans les interfaces du plugin et pas pouvoir être supprimer interractivement
Cet eqLogic ne serai donc supprimé que par le core lors de la désinstallation du plugin.
La méthode remove() de la class <pluginId> devra être surchargée pour qu’elle supprime les eqLogics <pluginId>_*. Cette méthode ne devra pas faire le nettoyage si elle est executée dans une classs héritière de <pluginId>.
J’ai déjà hésité à faire ce type d’archi mais perso je suis revenu en arrière, cela ne correspond pas à la philosophie de jeedom, y a surement du pour, probablement du contre, mais la question n’est pas là: ce n’est pas la façon de procéder et donc ca finira toujours pas être bancal et très difficile à maintenir, AMHA.
Je t’encourage à n’avoir qu’une seule class eqLogic et de gérer tes différents cas (charger, account, vehicle…) par une config sur ton eqLogic qui te permettra de faire la distinction.
Oui, je suis d’accord sur le principe.
J’avais commencé par ne pas utiliser d’eqlogic pour les accounts car ils n’ont pas besoin de commandes. Je passai donc par des objets avec les config dans la table « config » mais ça devenait trop lourd à gérer. J’ai ensuite tenter de n’utiliser qu’une seule classe eqLogic mais ça devenait aussi trop lourd car trop de différences entre les accounts et les chargers (je n’avais pas encore attaqué les vehicles). et puis il y a et aura les modèles d’accounts…
Je te remercie pour ton aide et de m’avoir confirmer que les functions <pluginID>_install()<pluginID>_remove() ne sont pas appelées comme décrit dans la doc.
Je vais trouver une solution pour contourner le problème. (au pire, j’interdirai de désinstaller le plugin )
) est que, lors de la désinstallation du plugin, le core ne supprime que les eqLogics de type 
) et pas les eqLogics de type 
)