Jump to content

1.4... modèle MVC pas respecté ?

Peha

By Peha
in Discussion générale

 Share

Recommended Posts

Peha Newbie

Peha

Posted
Posted

Bonjour,

Un petit message pour la team ou les utilisateurs avancés.

Parmi les nouveautés de la 1.4, un truc m'a frappé
c'est dans les controllers, par exemple ProductController.php,
que des fichiers css et javascript sont ajoutés dans le thème.

       Tools::addCSS(_THEME_CSS_DIR_.'product.css');
       Tools::addCSS(_PS_CSS_DIR_.'jquery.fancybox-1.3.4.css', 'screen');
       Tools::addJS(array(
           _PS_JS_DIR_.'jquery/jquery.fancybox-1.3.4.js',
           _PS_JS_DIR_.'jquery/jquery.idTabs.modified.js',
           _PS_JS_DIR_.'jquery/jquery.scrollTo-1.4.2-min.js',
           _PS_JS_DIR_.'jquery/jquery.serialScroll-1.2.2-min.js',
           _THEME_JS_DIR_.'tools.js',
           _THEME_JS_DIR_.'product.js'));

       if (Configuration::get('PS_DISPLAY_JQZOOM') == 1)
       {
           Tools::addCSS(_PS_CSS_DIR_.'jqzoom.css', 'screen');
           Tools::addJS(_PS_JS_DIR_.'jquery/jquery.jqzoom.js');
       }



En tant que web-designer, ayant lexpérience de plusieurs autres CMS
je pense que c'est UNIQUEMENT dans le thème que devrait être décidé quel CSS, ou quel javascript doit être inclus dans le <head>

