[Question aux codeurs] Méthodes & avis d'override d'AdminTab

[Luc Lérot Freelance]

Bonjour,

 

J'aimerais avoir vos avis sur 2 façons d'overrider un adminTab core via un module.

 

La première, c'est tout simplement la méthode native, en positionnant la classe overridée dans un répertoire modules/mon_module/override/controllers/admin/AdminProductsControllers.php

 

La deuxième, c'est utiliser l'objet Tab de PShop à l'install de mon module pour "re-rooter" l'AdminProductsControllers.php vers la classe résidant à l'intérieur de mon module (donc sans utiliser le merge natif de PShop)

 

Qu'est-ce qui vous semble le mieux, le plus simple, le plus judicieux, le moins dangereux...etc. Je pose la question parce que je n'arrive pas à me faire un avis.

[Prestaspirit]

Bonjour Luc,

 

Les 2 solutions fonctionnent, mais la première est prévu pour alors qu'elle est le but d'utiliser la deuxième?

 

Franck

[Luc Lérot Freelance]

Bonjour Franck,

 

Je sais bien que les 2 fonctionnent. le "but" c'est justement le sujet de ce topic...Le fait qu'il existe 2 méthodes peut donner à réfléchir sur l'une ET l'autre, les avantages et inconvénients des 2.

 

Personellement, je suis plus confortable avec le "détournement" d'une classe core via de l'objet plutot que d'ouvrir un fichier et merger son contenu avec un autre...

Edited November 9, 2012 by Luc Lérot Freelance (see edit history)

