Proposition améliorations plugin.template

domotruc · Août 2, 2018, 7:59

Bonjour,
Je développe le plugin jElocky (pour lequel je n’ai pas encore le petit tag ). Il nécessite plusieurs types d’eqLogic et j’aurais besoin des améliorations suivantes, proposées dans le PR 1115, dans plugin.template:

Possibilité de spécifier l’eqLogic_type sur action add
Correction d’un bug lié à l’eqLogic_type sur action remove
Amélioration de l’appel au callback prePrintEqLogic:
- Déplacement de l’appel après affectation du li_eqLogic actif
- Passage de l’eqLogic_id au callback

D’avance merci Loïc de regarder ces évolutions avec bienveillance

Loic · Août 2, 2018, 2:04

Bonjour,
Ca existé a une époque dans jeedom mais c’est assez complexe a gerer coté core donc j’ai du le retirer un plugin a un type et jeedom appels cette calss.

Par contre rien ne t’empêche de faire des sous class gérer dynamiquement, regarde du coté du plugin monitoring2 qui le fait.

domotruc · Août 6, 2018, 1:55

Bonjour Loïc,

Au vu de ta réponse, j’ai le sentiment de ne pas avoir été clair sur le contenu du PR proposé.

Tout existe déjà dans le core et est déjà utilisé, par exemple par le plugin ecodevice sur lequel j’ai pris exemple.
La seule chose qui manque est la possibilité de spécifier l’eqLogic_type sur ajout d’un eqLogic via l’interface desktop (action add). Le plugin ecodevice crée les sous eqLogic automatiquement par code et n’a pas ce besoin.
J’ai bien sûr testé ce PR plusieurs jours et n’ai pas noté de problèmes.

J’ai regardé le plugin monitoring2 (merci pour le lien) et ce serait effectivement faisable de cette façon.
Le PR corrige aussi un bug sur action remove (sans conséquence fonctionnelle puisque seul le type d’eqLogic affiché dans la boite de dialogue de confirmation de suppression est erroné).
Enfin, 3ème point du PR, le plus important car là je ne vois pas comment faire autrement, j’ai besoin de récupérer l’eqLogic_id dans le callback prePrintEqLogic appelé avant affichage d’un eqLogic. Ceci afin d’interroger le serveur elocky pour rafraîchir les données juste avant affichage et édition.

Dis moi ce que tu es prêt à prendre, je referai le PR en conséquence.
Merci d’avance.

Loic · Août 10, 2018, 8:09

En faite ca peut pas marché tu as plus eqType pour un même plugin l’autoload du core ne sait pas le gérer et ne doit pas le gérer. Avant il le faisait mais les temps de chargement des plugins étaient beaucoup plus long car il y avait de la recherche.

Pour etre congrès tu vas avoir un eqType : monplugin et un eqType monplugin_1 quand jeedom va tomber sur monplugin_1 si il n’a pas eu de monplugin avant il n’arrivera pas a trouver le fichier de class.

domotruc · Août 10, 2018, 10:32

Bonjour Loïc,
Tu es sûr ?

Voici la fonction autoload du core (voir contenu de la branche if):

function jeedomPluginAutoload($_classname) {
	$classname = str_replace(array('Real', 'Cmd'), '', $_classname);
	$plugin_active = config::byKey('active', $classname, null);
	if ($plugin_active === null || $plugin_active == '') {
		$classname = explode('_', $classname)[0];
		$plugin_active = config::byKey('active', $classname, null);
	}
	try {
		if ($plugin_active == 1) {
			include_file('core', $classname, 'class', $classname);
		}
	} catch (Exception $e) {

	} catch (Error $e) {

	}
}

Donc si le sous eqType est construit à partir de celui du plugin (i.e. monplugin_xxx), et que le fichier monplugin.class.php inclut bien monplugin_xxx.class.php, la sous-classe est bien trouvée.

Je t’assure ça marche bien. Et le plugin ecodevice qui utilise ce principe marche bien aussi.

Par contre, ce serait bien que tu prennes la 3ème partie du PR permettant de connaître l’eqLogic_id sur callback prePrintEqLogic appelé sur affichage d’un eqLogic. Car là je ne vois comment faire autrement.