Le principe du modèle MVC ne me semble pas respecté (et ça c'est pas bon signe non ?)


ça ne s'annonce pas très web-desigenr friendly cette version... si on doit modifier les fichiers Controller pour faire un thème, ça va poser de pb de MAJ... et même, on ne devrait pas avoir à toucher aux controllers pour faire un thème (si par exemple on veut pas utiliser FancyBox).


Il y'a bien d'autres endroits dans Prestashop où c'est pas complètement clean pour un intégrateur (ex. le breadCruuuuumb !!! ) mais là ça me semble bp plus grave car ça semble être un choix réfléchi.

Bref qu'en pensez vous ?
Link to comment
Share on other sites
Vincent Decaux Newbie

Vincent Decaux

Posted
Posted

Et bien concrètement on a juste le Controleur qui envoie des variables (ici un tableau de String) à la Vue, qui va ensuite les traiter et les afficher dans le head de la page.
Le MVC est respecté, en effet ce n'est pas le top pour la modification de thèmes, mais ça serait pire de déclarer un tableau de String dans la vue ou de taper directement les fichier .js dans le head.

Mais je vois difficilement comment faire mieux ?

Ce qui me choque encore un peu, c'est qu'il y est trop de fichiers de Scripts, la plupart sert uniquement pour la page produit, un fichier compilé et unique ferait pas de mal.

Link to comment
Share on other sites
Peha Newbie

Peha

Posted
  • Author
Posted

séparer les scripts ne me choque pas du tout,
le code est plus lisible, on ne passe pas son temps à chercher dans un fichier de 1500 lignes.
De plus, il s'agit souvent de librairies qui sont susceptibles d'être mises à jours (modules jQuery, fancyBox...)

Par contre, ne pas laisser la main au designer d'interface (qui n'intervient qu'au niveau du thème) et imposer des scripts comme fancybox, qui peuvent ne pas convenir pour certains thèmes n'est pas logique.

Les scripts comme Fancybox n'ont rien à voir avec Prestashop, c'est un choix lié à l'expérience utilisateur de chaque boutique. Rien à voir avec une fonction qui doit être présente sur toutes les boutiques.
Donc ça devrait se trouver au niveau du thème.

Link to comment
Share on other sites
Asenar Newbie

Asenar

Posted
Posted

Débat intéressant ! Donc j'y répond pour en plus recevoir des notifications :)

Ici, je trouve qu'en effet, si on peut changer de thème facilement, aucune raison de charger les css et js dont on a pas besoin.. C'est à cause de ça qu'il faudrait peut être trouver un autre moyen. Mais je ne crois pas dire de bétise en disant que c'est là pour des raisons de compatibilité (le contrôleur dans la 1.3 ajoute également ces mêmes fichiers, du moins sur la version que j'ai sous les yeux, dans product.php . On pourrait penser peut être à des ajouts dans la configuration du thème pour ne pas charger ces fichiers, mais ça ne sera probablement pas dans release 1.4 (qui va sortir bientôt bientôt, si si !).

En chargeant ces fichiers "ailleurs" (grâce au thème par défaut donc), ça poserait de sérieux problèmes de rétrocompatibilité. On veut que le passage 1.3.x >>> 1.4 se fasse en un seul clic (ou à peu près)


Par contre, si l'on parle MVC, ça n'engage que moi mais c'est le contrôleur qui "contrôle" (justement !) la vue, en y insérant tout ce qu'il faut, en choisissant les données, le js, le css et le html qu'il faut.

J'assimile le javascript au contrôleur sans problème. Et d'ailleurs personnellement, je n'aime pas trop quand il y a du code javascript en plein milieu d'une page (que ce soit entre des balises <script>, ou bien après un "onclick=" par exemple). Surtout depuis les bibliothèque jquery et autre, on tend de plus en plus vers du javascript non intrusif, et ça s'est bien (toujours mon opinion ^^)

Quand au css, ça fait partie de la vue évidement, mais le contrôleur ajoute le fichier css qu'il faut au même titre qu'il utilise la vue qu'il faut. Coté performance mettre les <link> pour les css dans le <head> est plus intéressant car tout se télécharge en parallèle sur les navigateurs les plus connus (à confirmer, je ne retrouve pas mes sources).


Pour ce qui est de plusieurs fichiers js à la place d'un seul, la nouvelle fonction "ccc" (cache, combine & compile) de la 1.4 est je crois là pour ça :) (désactivée par défaut, car là aussi, problème de rétrocompatibilité possible).


tout ceci n'est que mon avis perso hein, j'attend les autres et vos réponses si j'ai oublié quelquechose ou si je me suis trompé ;)

Link to comment
Share on other sites
Vincent Decaux Newbie

Vincent Decaux

Posted
Posted

Ah intéressant, je n'ai pas pu tester cette fonction 'ccc', mais le résultat a l'air très sympa !
Il faut avouer de toute façon que les thèmes n'utilisant pas les scripts de base de Prestashop (fancybox etc ...) sont assez rares, et la surcharge des controleurs peut de toute façon éviter la modification du coeur si l'on doit modifier les fichiers JS, enfin si je ne m'abuse ?

Link to comment
Share on other sites
Peha Newbie

Peha

Posted
  • Author
Posted

_Je pense que le meilleur endroit pour intégrer les css et les js est bien le <head> du thème par défaut,
( un thème par défaut conçu comme un EXEMPLE de bonne pratiques pour Prestashop, ça serait cool )

_Moi non plus je n'aime pas les balises script en plein milieu dans le html
(y'en a dans beaucoup de modules, alors qu'on a un hook header qui devrait servir à ça)
Mais ce n'est pas vraiment la question.

_Pour la rétro comptabilité, on pourrait imaginer un module rétroComptabilité1.3>1.4 qui intégrerait les scripts manquants pour les thèmes non prévu pour la 1.4, ou une option à cocher lors de l'activation du thème. (ça a déjà été fait pour une version précédente)


je propose une idée de solution
dans header.tpl
<head>
{addJS ("nom_du_fichier.js" ; booléen ; "product.php", "index.php" ) }
{addCSS ("nom_du_fichier.css" ; 1 ; "product.php, "category.php" ) }
</head>

par exemple :

{addJS ("Fancybox.js") }
//ajoute le script contenu dans le dossier js du thème sur toutes les pages

{addJS ("Fancybox.js" ; 0 ;  "index.php" ) }
//ajoute le script contenu dans le dossier js du thème sur toutes les pages sauf index.php

{addJS ("Fancybox.js" ; 1 ;  "product.php, "category.php" ) }
//ajoute le script contenu dans le dossier js du thème seulement sur les pages category.php et index.php




On devrait avoir une méthode similaire accessible dans les modules pour inciter les créateur de modules à placer leurs scripts
dans le header sans effort

Enfin Il est illogique que les scripts Javascript utilisés dans un thème soient placés dans le dossier JS à la racine de Prestashop, ils devraient être dans le dossier JS du thème. (pour des raisons de versions, ça permet au créateur du thème d'utiliser ce qu'il veut)

@vincent-decaux "les thèmes n’utilisant pas les scripts de base de Prestashop sont assez rares "
Et pour cause on vient de voir que rien n'est fait pour faciliter la diversité (il ne faut pas oublier qu'un créateur de thème a rarement des connaissances avancées en php, (faire un thème ne devrait pas demander de connaissances en programation (php, MVC, surcharge des controllers c'est du chinois pour un intégrateur qui lui se limite généralement à HTML/CSS/JS (les langages coté clients) et SMARTY )

Link to comment
Share on other sites
Asenar Newbie

Asenar

Posted
Posted

Concernant le "hook header qui doit servir à ça", maintenant on s'en affranchit avec Tools::addJs/Css très avantageusement, puisque ces fonctions sont disponibles n'importe où (y compris pour les modules), et surtout ça permet de ne pas avoir à "épingler" un module dans le hook_header.

L'idée d'atjouer des plugins smarty pour ajouter addJs et addCss, j'aime bien (je colle cette idée dans un coin du bureau ;) )



Concernant le boulot d'intégrateur, il faut connaitre un minimum php hein ! smarty ajoute une couche entre l'html et le php, mais c'est essentiellement remplacer du {$mavar} par <?php echo $mavar ?> . Mais l'utilisation d'un moteur de template est d'ailleurs déjà un débat en soit (perso quand j'ai commencé avec ça j'étais pas convaincu, mais finalement j'aime bien), désolé d'avoir débordé

Link to comment
Share on other sites
Peha Newbie

Peha

Posted
  • Author
Posted
Concernant le “hook header qui doit servir à ça”, maintenant on s’en affranchit avec Tools::addJs/Css très avantageusement, puisque ces fonctions sont disponibles n’importe où (y compris pour les modules), et surtout ça permet de ne pas avoir à “épingler” un module dans le hook_header.

ça c'est vraiment cool. (mais il faudra bien l'expliquer aux dev de modules)


L’idée d’atjouer des plugins smarty pour ajouter addJs et addCss, j’aime bien (je colle cette idée dans un coin du bureau )


j'ai plein d'autres idées de ce type pour rendre la vie plus facile aux graphistes si ça vous intéresse ;)
(qui viennent pour beaucoup de bonnes idées trouvés dans d'autres cms.)


Concernant le boulot d’intégrateur, il faut connaitre un minimum php hein ! smarty ajoute une couche entre l’html et le php, mais c’est essentiellement remplacer du {$mavar} par <?php echo $mavar ?> .


les "connaissances" nécessaires en SMARTY (ou en php dans d'autres cms) se limite à savoir copier/coller ou supprimer les deux choses que tu a décrite : {$mavar} ou <?php echo $mavar ?>
c'est tout.
Et on peut faire des super designs juste avec ça.
Donc faut pas croire qu'un intégrateur est familier avec les surcharges de controllers et autre joyeusetés.
Link to comment
Share on other sites
Asenar Newbie

Asenar

Posted
Posted

Ah mais n'hésite pas pour les bonnes idées !

Je ne te cache pas qu'il y a des risques de les perdre dans les méandres du forum si on y fait pas attention ! Mais bon là il faut boucler la 1.4, on parlera d'autres améliorations / nouvelles fonctionnalités plus tard (genre dans le forum dev plutot que discussion générale ^^ d'ailleurs je me demande si on devrait pas y déplacer cette discussion ..). genre avec une roadmap et tout et tout !

Bon, si on me cherche, je suis en train de résoudre les bugs qui me sont assignés !

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
 Share
Go to topic listing
×
×
  • Create New...