Vraiment content de la nouvelle structure ?

[Luc Lérot Freelance]

Bonjour les gens,

 

Rien de méchant hein, Prestashop rocks ya aucun problème avec ca. Je me demande juste -du point de vue du code- si ca a pas été poussé un peu (trop) loin.

 

Personnellement, je trouve. Des corrections de petits bugs redondants de la 1.4, la mise en place des override d'adminTab, le templating du BO aurait peut être été suffisants...

 

J'aimerais juste avoir des retours d'autres codeurs sur le framework.

[Dev On Web]

Bonjour,

 

Y a pas photo, les possibilités ont réellement évoluées ! Le code est plus propre, plus organisé et le BO est maintenant codé en MVC.

 

Les overrides et la gestion des classes/contrôleurs/templates est vraiment top

 

Après c'est un avis perso...

[Raphaël Malié]

Bonsoir luclerotfreelance,

serait il possible d'avoir davantage de précisions sur votre remarque ? Si possible avec des exemples.

 

Pour la 1.5 nous avons voulu améliorer le framework afin de le rendre plus souple et plus simple à utiliser qu'il ne l'était. Il a aussi fallu l'adapter à certaines grosses modifications : multi boutique, refonte du back office, stocks avancés. Malheureusement comme le temps n'est pas infini, que l'architecture de prestashop 1.4 se prêtait très peu à des évolutions aisées et surtout à cause des problématiques de rétro compatibilité, ces développements n'ont pas forcément pu être poussés complètement au maximum, et dans la plupart des cas il s'agit surtout de mise en place d'outil pour les futures versions, outils qui seront améliorés au fil du temps.

 

Cordialement

[Luc Lérot Freelance]

Hey, no probs Raphaël :-)

 

A titre d'exemple donc, lors de la création d'un module

 

