hopes34 Posted January 31, 2011 Share Posted January 31, 2011 Bonjour,je m'étonne un peu des choix d'architecture de prestashop. Je peux me tromper bien sûr car je suis en train d'examiner la bête et qu'étant nouveau je peux ne pas avoir saisie certaines subtilités.Je souhaite que ce que je dis ne soit pris que comme des remarques, pas des critiques négatives.---- Ces précautions d'usage étant prises :je m'étonne que les fichiers php à la racine (qui peuvent être vus comme étant des controleurs) pour certains, appellent directement des fichiers vues (themes/xxx.tpl) et non des modules.Par exemple le products.php déclare et impose des fichiers js et css. Mais moi, comme il est conseillé de ne pas toucher à ces fichiers racine, je n'ai accès qu'au fichiers du themes (et/ou aux modules).Du coup je vais me coltiner du javascript dont je n'ai que faire.Pourquoi ne pas avoir eu une approche homogene et passer toujours par des modules. Du coup j'aurais pu modifier ma façon d'afficher les produits par exemple et me passe de la thickbox ou le jqZoomTout cela sont des ressources et ne devrait pas être traité au niveau controlleur. Link to comment Share on other sites More sharing options...
hopes34 Posted January 31, 2011 Author Share Posted January 31, 2011 Je précise aussi que dans ces fichiers racine, on fait des requêtes SQL. Ce qui n'est pas franchement apprécié dans une approche Modèle Vue Controler Link to comment Share on other sites More sharing options...
Vincent Decaux Posted January 31, 2011 Share Posted January 31, 2011 Disons que les fichiers PHP de la racine sont les contrôleurs, et un contrôleur qui appelle une vue ... après avoir reçu les données via les classes (modèle) est le principe même du MVC.Donc rien de choquant la dedans. Le concept va encore plus loin en utilisant un système de Template (Smarty), où d'autres auraient simplement eu des fichiers .php comme templates. Après, Prestashop repose sur un Core, mais la version 1.4 devrait plus répondre à tes attentes car la séparation est plus claire et largement plus modifiable. Je t'invite à essayer la RC1. Ensuite, par exemple, le jQzoom et le Thickbox sont éditables via ton BO. (activé ou non) Link to comment Share on other sites More sharing options...
hopes34 Posted January 31, 2011 Author Share Posted January 31, 2011 Merci Vincent.Tu pourrais me dire ou dans le BO ? Link to comment Share on other sites More sharing options...
Vincent Decaux Posted January 31, 2011 Share Posted January 31, 2011 Préférences -> Produits il me semble. Le jQzoom est supprimable, à voir pour le thickbox ... Link to comment Share on other sites More sharing options...
hopes34 Posted January 31, 2011 Author Share Posted January 31, 2011 Oui la thickBox on ne peut pas l'enlever, et oui effectivement on peut gérer le jQZoom via le BOMerciEt effectivement l'architecture de la RC1 me semble plus compatible avec une approche cleanOn a de vrais controlleurs. Et le code est beaucoup plus lisible.C'est sûr je parts de la RC1 même si ce n'est pas forcément stable ...Merci Link to comment Share on other sites More sharing options...
cobolian Posted February 2, 2011 Share Posted February 2, 2011 Si tu es un puriste, quand tu vas voir certaine portions de code, tu vas faire des bonds de 3 mètres. Je pense en particulier a la gestion des déclinaisons. Ca fonctionne bien, mais parfois c'est un poil capilotracté. Link to comment Share on other sites More sharing options...
hopes34 Posted February 2, 2011 Author Share Posted February 2, 2011 Oui, tu as raison.Plus j'entre dans le code plus cela m'effraie.Ce n'est pas une question de puriste, mais une question de lisibilité, de maintenance, de debugage .... Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now