domotruc · Septembre 13, 2018, 6:14

Bonjour Loïc,

Je me permet de revenir vers toi quant à mon message précédent.

De mon point de vue, le core gère parfaitement les sous eqType (j’ai passé bcp de temps à analyser le code et à faire des tests avant de proposer cette amélioration/rationalisation).

Il y a aussi le passage de l’eqLogic_id au callback prePrintEqLogic : sans possibilité d’accéder à ce paramètre dans le callback, les possibilités sont très limitées.

D’avance merci,
domotruc

Loic · Septembre 13, 2018, 8:04

Salut,

Désolé j’ai pas eu le temps de me pencher là dessus…

Pour les sous eqtype oui le core les gère mais je prévois de retirer le support un jour car ça permettrait de gagner un peu de temps au chargement des classes ce qui est loin d’être négligeable…

Pour le prePrint je comprends pas le soucis car de mémoire il reçoit en paramètre l’objet eqLogic et donc toute les propriétés de celui ci

domotruc · Septembre 15, 2018, 8:24

Bonjour Loïc,

Désolé j’ai pas eu le temps de me pencher là dessus…

Pas de problème, je comprends.

Pour les sous eqtype oui le core les gère mais je prévois de retirer le support un jour car ça permettrait de gagner un peu de temps au chargement des classes ce qui est loin d’être négligeable…

OK, c’est clair maintenant. Faudra prévenir à l’avance parce que ça va casser quelques plugins (au moins ecodevice)…

Pour le prePrint je comprends pas le soucis car de mémoire il reçoit en paramètre l’objet eqLogic et donc toute les propriétés de celui ci

Bien non, c’est bien ça le problème, voici le code (issu de la branche alpha):

$(".li_eqLogic,.eqLogicDisplayCard").on('click', function () {
    jeedom.eqLogic.cache.getCmd = Array();
    if ($('.eqLogicThumbnailDisplay').html() != undefined) {
        $('.eqLogicThumbnailDisplay').hide();
    }
    $('.eqLogic').hide();
    if ('function' == typeof (prePrintEqLogic)) {
        prePrintEqLogic();
    }
    if (isset($(this).attr('data-eqLogic_type')) && isset($('.' + $(this).attr('data-eqLogic_type')))) {
        $('.' + $(this).attr('data-eqLogic_type')).show();
    } else {
        $('.eqLogic').show();
    }
    if($('.li_eqLogic').length != 0){
        $('.li_eqLogic').removeClass('active');
    }
    $(this).addClass('active');
    if($('.li_eqLogic[data-eqLogic_id='+$(this).attr('data-eqLogic_id')+']').html() != undefined){
        $('.li_eqLogic[data-eqLogic_id='+$(this).attr('data-eqLogic_id')+']').addClass('active');
    }
    if (!url.match('#')) {
        $('.nav-tabs a[href="#eqlogictab"]').click();
    }
    $.showLoading();
    jeedom.eqLogic.print({
        ...

Aucun paramètre n’est passé au prePrintEqLogic(). Et il est appelé avant que la classe active soit positionnée si bien qu’il n’est pas possible dans le callback d’obtenir l’id de l’eqLogic concerné.

Je proposais donc dans le PR de modifier comme suit l’appel:

    prePrintEqLogic($(this).attr('data-eqLogic_id'));

Je peux refaire le PR, dans la branche que tu souhaites, dis moi.

Loic · Septembre 15, 2018, 12:15

Effectivement le pre ne reçoit rien on peut lui passer l’id sinon tu as printEqLogic qui lui reçoit tout eqLogic

domotruc · Septembre 18, 2018, 4:48

Bonjour Loic,
Merci pour ta réponse.
J’ai besoin de mettre à jour les données en BD avant que celle-ci ne soit interrogée pour récupérer les données à afficher. C’est trop tard dans le printEqLogic. Le bon endroit est le prePrintEqLogic.
J’ai proposé le PR.
Merci encore pour tout.

Loic · Septembre 18, 2018, 9:20

J’ai vu merci pour le PR par contre peux tu le faire dans la branche Alpha ?