Question code de "widdgetPossibility" de la class php "cmd"

Bonjour,
Le code de la fonction widgetPossibiliy de la class php cmd du core 4.1.22 commence par ces lignes:

public function widgetPossibility($_key = '', $_default = true) {
        $class = new ReflectionClass($this->getEqType_name());
        $method_toHtml = $class->getMethod('toHtml');
        $return = array();
        if ($method_toHtml->class == 'eqLogic') {
                $return['custom'] = true;
        } else {
                $return['custom'] = false;
        }
        $class = new ReflectionClass($this->getEqType_name() . 'Cmd');
        $method_toHtml = $class->getMethod('toHtml');
        if ($method_toHtml->class == 'cmd') {
                $return['custom'] = true;
        } else {
                $return['custom'] = false;
        }

Je ne comprend pas le but du premier if else car il me semble que le deuxième if else va de toutes façons écraser la valeur de $return['custom'] définie par le premier.

Soit

  • Il y a une subtilité que je n’ai pas compris et alors merci de m’éclairer.
  • Le premier if else est inutile et pourra être retiré du code dans une version future de core.
  • La deuxième test ne doit être effectué que si le premier a donné true (ou false).

La variable $_widgetPossibility peu etre sur la class eqlogic ou sur la class cmd du plugin, ou sur les deux. Donc le return peu etre false car pas sur la class eqlogic, mais finalement true car sur la cmd.

Peut importe que $return soit mis à false ou true sur la base de eqLogic.

Dans tous les cas, le résultat sur la base de cmd écrasera le résultat sur la base de eqLogic qui ne sera donc jamais pris en compte.

Ah oui pas faux …

@loic ?

dans la mesure où le résultat est un tableau, il me parait logique de mettre une clé différente, par exemple sur le 2e if / else mettre une clé ‹ customCmd › pour ne pas écraser la valeur ‹ custom › …
La même méthode existe dans la classe EqLogic et elle commence presque pareil, du coup c’est peut être juste un copié / collé mal adapté.

Il faut surtours voir comment le retour est utilisé dans le core par les fonctions qui appellent celle-ci. Mon impression est qu’il faut plutôt quelque chose du genre

$return = false;
if (<test pour eqLogic>) {
    $return = true;
}
if (<test pour cmd>) {
    $return = true;
}

ou supprimer le test sur eqLogic.

Mais je ne connais suffisamment le core pour en être sûr.

Ha oui alors s’il faut voir comment la fonction est utilisée alors… en effet dans ce cas, autant conserver la valeur actuelle - donc la dernière - et supprimer le début qui est écrasé. Voici ce que j’ai trouvé sous netbeans pour l’utilisation:


Clairement on n’utilise que ‹ custom › ou bien ‹ custum::qqchose › et je ne sais pas ce que ça désigne - je ne maitrise pas encore les widgets.

ça me fait penser, qu’on devrait utiliser un outil comme Sonarqube qui permet d’analyser le code et détecter le code inutile, redondant, code mort.

Si pas de methode sur eqlogic → $return[‹ custom ›] = false;
Mais si methode sur commande → $return[‹ custom ›] = true;

Le seul cas d’écrasement c’est si pas eqlogic ni cmd, qui ecrase false par … false. Mais faut bien tester les deux.

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