m1bs Posted January 6, 2009 Share Posted January 6, 2009 Hello,Concernant smarty quels sont vraiment les réels avantages de cette méthode :- séparation des données ( traitement / affichage )- plus propreMais au final on doit toujours éditer 2 fichiers au lieu d'un seul, et l'on pourrait en fait tout faire dans le .php mais bon je pense que c'est le principe du MVC. Je me demande si c'est un phénomène de tendance ou si réellement ça apporte un plus.[Edit par Damien : ajout d'un sondage] Link to comment Share on other sites More sharing options...
Fredj Posted January 6, 2009 Share Posted January 6, 2009 Salut,+1 pour une séparation du fond de la formeSmarty dispose aussi d'un système de cache très performant, et d'un système de plug-in qui permet d'ajouter des modules externes créés par la communauté, ce qui signifie un gain de temps :]Fredj Link to comment Share on other sites More sharing options...
Cédric Girard Posted January 6, 2009 Share Posted January 6, 2009 +1 aussi pour Smarty# pour le cache intégré# pour la mise en forme simplifiée malgré tout, et surtout la lisibilité du code !J'ai découvert ce framework avec Prestashop, c'est une tuerie (bon, j'ai pas dit que je l'utiliserai dans des développements, mais c'est vraiment un concept intéressant !) Link to comment Share on other sites More sharing options...
Damien Metzger Posted January 6, 2009 Share Posted January 6, 2009 Smarty nous permet de faire des thèmes sans changer le coeur, et en étendant le concept, proposer le site sous d'autres formes (un thème pour smartphone par exemple).Smarty permet également aux graphistes et intégrateurs de pouvoir modifier l'interface plus confortablement et sans tout casser derrière.Enfin, c'est déjà éprouvant de mettre à jour son thème en changeant de version quand il est séparé du coeur, alors je vous laisse imaginer ce que ce serait si tout était mélangé.J'en profite pour lancer un débat (c'est un grand mot) : pour ou contre l'utilisation de smarty pour le back office ? Link to comment Share on other sites More sharing options...
Fredj Posted January 6, 2009 Share Posted January 6, 2009 Enfin, c'est déjà éprouvant de mettre à jour son thème en changeant de version quand il est séparé du coeur, alors je vous laisse imaginer ce que ce serait si tout était mélangé.] Ca serait du oscommerce :] J'en profite pour lancer un débat (c'est un grand mot) : pour ou contre l'utilisation de smarty pour le back office ? Puisqu'on demande mon avis je répondrais: s'il y a besoin de ça, et donc ça vous demanderais du temps de travail, alors c'est préférable que vous travailliez sur des choses plus intéressantes comme la correction des bugs et l'ajout d'autres fonctionnalités, ce que tout le monde attends :]Je dis ça car les trois seuls intérêts que je trouve à intégrer smarty dans le bo c'est comme tu as dit, la possibilité de créer des templates personnalisé pour le bo et comme je l'ai dit plus haut, pouvoir mettre en cache le bo ce qui est important pour un gros site qui demande un travail important coté bo. Et enfin ça serait plus cool pour celui qui développe sur le bo.Fredj Link to comment Share on other sites More sharing options...
Rémi Gaillard Posted January 6, 2009 Share Posted January 6, 2009 J'en profite pour lancer un débat (c'est un grand mot) : pour ou contre l'utilisation de smarty pour le back office ? Pour Link to comment Share on other sites More sharing options...
m1bs Posted January 6, 2009 Author Share Posted January 6, 2009 je vais peut être dire des choses pas censées mais si vous pouvez me renseigner,"+1 pour le cache intégré"Je comprends pas, pour moi si on me parle de cache c'est le cache du serveur qui a la capacité de distribuer la page + effectuer l'opération de traitement, pour moi smarty est un système qui permet à la limite d'accélérer le traitement un peu comme une superfonction."+1 un système de plug-in qui permet d’ajouter des modules externes"Ca je ne comprends pas non plus, des modules externe on parle des modules prestashop par exemple ? Si c'est le cas je veux dire on pourrait tout à fait le faire sans l'utilisateur final ne verrait pas la différence. ( mais je pense qu'il s'agit d'autres types de modules ) Link to comment Share on other sites More sharing options...
Damien Metzger Posted January 6, 2009 Share Posted January 6, 2009 Pour Chut, n'influence pas le débat toi @m1bs :Le cache de Smarty consiste en fait en une "compilation" des tpl, qui ne sont donc pas re-moulinés à chaque appel de page. Ce n'est en aucun cas plus rapide que si on le faisait directement en PHP, mais ça limite fortement le temps qu'on pourrait perdre (temps de calcul j'entends).Les modules externes ne sont pas du tout les modules prestashop, simplement une manière puissante de personnaliser Smarty.Smarty ne va pas accélérer la boutique, mais c'est sans conteste un des meilleurs frameworks pour faire du MVC. Link to comment Share on other sites More sharing options...
Fredj Posted January 6, 2009 Share Posted January 6, 2009 Smarty ne va pas accélérer la boutique A quoi sert le cache ? Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 7, 2009 Share Posted January 7, 2009 J'en profite pour lancer un débat (c'est un grand mot) : pour ou contre l'utilisation de smarty pour le back office ? Pour Depuis quand Smarty nous ferait perdre du temps ? Mettre en place Smarty est extrement rapide dans un projet web, surtout lorsqu'il est déjà présent en Front Office Une synthaxe plus claire n'est elle pas un avantage pour le Back office ? Trouvez-vous le code source du Back Office aussi lisible que le Front Office sur le V1 ? Il faut bien prendre en compte que le Back Office sera également modifié au fur et à mesure des différentes versions de la V2, donc un petit gain de temps à prévoir pour raison de "code lisible et clair".Les développeurs utilisant la solution en seront selon moi également ravis car vous savez bien qu'il est fréquent qu'un client demande des ajouts de fonctionnalités (qui peuvent impliquer des ajouts en BO) en même temps qu'un thème spécifique.Exemple intéressant : Un template de listing d'items (listing.tpl ?) : très présent en BO (tout le monde sera d'accord....) auquel on appliquera une variable $items qui sera bouclée pour l'affichage des items. N'est ce pas là un gain de temps par rapport a ce qui est proposé actuellement en V1 ?Souffre-t-on pour autant de problèmes de lenteur liés à Smarty sur le Front Office de PrestaShop ?Bonne journée, Link to comment Share on other sites More sharing options...
Damien Metzger Posted January 7, 2009 Share Posted January 7, 2009 A quoi sert le cache ?Smarty est en quelque sorte une surcouche de PHP permettant de faire des fichiers de templates. Lors du traitement d'une page, ces fichiers sont "traduis" en PHP pour être intégré au processus normal de traitement d'une page PHP.Pour éviter de perdre du temps à faire cette "traduction" à chaque appel, smarty la met en cache.C'est tout. Link to comment Share on other sites More sharing options...
Patric Posted January 7, 2009 Share Posted January 7, 2009 Personnellement j'ai voté pour "oui".Si comme le dit Lucas ça permettrait, moyennant une petite "perte" de temps pour la mise en place, d'en gagner plus tard dans le développement des versions futures, alors il n'y a pas à hésiter.Si par contre ce gain de temps sera négligeable, au regard du temps que demanderait sa mise en place, alors je préfèrerait que dans l'immédiat les efforts soient portés sur les ajouts de quelques fonctionnalités, souvent (apparemment) simples, qui font cruellement défaut à PS (comme par exemple un résumé de panier plus détaillé et flexible)...Mais à terme il est évident que ce serait un plus !Quoi qu'il en soit, j'aime aussi beaucoup les M&M;’s... Link to comment Share on other sites More sharing options...
Guest Posted January 7, 2009 Share Posted January 7, 2009 Quoi qu'il en soit l'utilisation de smarty facilite la maintenance du code pour un projet de cette en verdure.Et ne ralentirait en aucun cas le le site en question, le cache de smarty peut être couplé à d'autre cache tel que e-accelerator ( http://smarty.incutio.com/?page=CacheHandlerEaccelerator ).Smarty peut également être couplé à zend framework ( http://kpumuk.info/php/zend-framework-using-smarty-as-template-engine/ )...Je suis pour smarty sur le FRONT et dans le BO, et partout ailleurs... tant que possible... Link to comment Share on other sites More sharing options...
astragor Posted January 7, 2009 Share Posted January 7, 2009 Et bien moi j'ai voté que je préférait les M&M;'sOu plus sérieusement, je dirais comme certain l'ont déjà dit ! Si ca peut accellerer les dev. futurs, pourquoi pas !Mais si ca doit ralentir l'équipe dans la correction de bug ou dans le dévelloppement de fonctions très utilise à PS mais encore manquante. Alors la je dis non, laissez tombés.Franchement, je vois pas l'interert de customiser sont BO. Au contraire c'est bien mieu que tout le monde est le même.Déjà certains débutants ont du mal a trouver les fonctions dans la boutique alors imaginez la cata si tout le monde avait un BO different ! Link to comment Share on other sites More sharing options...
Cédric Girard Posted January 7, 2009 Share Posted January 7, 2009 Au niveau perfs, je tiens quand même à signaler que Prestashop est l'un des scripts de boutique en ligne les plus légers qu'il m'ait été donné d'essayer... Quand on compare (en terme de ressources serveur) à un mastodonte comme Magento, y'a pas photo !Certes, ce dernier fait certaines choses en plus (multi-shop...) mais bon, niveau vitesse en front-office, y'a vraiment pas photo ! Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 7, 2009 Share Posted January 7, 2009 Franchement, je vois pas l'interert de customiser sont BO. Au contraire c'est bien mieu que tout le monde est le même.Déjà certains débutants ont du mal a trouver les fonctions dans la boutique alors imaginez la cata si tout le monde avait un BO different ! Moi non plus je ne vois pas l'intérêt. Le but de mettre en place Smarty pour le BO, ce n'est pas du tout de le customiser, bienque ce soit desormais possible.Le but principal, je le rappelle, est de simplifier et de clarifier le code source en BO afin de le rendre plus maintenable pour un developpement plus serein, propre, rapide.Rien d'autre. Link to comment Share on other sites More sharing options...
Patric Posted January 7, 2009 Share Posted January 7, 2009 Le but principal, je le rappelle, est de simplifier et de clarifier le code source en BO afin de le rendre plus maintenable pour un developpement plus serein, propre, rapide. Dans ce cas pourquoi demander à la communauté son avis si ça n'a que des points positifs ? Link to comment Share on other sites More sharing options...
Cédric Girard Posted January 7, 2009 Share Posted January 7, 2009 Ceci dit, ajouter la possibilité de customiser le BO serait un plus (même si je ne me sens pas encore prêt à y mettre le nez :-) ) Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 7, 2009 Share Posted January 7, 2009 En effet. Et pour anecdote, le BO d'eZ Publish le permet, et certains gros clients de cette solution demandent parfois d'adapter (grossièrement) la charte graphique du BO d'eZ Publish à celle du FO. Link to comment Share on other sites More sharing options...
vins Posted January 7, 2009 Share Posted January 7, 2009 Pour ma part je suis à 100% pour.En effet j'ai du ajouter une classe au BO (accessible via un nouvel onglet) pour l'envoi directes de commandes à mes fournisseur. Mes fournisseurs disposent de leur interface (BO) restreinte à un seul onglet leur permettant de visualiser ces commandes.Donc pour moi, si le BO est mieux codé... et bien gain de temps et gain en maintenabilité.Je ne pense pas non plus que cela prenne énormément de temps à recoder.A plus. Link to comment Share on other sites More sharing options...
Damien Metzger Posted January 7, 2009 Share Posted January 7, 2009 Dans ce cas pourquoi demander à la communauté son avis si ça n'a que des points positifs ? Ben non on est pas tous d'accord Si c'est indispensable pour le front, j'estime que pour le back c'est une très mauvaise idée.2 fois plus de fichiers (php + tpl), 2 fois plus de code (traiter les données puis les afficher), 2 fois moins de perfs (on fait tout en double au lieu de le faire en simultané) et comme ce n'est que formulaires à tout va avec traitement et affichage complètement imbriqués, la nécessité de jongler entre des fichiers pour la moindre modification.Le code du BO n'est pas très attirant pour un nouveau venu, qui se dira alors qu'il faut tout refaire avec Smarty et que ce sera beaucoup mieux, mais d'expérience ça ne fera que retomber dans le même travers avec en plus les inconvénients cités plus haut.En gros je suis contre Link to comment Share on other sites More sharing options...
m1bs Posted January 7, 2009 Author Share Posted January 7, 2009 En ce qui me concerne, je comprends mal la logique de dire on utilise smarty uniquement pour le front et pas pour le BO.Dans l'ordre logique je dirais toute la partie graphique devrait être logiquement gérée avec smarty autant le FO que le BO.Mais je peux pas trop m'avancer vu que ce choix a été effectué certainement pour une bonne raison. Link to comment Share on other sites More sharing options...
Patric Posted January 7, 2009 Share Posted January 7, 2009 Ben non on est pas tous d'accord OK, dans ce cas il vaut mieux demander l'avis à des gens qui connaissent très bien Smarty, ses avantages et ses inconvénients... Parce que moi j'ai voté ne sachant pas tout ce que tu as dit... Et je dois dire que Lucas m'a un peu influencé... :red: Tu as commencé ta campagne trop tard... %-PBon je dévote et donne ma voie aux M&M;'s... Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 8, 2009 Share Posted January 8, 2009 2 fois plus de fichiers (php + tpl), 2 fois plus de code (traiter les données puis les afficher), 2 fois moins de perfs (on fait tout en double au lieu de le faire en simultané) et comme ce n'est que formulaires à tout va avec traitement et affichage complètement imbriqués, la nécessité de jongler entre des fichiers pour la moindre modification. 2 fois plus de fichiers certes, mais c'est plus lisible, le code HTML n'est plus dans des variables PHP ou des echo.2 fois plus de code, non. Sinon cela voudrait dire que la quantité de code des "$smarty->assign" et des "$smarty->display" equivaudrait à la quantité de code traitement du Back office. De plus du code est gagné dans les templates, jettez un oeil aux fichiers dans /tools/smarty/compile et comparez. C'est quand même plus léger avec la synthaxe Smarty.2 fois moins de perfs : on ne fait pas tout en double ! L'affichage n'a pas la même fonction que le traitement. Mais il est vrai que les boucles sont exécutées une fois pour l'instanciation et le traitement et une seconde fois pour l'affichage. Il faudrait faire des mesures pour connaitre le coût en terme de performance, mais puisque la vitesse du FO est très convenable, pourquoi celle du BO serait moins correcte ?Jongler entre des fichiers lisibles ne posent pas de problème en règle générale.Et une raison de plus d'opter pour Smarty dans le BO serait l'uniformisation du MVC dans la solution comme certains d'entre vous le cite.Nous souhaitons améliorer la qualité du développement sous PrestaShop pour simplifier encore plus notre travail. Voilà, pourquoi nous sollicitons l'avis de la communauté de développeurs PrestaShop.---....à part ça, Damien et moi, on s'entend très bien dans la vie, ne vous en faites pas, c'est simplement une discussion ouverte ! hehehe Link to comment Share on other sites More sharing options...
jolvil Posted January 8, 2009 Share Posted January 8, 2009 personnellement je trouve que l'affichage est un peu lent en back office notament pour le traitement des fiches produits, si vous allourdissez encore.....ce ne sera pas tres bon pour l'utilisateur. Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 8, 2009 Share Posted January 8, 2009 La fiche produit : un très bon exemple ! Celle-ci est tellement illisible qu'y apporter de petites modifications (notamment en terme de performances ) peut devenir un casse-tête pour les développeurs. C'est une page complexe dans PrestaShop offrant beaucoup de fonctionnalités. Alors la rendre plus lisible ne rendra ses optimisations que plus simples à mettre en place, difficile avec la fiche produit actuelle de l'alléger. Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 8, 2009 Share Posted January 8, 2009 En tout cas je peux vous garantir que le fetch de Smarty (fonctionnalité incriminée lorsque l'on parle de la (pseudo) lenteur de Smarty...) ne rallentira en rien la fiche produit :Le fetch peut devenir légèrement long lors de boucles très longues, or il n'y a pas de boucles longues dans la fiche produit (si l'on considère que le listing des accessoires doit être chargé en AJAX, ce qui est selon moi évident, car c'est dans ce cas que l'AJAX prend toute sa puissance!) Link to comment Share on other sites More sharing options...
vins Posted January 8, 2009 Share Posted January 8, 2009 Je pense que côté développeur externe de Presta c'est évident qu'un code à la Smarty est bcps plus clair. J'en ai fait l'expérience.Donc moi toujours pour.Avez-vous estimer le temps de recodage ? Link to comment Share on other sites More sharing options...
Lucas Cherifi Posted January 8, 2009 Share Posted January 8, 2009 Avez-vous estimer le temps de recodage ? Il est infime car cette fonctionnalité technique sera mise en place dans la V2. On reprend tout depuis le début, "from scratch". Nous allons tout recoder, donc pour ma part s'il faut estimer ce temps, je donnerai une valeur négative.... soit un gain 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