- La structure views/templates/* est trop profonde, un simple 'templates' aurait suffit à mon avis. C'est très lourd et trop "catégorisé" (=trop de répertoires)

- Les conventions de nommage sur les controllers sont mal pensées (le nom de la classe n'a plus aucun intérêt avec un nom si long) et la moindre erreur (voire sur des plateformes web un poil trop restrictive à cause de strtolower () utilisé dans le nom du controller ) est rédhibitoire

 

A titre d'exemple aussi, dans la gestion du BO :

- la notion de helper est bien en soit, mais il ne s'agit peut être pas d'un bon nom et surtout, la structure des répertoires est juste impossible (trop profonde)

- Les modeles, exemple Order.php & Cie, reclassés dans des sous-répertoires, pareil, trop lourd

 

 

La doc mes amis, la doc...où est-elle ? Quelles guidelines pour créer un module ? Quelles guidelines pour utliser le Context ?

 

 

Pour résumer, il y a donc 2 points essentiels qui -personnellement- me "gênent" puisqu'ils complexifie l'approche "conception" des développements :

1. cette "répertoirisation" à outrance (qui conduit à quelques incohérences : un répertoire 'templates' dans un répertoire 'views' pour les modules, un répertoire 'view' dans un répertoire 'template' pour le BO)

2. cette impression de restriction accrue qui casse la liberté que j'avais en 1.4 de pouvoir organiser mes modules comme je le souhaitais (quand même beaucoup plus souple niveau maintenance)

 

 

 

J'ai l'impression d'avoir un pseudo-Symfony loadé avec des fonctionnalités e-commerce par défaut, mais :

- Si je veux un framework capable de me générer du blog, du forum, ...etc (ie. autre chose qu'une "simple" boutique en ligne) pourquoi choisir Prestashop ?

- Pourquoi ne pas avoir utiliser Symfony (ou autre hein, c'est un exemple) directement comme sous-couche MVC plutot que d'en avoir re-créé une bien moins performante (sans méchanceté hein, attention ;-) )?

 

 

Sans compte que les migrations 1.4 à 1.5 ne vont pas forcément être les bienvenues en terme de coût pour les clients puisqu'il n'y a pas si longtemps ils ont migré de 1.3 à 1.4 (avec parfois une reprise intégrale de leur themes).

 

Ce qui me pousse à penser que beaucoup resteront en 1.4 et nous obligera à faire de la gymnastique entre 2 versions complètement différentes de la même techno, pas très confortable.

 

J'espère ne pas me faire trop d'ennemis ;-)

[Dev On Web]

Il y a du vrai...

[Joël Gaujard]

Bonjour,

 

Je suis surtout d'accord pour la rétro-compatibilite. Je ne vois pas comment faire un module qui peut être compatible avec les versions 1.2 à 1.5 de PrestaShop (ce qui restait a peu près possible jusqu'à maintenant).

 

Pour la complexité ou le trop de profondeur des répertoires, je ne suis pas du tout d'accord. Justement Luc tu cites Symfony qui est bien pire que PrestaShop au niveau de la profondeur. Par expérience, j'ai pu m'apercevoir que plus tu ranges tes fichiers dans des dossiers plus tu reste modulaire. Par exemple le répertoire "views" qui obtient "templates" pour ensuite avoir "front", "hook" et/ou "back". On pourrait avoir dans le futur une vue "json" ou encore "xml" et la ces répertoires trouvent leur place logique au coté de "templates". Bien sur cela reste mon avis.

 

Archi d'accord avec le nom des classes de contrôleurs ! Leurs noms est beaucoup trop long.

 

C'est vrai que la syntaxe ressemble de plus en plus a celle de Symfony et je dirais tant mieux ! Cela me semble plus "robuste". Je me rappelais qu'a l"époque ou je bossais pour PrestaShop qu'on parlait d'utiliser un framework comme fait Magento. Mais quand tu vois le résultat de magento en terme de performance, je prefere vraiment que le framework de PS soit fait maison et surtout optimiser pour du e-commerce. Tout en sachant que l'intérêt de se baser sur un framework permet d'ajouter des fonctionnalités en beaucoup moins de temps et beaucoup moins buggé.

 

Pour les migrations, ça va être énorme. Deja entre la 1.3 et la 1.4, c'était galère mais alors la oublie. Autant refaire les modules.

 

Mes salutations en esperant ne pas m'avoir fait un ennemi ou voire plusieurs (je possède un don naturel pour ça).

Edited June 19, 2012 by Joël Gaujard (see edit history)

[Dev On Web]

C'est vrai que niveau rétro-compatibilité, je me limite à la 1.4 pour un module généralement.

Concernant la migration, ça risque effectivement d'être plutôt tendu, les thèmes et les modules en plus de la BDD, ça va faire mal (au temps et au budget)...

[Luc Lérot Freelance]

C'est vrai que niveau rétro-compatibilité, je me limite à la 1.4 pour un module généralement.

Concernant la migration, ça risque effectivement d'être plutôt tendu, les thèmes et les modules en plus de la BDD, ça va faire mal (au temps et au budget)...

 

Ah ah :-D on va encore se faire accuser de vouloir rouler en Porshe...

[Dev On Web]

Ah ah :-D on va encore se faire accuser de vouloir rouler en Porshe...

 

Carrément ! Un premier devis y a deux jours pour une migration d'une vieille version de PS (< 1.3) et un budget très (très) serré.

Résultat : des semaines de boulots pour refaire le thème + les modules + la migration manuelle BDD.

 

C'est tout simplement pas possible, obligé de refusé si tu bosses en solo... :/ Tellement d'adaptations à faire !

[Luc Lérot Freelance]

Joël,

 

Symfony est pire en terme de 'répertorialisation', aucun doute. Si Prestashop part sur du Symfony, je n'ai rien contre, au contraire...mais l'impression là, c'est qu'on est à mi-chemin : on a la rigidité d'un framework "à la Symfony" sans sa "puissance". C'est dommage.

 

Et puis pour le don naturel, pareil. Mais c'est pas grave, on se fera des presta-péro tous les 2 pour parler stratégie migration ;-)

[Raphaël Malié]

Merci pour ces retours

Pour les répertoires c'est vrai que c'est complexe. En fait l'idée du répertoire templates/views/ des modules c'est qu'à terme on souhaite que les images, js et css des modules soient dans le répertoire templates/, donc par exemple templates/css/. Actuellement seuls les tpl sont gérés via le dossier views.

Les répertoires admin sont profonds oui, mais comment faire plus cours ? Si vous avez des suggestions n'hésitez pas

Edited June 21, 2012 by Raphaël Malié (see edit history)

[daidais]

La structure en sous dossier n'est pas forcément dérangeante, le gros soucis c'est que les noms des classes ne représente pas cette arborescence est là c'est vraiment gênant puisque cela complexifie énormément les possibilités de surcharge il est quand même dommage qu'aujourd'hui encore tu ne puisses pas surcharger les classes d'un module.

Quand tu regardes le nom des classes on a donc pour un module une classe Blocknewslettter par exemple si on l'appelle Module_Blocknewsletter ou ModuleBlocknewsletter on peut simplement la surchargé par un classe Override_Module_Blocknewsletter ou OverrideModuleBlocknewsletter qui serait placé dans override/module/blocknewsletter/blocknewsletter.php si tu appliques ce principe à toutes les classes du cœur en front et en admin on est pas mal déjà.

Même si la structure en underscore n'est pas dans la convention je la trouve plus parlante un « _ » est un sous dossier on sait ou on va.

Au final il serait plus qu'avantageux pour le cms qu'il suive au minimum la norme PSR-0

Vous en pensez quoi ?

[Raphaël Malié]

Salut,

 

Tout ce que tu dis fait désormais parti des bonnes pratiques de développement depuis quelques années. Malheureusement il sera très difficile pour PrestaShop de suivre ces standards sur leur version 1 puisqu'ils doivent rester rétrocompatible avec les modules existant.

 

Si une version 2 arrive un jour, j'espère qu'ils comprendront l'importance d'avoir une bonne architecture logiciel et de suivre ces standards.

[daidais]

Je suis d'accord avec toi, et effectivement je n'invente rien mais ça mérite d'être souligné.

Je comprend bien les difficultés que cela pose et me doute ne pas en voir la couleur avant une 2.0 mais le projet ne peut pas patir des erreurs du passé toute sa vie. C'est un travail énorme j'en suis conscient mais rien n'empêche de maintenir cette version seulement pour les bugs et failles de sécurité et de plus sur une période défini (1 ou 2 ans) et de travailler dés maintenant à la "mise au norme" et à la refonte de la solution en aidant les développeurs de modules/thèmes à se préparer au mieux à la mise à niveau.