[DrÿSs']

Personnellement je trouve ça très crade de modifier la liste des menu initiaux présents dans la solution.

 

Bref, cela dépends de ce que tu veux faire :

 

- une surcharge du contrôleur pour modifier/ajouter une fonctionnalité

 

- une modification/ajout d'un nouvel onglet pour faire une feature complète

 

Les besoins et solution ne sont pas les même !

Le mieux serait encore de désactiver le tab existant et d'en créer un nouveau, mais si c'est pour dupliquer le code de l'onglet AdminProductsControllers vers celui de ton module... autant faire une surchage.

[Luc Lérot Freelance]

Personnellement je trouve ça très crade de modifier la liste des menu initiaux présents dans la solution.

 

Bref, cela dépends de ce que tu veux faire :

 

- une surcharge du contrôleur pour modifier/ajouter une fonctionnalité

 

- une modification/ajout d'un nouvel onglet pour faire une feature complète

 

Les besoins et solution ne sont pas les même !

Le mieux serait encore de désactiver le tab existant et d'en créer un nouveau, mais si c'est pour dupliquer le code de l'onglet AdminProductsControllers vers celui de ton module... autant faire une surchage.

 

Donc merger ton contenu d'override (de ton module par exemple) avec le contenu déjà présent des overrides natifs ne te gêne pas ?

[DrÿSs']

Je ne merge rien, PrestaShop le fait à l'installation de mon module !

 

Nativement, il n'y a aucun override, après si tu installe 10 000 modules X et Y, oui tu peux te retrouver avec un merge posant problème dans les surcharges... mais pour une utilisation "normale", il n'y aucun problème !

[Luc Lérot Freelance]

Oui, biensur !! Mais ca ne te gêne pas ? Tu ne préfères pas faire un extend ?

[DrÿSs']

C'est déjà le cas de ma surcharge, elle extends ma classe du coeur.

 

En quoi cela devrait me géner que PrestaShop merge les différentes surcharges des modules dans une classe qui extends celle du coeur ? Si les sucharges ne se marchent pas dessus...

[Luc Lérot Freelance]

 

En quoi cela devrait me géner que PrestaShop merge les différentes surcharges des modules dans une classe qui extends celle du coeur ? Si les sucharges ne se marchent pas dessus...

 

Ben c'est le sujet du topic justement

 

Soit utiliser TA classe dans ton module en gérant l'objet Tab à l'install, soit utiliser la structure override/classes ou override/controllers et laisser PShop copier/coller le code...

[DrÿSs']

Oui c'est pour cela que je te dis que les besoins ne sont pas les mêmes dans les deux cas.

 

Cela dépends de ce que tu veux faire :

 

- une surcharge du contrôleur c'est bien pour modifier/ajouter une fonctionnalité existante

 

- une création d'un tab c'est bien pour créer ton propre onglet pour une nouvelle fonctionnalité

 

Tu ne peux pas comparer les deux, cela n'a rien à voir

 

Si tu veux modifier l'onglet Produit, tu ne détournera pas son onglet vers ta propre classe dans ton module (cela veut dire que tu va dupliquer toute le code du contrôleur initial), mais tu feras une surcharge.

 

Après, à savoir si le merge peut ou non poser problème dans certains cas de figure, c'est un autre problème...

[Luc Lérot Freelance]

 

Si tu veux modifier l'onglet Produit, tu ne détournera pas son onglet vers ta propre classe dans ton module (cela veut dire que tu va dupliquer toute le code du contrôleur initial), mais tu feras une surcharge.

 

 

Ben si justement, c'est tout l'intérêt de l'objet Tab, et en utilisant un extend dans ta propre classe, tu n'as pas à copier/coller de code...

[DrÿSs']

Ha bah non désolé moi j'ai jamais surchargé un onglet existant dans un autre tab

Je fais mes propre admintabcontroller, pour gérer mes objets !

 

Dis-moi, afin de m'éclairer, quel comportement aimerais-tu avoir au final ? (que veux-tu modifier/ajouter à l'onglet produit grosso modo).

[Luc Lérot Freelance]

Bon, j'ai l'impression que j'ai mal tourné ma question...je ne cherche pas à faire quelque chose en particulier, je cherche simplement à avoir des avis de codeurs sur l'utilisation d'une méthode ou d'une autre.

 

Je pensais que la méthode de "détournement" des overrides était tout autant utilisée que la méthode native de merge.

 

Pour info donc, le code dont je parle est ci-dessous. L'exemple qui j'ai pris c'est la surcharge de la méthode de génération de table des images sur une fiche produit BO. A noter que c'est du pseudo-code, j'ai pas le code d'origine sous la main.

 

A l'install d'un module :

 

$oTabAdminProductController = Tab::getInstanceFromClassName ('AdminProductsController');
$oTabAdminProductController->module = 'Mon_Module';
$oTabAdminProductController->save();

 

 

Dans l'architecture du module (je sais plus à quel endroit exactement), un fichier AdminProductsController.php :

 

class AdminProductsController extends AdminProductsControllerCore {
public function initFormImages($obj) {
	//Code de surcharge
}
}

 

Cette méthode permet de "détourner" l'adminTab AdminProductsController sans passer par le merge natif (et perso, je suis plus à l'aise avec ca)

Edited November 15, 2012 by Luc Lérot Freelance (see edit history)

[DrÿSs']

C'est pas catholique ton truc

 

Mais oui pourquoi pas, un peu tordu je trouve.

 

Mais du coup, si tu installe un autre module qui a besoin de surcharger ton contrôleur product, alors celle-ci se retrouve inopérante non ? (l'héritage multiple n'existant pas en PHP).

 

En fait, cette méthode de détournement rend inopérante la fonctionnalité de surcharge initiale de PrestaShop, donc je préfère la solution du merge perso plus propre !

[Luc Lérot Freelance]

pas catholique, pas catholique...parce PShop c'est super catholique comme code peut être ?!

 

"Inopérante" pas vraiment, la méthode du merge a la même incapacité lorsqu'une méthode est déjà overridée, ca change pas grand chose.

 

Ceci dit, en même temps que je postais mon code, je me suis dit que le merge avait 1 avantage, c'est qu'un message est affiché à l'install du module pour prévenir que la surcharge est impossible dans le cas où une méthode serait déjà surchargée. Pas avec ma "méthode".

 

Mais ca valait le coup d'essayer.

[Luc Lérot Freelance]