Duel de technos : Oxid eSales vs. PrestaShop

Au niveau de l’exécution des controllers, quelques soucis dans Oxid par rapport à une implémentation plus carrée style ZF :

1. Parce que les controllers se trouvent dans un dossier “views” et non pas “controller(s)”
2. Les controllers sont utilisés davantage comme des actions de controllers et non pas des controllers qui englobent le comportement d’une entité, en témoigne la présence de multiples actions surtout dans la partie admin (par exemple Article_Overview, Article_Pictures sont deux actions différentes pourtant attachées à la même entité).

Toutefois le découpage est bien fait et avec le mécanisme de routage vu ci-dessus, cela laisse quand même pas mal de souplesse si l’on veut implémenter quelque chose.

Cependant on voit bien que c’est un peu brouillon notamment avec l’arrivée de la version 1.5. En effet avant il n’y avait pas de routage, on exécutait directement le bon script (cart.php, category.php) ; ces scripts sont toujours là pour des raisons de compatibilité ascendante.

Au niveau de l’exécution des controllers, quelques soucis également :

1. La méthode “run” est la seule méthode appelée et la seule possibilité pour différencier les actions à l’instar du CartController est de faire comme ci-contre, ce qui, vous en conviendrez, est assez inélégant, il eut mieux valu, que le dispatcher puisse appeler directement les bonnes actions.
2. On peut noter que pas de mal d’appels directs à des requêtes SQL sont effectués dans la couche controller (ex front/ContactController, front/StoresController), ce qui correspond à une rupture de couche.
3. On trouve aussi du code HTML en dur dans la couche Controller.

PS : On trouve dans Oxid une requête SQL dans la couche controller, et un appel à du html, mais cela reste marginal.

1. Une implémentation d’entité (étendant oxBase)
2. Une implémentation de collection (étendant oxList)

On constate que le mapping des propriétés d’une entité avec l’objet correspondant est effectué en lisant la structure de la table, par l’utilisation de méthodes magiques (dans oxBase). Ceci a l’avantage de ne poser aucun problème si l’on modifie la structure de la table, nous n’avons pas besoin de modifier le code (il faudra tout de même vider le cache).

Par ailleurs dans la couche model d’Oxid, on constate un début d’implémentation événementiel (même si le pattern event/listener n’est pas là), par exemple dans le save des model, on appelle une méthode ‘onChange()’ sur l’objet courant, que les classes filles peuvent surcharger à loisir.

Le seul reproche que l’on peut faire à cette implémentation est qu’il n’y a pas de couche DAO, par conséquent, si l’on veut changer de support physique de données ou même de SGBD, il n’y a aucun endroit où sont centralisées les requêtes.

Pour le reste, rien à dire, la couche model du pattern MVC est bien implémentée, on constate de nombreuses implémentations métiers dans cette couche, et la couche controller appelle directement les méthodes mises à disposition.

Par ailleurs, le fait de ne pas avoir implémenté de mécanisme de gestion de collection génère des problèmes. D’une part, il n’y a pas vraiment de convention de nommage à ce niveau (par exemple, ProductCore::getProducts (en statique), CategoryCore::getCategories (en statique)). D’autre part, plus embêtant si l’on doit implémenter une nouvelle entité, il faudra aussi implémenter son mécanisme de récupération de collection qui n’est pas fourni en standard.

Encore un défaut, on constate que le mapping entre les attributs d’objets et les champs des tables, doivent s’implémenter dans le code : problème donc si l’on modifie la structure d’une table.

1. Utilisation de fichier de layout (layout/base.tpl) pour définir la structure d’une page :
   
2. Possibilité en recréant un thème d’hériter d’un thème existant sans recopier tous les fichiers.
3. Utilisation de nombreux plugins smarty. Voici un exemple :
   
4. Utilisation du tag ‘block’ smarty. Ainsi il est possible de modifier l’affichage d’un block

En revanche quelques points négatifs :

1. Il n’est pas possible d’ajouter un ‘block’ ou template dans une colonne (content ou left) sans modifier le template conteneur. (et sans faire du bricolage js bien sûr:))
2. Si l’on prend le cas du template sidebar.tpl, celui-ci est couplé à de très nombreux modules et comme ce template est affiché sur presque toutes les pages, on est obligé devant chaque bloc de faire une condition pour savoir sur quelle page on est pour afficher ce bloc, ce qui assez moyen.

1. Utilisation d’un framework CSS pour gérer le positionnement des éléments
2. La possibilité de surcharger les templates des modules en les positionnant au bon endroit : la documentation officielle explique comment faire.
3. L’utilisation de HOOK colonnes pour ajouter facilement du contenu à une colonne donnée

En revanche quelques points négatifs :

1. Pas d’utilisation de layout -> on doit ouvrir ses balises dans header.tpl et les fermer dans footer.tpl, ce qui est inélégant en plus d’être source d’erreurs
2. A priori, il n’est pas possible d’utiliser l’héritage de thème
3. Utilisation de beaucoup de javascript avec des fonctions dans les fichiers de template, cela aurait pu être déporté dans des fichiers js

1. Surcharger les thèmes, avec un mécanisme de fallback sur ceux-ci, surcharger les éléments de vue des modules
2. Surcharger les comportements métiers (fichier des couches models et controllers) et de réaliser un chainage d’héritage pour résoudre les conflits dans le cas où deux classes hériteraient d’un même parent.
3. Manipuler via le BO l’installation / désinstallation de module

Dans la pratique on regrettera :

1. Aucune convention/normes pour le positionnement des classes du module : chacun fait comme il veut du moment que cela respecte le MVC.
2. L’installation / désinstallation de module via le BO est encore incomplète. En effet les tables doivent être créées manuellement via des scripts et les upgrades sont assez pénibles, il faut vider en permanence des tables de config.

1. Surcharger les éléments de vue des modules (Templates, JavaScript et feuilles de styles) afin que les thèmes puissent s’adapter au mieux à ceux‑ci.
2. Surcharger les comportements métiers (fichiers classes et fichiers contrôleurs) afin de ne cibler qu’une partie des éléments désirés.
3. Créer de nouveaux modules : à positionner dans le dossier modules/ de votre application
4. Gérer la création/suppression dynamique des ressources du module (tables en sgbd) via l’install/desinstall d’un module.

Dans la pratique on regrettera :

1. De ne pouvoir surcharger qu’une fois une classe donnée, sinon -> gestion de conflit
2. En version 1.5.X de Prestashop, il est encouragé de respecter une arborescence MVC au niveau des modules, cependant cette arboresence n’est pratiquement reportée sur aucun module de base ce qui pose des problèmes de rupture de couche.