Jump to content

[Proposition] Modification du core Prestashop (fichier /classes/Module.php)


Recommended Posts

Bonsoir,

j'ai une "suggestion" d'amélioration du core de Prestashop pour, éventuellement, une prochaine version du CMS.

J'ai découvert récemment Prestashop et il m'est apparu (dès les premiers jours) un problème qui me semble important et que j'ai retranscrit dans ce post (http://www.prestashop.com/forums/viewthread/58403/).

J'ai donc regardé un peu le core et comment fonctionnent ces modules de "type block". Il me semble "logique" de modifier le core et ce pour le confort de l'utilisateur (sauf si quelque chose m'échappe).

Je résume si vous n'avez pas lu mon précédent post sur le forum : l'utilisateur qui souhaite déplacer un module dans une position qui n'est pas définie dans le core du module ne peut le faire sans modifier le fichier "/modules/monmodule.php" du module en question (on appel ça un "Hack").

Ma suggestion est donc la suivante :

Ajouter des fonctions "public" dans le fichier "classes/Module.php", pour chacun des Hooks.
En effet tous les modules sont en "extends" (héritent) de la classe mère "Module" (/classes/module.php), la classe fille (le module) hérite donc de ces fonctions. Le but de la modification serait donc d'ajouter ces fonctions (ex : hookFooter) dans le core (classes/Module.php), ce qui permettra d'empêcher ce problème récurrent et vraiment problématique selon moi.

Il faut également savoir qu'il n'y aura aucune modification à faire dans les modules existants étant donné que la classe fille (le module) qui hérite des fonctions de la classe mère "Module" (/classes/module.php) pourra "surcharger" ces fonctions (les modules tels qu'ils sont écrit à l'heure actuelle le feront très bien), dans ce cas là ce seront les fonctions de la classe fille (le module) qui seront utilisées. Si elles ne sont pas définies dans la classe fille alors ce seront celles de la classe mère qui rentreront en jeu (d'où l'intérêt de cette modification).

(Je me doute que ceux qui liront ce post connaissent très bien le fonctionnement de la POO etc... Ces explications sont donc uniquement là pour "imager" la chose)

Voilà j'éspère ne pas être à côté de la plaque. En éspérant pouvoir aider au développement de ce CMS ;)

(Je ne savais pas trop si je devais contacter directement via le formulaire de contact ou poster ici, désolé donc si j'ai mal fait)

A bientôt.

Link to comment
Share on other sites

Hello,

Au risque de paraitre méjugeant, je pense que c'est carrément une mauvais idée ... même implémenter un hookName par défaut qui signalerai au développeur que le hookModule n'est pas définie.
Exemple dans la fonction hookExec() de la classe abstraite Module:

if (is_callable(array($moduleInstance, 'hook'.$hook_name)) AND $show)
{
   $hookArgs['altern'] = ++$altern;
   $output .= call_user_func(array($moduleInstance, 'hook'.$hook_name), $hookArgs);
}
else
{
   // Bad idea
   $output .=  get_class( $moduleInstance) . '::hook'.$hook_name.' is not implemented';
}



Néanmoins, je ne suis pas que médisant, ta remarque et ton intention sont honorable. Et si je peu me permettre un conseil a qui veut aider au développement de prestaShop je dirai qu'il serai intéressant de se pencher sur le fichier /themes/prestashop/config/config.xml et de AdminAppearance ( le module d'administration des theme) qui permettrai de "reconfigurer" les Hook & Module selon le theme. De cette façon vous comprendrez pourquoi je pense que c'est une mauvaise idée que d'implementer "tout" les hookName d'un module ...

PS : L'avantage dans le "greffage" de module est est dans la phase de développement.

Link to comment
Share on other sites

Bonjour,

j'avoue ne pas avoir tout compris à ta remarque...

J'ai testé l'implémentation dont je parle et ça fonctionne.

Cela dit étant donné que je ne suis pas sur d'avoir saisi ton propos ,je ne sais pas si on parle de la même chose j'ai mit en ligne un exemple de fichier modifier dans le "bug_traker" : http://www.prestashop.com/bug_tracker/view/4781/ (si ça t'intéresse de voir ce à quoi je pensais, c'est à la fin du fichier).
En fait ma suggestion d'implémentation part du principe qu'il va appeler une fonction hook déjà définie pour gérer l'affichage des autres hooks, après on peut tout à fait voir à gérer des conditions permettant de savoir quel hook est déjà définis ou non (mon fichier étant là à titre d'exemple "simpliste").

Mon propos et ma modification n'ont rien avoir avec la gestion du templeting... Cela dit d'après ce que j'ai pu en voir ce serait également à revoir, comme tu sembles le dire.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...