Duel de technos : Oxid eSales vs. PrestaShop

Un duel n’est intéressant que si les 2 adversaires sont comparables, et il se trouve que techniquement PrestaShop et Oxid eSales sont deux solutions aux socles techniques très semblables.

Oxid eSales est une solution e-Commerce très répandue en Allemagne et dans le reste du monde (40.000 sites en production) et on ne présente plus PrestaShop, plus de 125.000 boutiques dans le monde générant un CA cumulé de plus 30 millions de dollars…

Avant le comparatif, le contexte : je vais vous expliquer ici pourquoi il est pertinent de comparer techniquement ces 2 solutions, en prenant point par point les éléments communs.

Note de l’auteur
Ce comparatif a été réalisé à partir mon expérience personnelle. En tant qu’expert technique à l’e-Commerce Academy, j’ai l’opportunité d’appréhender tous les aspects techniques qui caractérisent les différentes solutions, tant sur Oxid eSales que sur PrestaShop, et d’identifier les similitudes.

1. Contexte du duel de technos

1.1 Même socle PHP/MySQL

Oxid eSales et PrestaShop sont deux solutions basées sur le couple PHP/MySQL.

1.2 Toutes 2 implémentent un pattern MVC

Couche Controller

La couche controller PrestaShop se trouve dans les dossiers controllers/[admin|front] et est pilotée par les classes mères : FrontControllerCore, AdminControllerCore et Controller (pour les controllers) et DispatcherCore pour le routage.

La couche controller Oxid se trouve dans les dossiers views et admin et est pilotée par les classes mères : oxUBase, oxAdminView (pour les controllers) et oxShopControl pour le routage.

On retiendra de ces deux couches controller, que tous les fichiers sont dans les mêmes dossiers et que les implémentations sont toutes deux faites maison, aucun framework n’est utilisé et les fonctions utilitaires de l’un et l’autre se ressemblent peu ou prou.

Couche Modèle

La couche Modèle PrestaShop se trouve dans le dossier classes et est pilotée par la classe Mère ObjectModel, et la couche d’accès aux données dans le dossier classes/db

La couche modèle Oxid se trouve dans le dossier core et est pilotée par oxBase et oxList. Elle utilise une petite librairie adodblite pour la couche d’accès aux données.

On retiendra de ces deux couches modèles quelles sont aussi faites ‘maison’ et que tous les fichiers de modèles sont dans un dossier commun.

Couche Vue

  • Couche Vue PrestaShop : Utilisation de smarty
  • Couche Vue Oxid : Utilisation de smarty également

On retiendra de ces couches vues, que toutes deux utilisent le même moteur de template, avec des templates associés rangés dans des thèmes.

1.3 Ajout de fonctionnalités

Les deux solutions permettent d’ajouter de nouvelles fonctionnalités (extensions) à la plateforme existante et toutes deux implémentent des mécanismes permettant de modifier les fonctionnalités natives du noyau sans modifier le contenu du core.

A ce niveau nous avons assez de points pertinents de comparaison pour détailler point par point lequel est le mieux implémenté et/ou le plus robuste dans ses choix d’implémentations.

Au 13 décembre 2012, le comparatif sera effectué sur les versions suivantes :

  • 1.5.2 de PrestaShop
  • 4.6.3 de Oxid CE

Je ne m’appuierai pas sur cet article sur ce qui pourrait sortir dans les prochaines versions, les 2 solutions ont évidemment des roadmap techniques.

2. Comparatif Oxid eSales vs. PrestaShop

2.1 Couche Controller

Petit rappel : la couche controller d’une application web a trois rôles majeurs :

  1. Routage de la requête HTTP
  2. Exécution d’une action (potentiellement faire appel au modèle et/ou à la vue)
  3. Renvoyer une réponse HTTP au navigateur (réponse 200, avec du html, JSON, xml, ou 30[X] : redirections)
Oxid eSales : Couche Controller
Oxid eSales vs. PrestaShop : couche controller Oxid eSalesLe routage sur Oxid eSales s’effectue grâce à la classe oxShopControl et plus précisément aux paramètres “cl” et “fnc” passés en GET dans l’url de la requête. Simple mais efficace : la gestion de l’url rewriting est faite en amont, ce très bon article explique bien ce mécanisme. Les urls réécrites sont stockées dans une table oxseo. 

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.

