Développement de module : des règles sur ce qui est interdit / autorisé ?

[SmartPlugs]

Bonjour à tous, 

 

Voilà, je l'ai bien mauvaise aujourd'hui.

Mon nouveau module vient de se faire refuser pour la 4eme fois.

 

Première fois : le module propose implémente une surcharge de Db. Refusée car vous comprenez, les surcharges de Db ça ne se fait pas. Bon ...

 

Deuxième fois : j'ai surchargé Product à la place, ce que je ne voulais pas faire initialement car la méthode est longue, qu'elle a changé souvent, qu'il n'y a pas de hook etc. Refusé car la surcharge est trop longue. Re-bon ....

 

Troisième et quatrième fois : j'ai réussi à expliquer que la surcharge est longue car elle doit fonctionner sur toutes les versions de PS et que la méthode native a changé 10 fois (et donc tous ces changements sont dans la surcharge, ben oui). Mais refusée de nouveau car le code copié dans prestashop (cette surcharge de 200 lignes ce n'est que pour ajouter 3 lignes au milieu) doit être mieux sécurisé ! Autrement dit, on me demande de sécuriser le code de PrestaShop oui oui.

 

Sympa non ?

 

 

 

[SmartPlugs]

Oui, je parlais bien d'une surcharge de la classe Db native de PrestaShop.

[Eolia]

Non mais Addons c'est comme la 1.7, faut oublier dorénavant^^

[coeos.pro]

Par curiosité, il fait quoi votre module?

[SmartPlugs]

Bien, j'aimerais bien qu'il soit validé / en vente avant d'en parler mais il ne fait rien de grave

[coeos.pro]

J'ai fait énormément de modules, je n'ai jamais eu besoin de changer Db, c'est juste pour donner des conseils

[SmartPlugs]

Et oui, je comprends.

 

Ma surcharge avait uniquement pour but de modifier une clause d'un select dans une méthode assez longue de la classe Products. Or cette clause se trouve au milieu de la méthode et je n'avais absolument pas envie de recopier toute la méthode dans une surcharge pour simplement ajouter 3 lignes au milieu. En effet cette pratique est selon moi mauvaise car cette méthode surchargée ne pourra plus bénéficier des mises à jour de PrestaShop.

 

Comme cette clause est tout a fait identifiable, j'avais décidé dans un premier temps de surcharger la classe Db pour que la clause soit modifiée avant exécution de la requête. Dans Db, la surcharge pouvait être placée en début de méthode et je pouvais surtout faire un parent::methode() ensuite ce qui est largement plus satisfaisant côté qualité selon moi.

 

Mais bon... On ne surcharge pas cette classe.

[coeos.pro]

En tout cas overrider Db pour changer une requête SQL est effectivement une mauvaise approche.

[SmartPlugs]

J'ai confiance dans mon code

[Eolia]

Perso je n'utilise jamais d'override pour mes modules car vu que Prestashop s'amuse à modifier les classes et leur définition, tout le principe s'écroule^^

 

J'avoue qu'il faut sacrément ruser parfois 

[SmartPlugs]

Si je peux les éviter, j'évite aussi mais surtout parce que de toute manière chaque méthode ne pourra être surchargée que par un seul module. Et aussi à cause de /cache/class_index.php qui doit représenter 75% de mes tickets de support.

[BeComWeb]

Je comprends que la solution soit pénible pour toi mais je comprends leur refus, la classe Db est beaucoup trop centrale et sensible.

Par contre refusé ta solution de contournement (override de Product) là c'est un peu abusé, surtout si tu leur as expliqué la situation.