PrestaShop : Couche Controller
Oxid eSales vs. PrestaShop : couche controller PrestaShop (getController)Le routage sur PrestaShop est effectué dans la classe Dispatcher et plus particulièrement en utilisant le paramètre “controller” passé en GET dans l’url de la requête. La gestion de l’url rewriting se fait également en partie grâce aux fichiers meta.xml qui contiennent un ensemble d’instructions d’url rewrite et a priori aux champs link_rewrite dans les tables category_lang et product_lang. 

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. Oxid eSales vs. PrestaShop : couche controller PrestaShop (postProcess)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.

Oxid eSales vs. PrestaShop
Bilan sur la couche Controller

Je mettrai les 2 couches controllers de ces solutions à égalité en tenant compte du fait que l’implémentation de Oxid semble plus robuste car elle est en place depuis de nombreuses versions, alors que pour PrestaShop c’est en place depuis la version 1.5 seulement.

2.2 Couche Modèle

Petit rappel : la couche modèle d’une application a deux rôles majeurs :

  1. Implémentation de traitement métier
  2. Interfaçage entre le support physique de données (ex BDD, fichier xml), et le contexte applicatif en mémoire (objet si c’est de la POO, tableau et variable pour du procédural)
Oxid eSales : Couche Modèle
La couche model d’Oxid se trouve dans le dossier core/ et est divisée en 2 parties : 

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

Oxid eSales vs. PrestaShop : couche model Oxid eSales (méthodes magiques)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.

PrestaShop : Couche Modèle
La couche model de PrestaShop se trouve dans le dossier classes/ et ne contient qu’une partie : une implémentation d’entité étendant d’ObjectModel.On peut faire le même reproche à PrestaShop qu’à Oxid sur la couche DAO. 

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.

Oxid eSales vs. PrestaShop
Bilan sur la couche Modèle

Un point pour Oxid pour l’implémentation de sa couche modèle.

2.3 Couche Vue

Petit rappel : la couche vue d’une application a deux rôles majeurs :

  1. Présentation des données
  2. Mise en page
Oxid eSales : Couche Vue
Comme précisé en début d’article, Oxid utilise Smarty comme moteur de template à l’instar de PrestaShop. Le dossier thème utilisé pour le demoshop Oxid est azure (il se trouve dans le dossier out/azure). De bons points sont à signaler : 

  1. Utilisation de fichier de layout (layout/base.tpl) pour définir la structure d’une page :
    Oxid eSales vs. PrestaShop : couche vue Oxid eSales (layout/template)
  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 :
    Oxid eSales vs. PrestaShop : couche vue Oxid eSales (plugins Smarty)
  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.
PrestaShop : Couche Vue
Comme déjà dit, PrestaShop utilise Smarty comme moteur de template à l’instar de Oxid.Le dossier thème utilisé par défault pour PrestaShop est default (il se trouve dans le dossier themes/default).De bonne choses sont à signaler : 

  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

Oxid eSales vs. PrestaShop
Bilan sur la couche Vue

Bien que je n’aime pas du tout le fait de ne pas utiliser de layout, je vais mettre PrestaShop et Oxid à égalité pour l’implémentation de leur couche vue.

2.4 Installation de modules et modification du comportement

Alors là, les 2 solutions vont se targuer techniquement d’être des plateformes modulaires et vont présenter les nouvelles implémentations comme des “modules”.

On va jouer un peu sur les mots mais dans la notion de modules, il y a l’idée de composant, avec une notion d’autonomie et d’indépendance de ces composants les uns par rapport aux autres. Or on l’a bien vu, le fait que toutes les classes sont dans un seul dossier et qu’il y a des dépendances de certaines entités jusque dans les classes mères (ex : cart que l’on trouve dans FrontControllerCore pour PrestaShop et dans oxuBase pour Oxid) me fait dire que ni l’une ni l’autre ne sont des plateformes modulaires. Elles sont cependant extensibles et disposent de mécanismes permettant de modifier le comportement natif sans toucher le code du noyau.

Oxid eSales : Installation de modules et modification du comportement
D’après la documentation officielle d’Oxid à ce sujet il est possible de : 

  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.
PrestaShop : Installation de modules et modification du comportement
D’après la documentation officielle de PrestaShop à ce sujet il est possible de : 

  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.

Oxid eSales vs. PrestaShop
Bilan sur l’installation de modules et la modification du comportement

Un point sur cette partie pour Oxid grâce à son système de chainage d’héritage.

3. Conclusion

Voici les résultats bruts de ce qui vient de découler.

Oxid eSales (4.6 C.E.) PrestaShop (1.5.2)
Couche Controller 1 1
Couche Modèle 1 0
Couche Vue 1 1
Installation de modules et modification du comportement 1 0
Total 4 2

À mon sens le meilleur résultat technique d’Oxid vient du fait que c’est une solution qui est mature depuis plus longtemps que PrestaShop (profondément transformé depuis la sortie de la version 1.5).

Oxid est donné vainqueur sur ce duel mais il ne faut pas oublier que :

  1. Tous les aspects techniques n’ont pas été abordés (exemples : modélisation des données en base, gestion des webservices, …)
  2. Ce comparatif ne représente que les aspects techniques.

Un duel fonctionnel entre ces deux solutions est nécessaire et fera l’objet d’un prochain billet.

Affaire à suivre ! En attendant, vos questions sont les bienvenues.

5 commentaires pour “Duel de technos : Oxid eSales vs. PrestaShop

  1. Bonjour Matthieu,

    Sur le point numéro 4 “Installation de modules et modification du comportement”, je trouve que vous êtes sévère, le fichier .module peut-être allégé radicalement si dedans on ne fait instancier des fonctions de classe du framework ou bien du module. Le .module fait interaction avec le framework Prestashop et les hooks (on va dire que c’est un super contrôleur). Après si l’on développe dans le module des controllers, des classes, tout ce qui rentre dans le moule comme il faut cela fonctionne à merveille. Il faut signaler aussi qu’il y a une phase intégration dans le développement d’un module et bien sur ce n’est quasi jamais le développeur qui s’occupe de cela mais un intégrateur et pour la plupart du temps ce n’est pas une star du codage :). Je trouve que pour l’intégration ce système facilite grandement la tâche de l’intégrateur, car il n’aura qu’à toucher au template fournit dans le module avec une hiérarchie de répertoires comme il se doit !

    Le .module est essentiellement pour les scripts d’installation et de suppression du module, son initialisation dans l’appli et le plus important le rattachement du module aux différents hooks. Celui qui pond du code dedans qui n’a rien à voir avec tout ça, faut qu’il arrête le MVC ! Donc le 0 pour ce point n’est franchement pas mérité, ce n’est que mon point de vu.

    • Bonjour Johan,

      Je suis d’accord avec vous sur le fait que l’on puisse hiérarchiser ses modules en MVC sur PrestaShop et que c’est même conseillé (j’ai ajouté cela dans l’article), cependant sur un packaging de base d’une version 1.5.2 de PrestaShop avec tous les modules disponibles : il y en a très peu qui respectent cette convention => productcomments, et si l”on regarde les modules gsitemap ou shopimporter, on voit que ce n’est pas vraiment bien établi sur les modules existants.

      Par ailleurs le fait de noter 1 ou 0 sur Prestashop ou Oxid ici est de bien déterminer qui a l’avantage technique, et clairement rien que sur le chaînage d’héritage, Oxid prend l’avantage puisque pour le reste, sur ce point il est équivalent sinon mieux.

      • C’est vrai que les modules Prestashop 1.5 de base sont assez mal développés car la plupart sont des modules de la v1.4 convertis au plus simple sur du 1.5. Cela prouve que c’est un problème de développeurs et de gestion d’équipes derrière qui n’audit pas la normalisation du nouveau modèle prôné par Prestashop.
        Ensuite je tiens à ajouter que cela soit Prestashop, oxid, magento ou autres open source, un prestataire ayant signé avec un e-marchand fait que l’outil fonctionne bien ou pas. On peut comparer tel outil avec tel autre outil, perso cela ne change pas grand chose car un prestataire peu sortir une merde avec Magento et une bombe avec Presta, puis un mois plus tard c’est l’inverse ! On arrive à faire du bon avec du drupal commerce, pour vous dire il y a de très beau site ecommerce en drupal :) !!!
        Techniquement comparer si c’est mieux ou pas, peut-être mais pourquoi ? A la finale cela dénigrera une des deux solutions.

        • Oui, l’essentiel est d’utiliser une solution technique qu’on maitrise.
          A partir de là, tout devient possible.

          Après on ne peut pas nier que certain CMS sont mieux codés, plus souples, plus stables que d’autres, et c’est toujours intéressant de le savoir.

  2. Un p’tit troll gratuit :
    Prestashop, Magento, Zen Cart, Opencart, Drupal Commerce…
    Je rêve que la team de développement Typo3 sorte un jour un “Typo3 Commerce” pour mettre tout le monde d’accord… ^^

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *