Il y a quelques mois de ça, je découvre Smarty, un moteur de template pour PHP. À première vue, ce concept de template fait très envie en mettant fin au morceaux de html dans tous les sens au milieu du code PHP. On découpe mieux, c'est plus beau, plus propre, plus professionnel, etc.
Mais finalement… ne pourrait-on pas faire la même chose sans s'encombrer d'un outil pareil ? Comme on me l'a justement fait remarquer il y a quelques temps : « bué ça sert à rien, PHP c'est déjà un moteur de templates ». C'est vrai ça, pourquoi ne pas simplement faire un dossier tpl dans lequel on irait y mettre des fichiers tels que head.php, foot.php, form_inscr.php, etc. puis les intégrer à coup de include() dans le core ?
Outre le fait que des moteurs de templates semblent facultatifs avec ce genre de manipulation, on se rend compte que les développeurs de moteur de templates fournissent un système de conditions et de boucles en tout genre. On retrouve donc des if/while dans les templates, avec une énième syntaxe… c'est le monde à l'envers non ? Autant directement faire du bouclage dans la template en .php comme vu juste au dessus, qui sera certainement bien plus efficace.
Pour finir, il ne faut pas oublier qu'intégrer un outil comme Smarty demande une maintenance supplémentaire pour le développeur, et peut potentiellement rajouter des problèmes de sécurité. Et si un jour le moteur n'est plus maintenu pour une raison X ou Y et que le PHP ne supporte plus des fonctions deprecated effectuées par le moteur de template, on fait quoi ? On refait tout le site ? On maintient le moteur nous même en plus du site ?
Vu le niveau de complexité de petits outils comme Smarty je dois oublier quelque chose d'important dans l'histoire, mais je ne vois pas quoi. Et s'il y a quelques petits avantages pratiques (ce dont je suis presque certain), est-ce qu'ils valent vraiment le coup par rapport à ce que l'on y perd ?
Attention, je ne traite ici des moteurs de template que dans le cas du PHP.
Tiens, pourquoi je ne poste des journaux que le vendredi ?…
Journal De l'utilité des moteurs de templates en PHP
2
jan.
2009
# smarty ou pas
Posté par NeoX . Évalué à 4.
ils redefinissent donc des balises pour simplifier la creation de page
ex: box(title,height,width,xposition,yposition, content)
tu sais que ca te fera une box avec ton contenu (content), placé en xpos,ypos, avec le titre (title)...
c'est plus parlant pour le novice mais ca lui masque la realité des choses (pilule rouge ou pilule bleue ?)
maintenant je peux me tromper, mais tu peux faire un page html pure, avec juste une ou deux balises php dedans pour les parties variables.
meme si perso je fait l'inverse une page php avec du html dedans
surement une question de gout.
[^] # Re: smarty ou pas
Posté par Spyhawk . Évalué à 3.
Pour avoir utilisé Smarty dans quelques projets, j'y vois 2 avantages :
- la meilleure séparation du code php/html. Comme tu l'as précisé, c'est plus "propre", plus "beau", plus "pro", mais ça a surtout l'avantage de permettre à 2 personnes distinctes de travailler sur le même projet sans trop se marcher sur les pieds (designer/codeur).
- la rapidité, par la "compilation" des templates ainsi que la gestion des caches, très utile dans certains cas.
[^] # Re: smarty ou pas
Posté par Uriel Corfa . Évalué à 6.
[^] # Re: smarty ou pas
Posté par tfeserver tfe (site web personnel) . Évalué à 2.
Par contre, pour avoir développer sans templates, et à coup de "include", comme tu le préconises, je trouve cela très pratique.
En gros on a un code PHP avec nos commandes php, et un autre avec uniquement le code html, utilisant les variables php initialisées auparavant (voir quelques foreach évidemment, pour les elements de type array).
L'utilisation de moteur de templates est peut etre plus utile sur de vraiment gros gros projets?
# C'est vendredi :)
Posté par tcheuck . Évalué à 4.
Je préfère jTpl : http://jelix.org/articles/fr/telechargement/jtpl
# Un moteur de templates est très utile
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 5.
Au passage, ce n'est pas une usine à gaz du tout, juste 2 fichiers, le "chargeur" et le "compilateur".
Donc je conseille vivement un moteur de templates, regarde les gabarits de InDefero[4], le résultat est vraiment propre.
[1]: http://www.pluf.org
[2]: http://www.jelix.org
[3]: http://pluf.org/doc/template.html
[4]: http://projects.ceondo.com/p/indefero/source/tree/master/src(...)
[^] # Re: Un moteur de templates est très utile
Posté par Uriel Corfa . Évalué à 3.
De plus, si jTpl vous plait, peut-être irez-vous essayer Jelix dans son ensemble. Et là, quel bonheur... Ca m'a presque réconcilié avec le PHP :)
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
http://jelix.org/articles/fr/manuel-1.1/templates
Teasing: la version 1.0 de jTpl standalone sort très bientôt
[^] # Re: Un moteur de templates est très utile
Posté par Tof . Évalué à 1.
>>> "* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}"
<?=$variable?> marche bien en php, avec l'option "short_open_tag = On".
Et du coup ça permet des transformations rapides, genre <?=ucword($nom)?> .
>>> * "sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)"
Entre <?= $variable . $objet->propriete ?>
et {$variable.$objet->propriete}, le gain de lisibilité est limité non ?
>>> "il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.</cite>"
Souvent je fais:
<h1><?=count($personnes)?> listée(s) :</h1>
<? foreach($personnes as $p): ?>
<p>Nom : <?=$p->nom?>, Age : <?=$p->age?> ans</p>
<? endforeach; ?>
Avec une coloration syntaxique c'est clair comme de l'eau de roche.
>>> "* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées"."
C'est le seul avantage que je vois à un moteur de template autre que PHP. Dans ce cas ça ne concerne que le cas où des non-développeurs ont accès à des modèles sur une appli critique.
My 2 cents :)
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
[^] # Re: Un moteur de templates est très utile
Posté par Tof . Évalué à 1.
Que nenni, il est même fixé par défaut à ce jour.
+1 pour les goules et les couleuvres. Je préfère du PHP :-)
[^] # Re: Un moteur de templates est très utile
Posté par Bastes . Évalué à 2.
[^] # Re: Un moteur de templates est très utile
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Dans mon utilisation pro, la moitié des clients ne l'ont pas, donc on est obligé de développer sans.
Pour les librairies en plus c'est une bonne idée d'éviter de l'utiliser, ça évite pas mal de mauvaises surprises...
# MVC
Posté par gUI (Mastodon) . Évalué à 4.
- Modèle pour manipuler les données "métier"
- Vue : pour les seuls soucis d'affichage (et là, je pense que les templates sont destinés à ça)
- Contrôleur : architecture globale, organisation du site, bref les interactions
Mais peut-être me trompé-je ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: MVC
Posté par keyes . Évalué à 3.
Apprendre ces frameworks nécessite un peu d'investissement en temps mais permet ensuite de gagner un temps précieux et d'obtenir des applications d'une qualité bien supérieure.
Symfony utilise PHP lui même comme langage pour le moteur de templates (avec l'équivalent des systèmes de blocs et autres helpers de Smarty), il est aussi possible d'utiliser un autre moteur de templates que celui livré par défaut, Smarty pat exemple.
# Evidemment que c'est interessant !
Posté par Temsa (site web personnel) . Évalué à 8.
Utiliser un système MVC augmente fortement la capacité de l'application à évoluer : il devient aisé, à partir d'un même contrôleur, de disposer de plusieurs vues représentant la même chose: par exemple on code d'abord une vue html, puis une vue xml, puis une vue json, puis une vue rss, etc. Le code des vues demeure très simple et c'est d'ailleurs _essentiel_.
Je dirais donc que l'un des principal intérêts du moteur de template est de forcer les développeurs à ne pas faire le code de l'application dans la vue.
Ca évite les mélanges, et c'est le début du développement en couche : on commence par le système de template, on continue en séparant le code métier du contrôleur, puis en utilisant une couche DAO en utilisant un ORM permettant d'abstraire la base de donnée (ou tout autre source de donnée, comme un web service).
Ainsi, le code d'une vue doit toujours être limité au maximum et doit concerner pratiquement uniquement la présentation de l'information issue du modèle. Sinon, c'est que l'on ne code pas "volatile" et "évolutif"... ce qui 'impliquera à terme la réécriture ou l'abandon de l'application, puisque toute application évolue, à part peut-être hello world!
Par conséquent, l'une des principales fonctionnalités du moteur de template et de tenter de restreindre les actions que peut réaliser le développeur dans la vue.
En outre, lorsque l'on utilise un moteur de template dont le langage est bien étudié comme TAL (en php l'implémentation de référence est PHPTAL je crois), créé pour les besoins de Zope et disponible dans la plupart des langages, un moteur de template peut aider fortement à la séparation graphiste/développeur.
En effet, le TAL s'intègre directement sous forme d'espace de nommage xml dans le html/xhtml, ce qui permet tout bêtement d'afficher un template non interprété directement dans le navigateur, ce qui sera généralement la "maquette statique" du site, et ceci va donc favoriser les échanges entre le développeur et les graphistes : les changement de l'un et de l'autre peuvent tourner dans le même fichier sans rentrer en conflit, il n'y a plus besoin d'intégrer une nouvelle maquette, il suffit de prendre le fichier modifié par le graphiste. Idéal pour un travail en équipe.
Pour un certain nombre de langage de template, il est possible d'utiliser des fonctions standards, simple à appliquer et très lisibles, pour mettre en forme le texte ou appliquer des filtres : par exemple, passer tout en majuscule, limiter la taille d'un champ et rajouter "..." à la fin, et j'en passe.
De plus, et ce n'est pas forcément négligeable, un système de template apporte encore 2 atouts:
- Il peut gérer un cache d'interprétation (de mémoire Smarty le fait), ce qui diminue la charge sur la machine et permet d'accueillir plus de visiteurs. On augmente donc à peu de frais la scalabilité de l'application.
- Finalement, c'est peut être un des points les plus importants, le plus simple de tous : un langage de template permet du code dans la vue, et non la vue dans du code (et oui, dans ce sens, php est déjà un système de template), ceci améliore la lisibilité, la compréhensibilité de la vue et par conséquence l'aisance de modification du code, donc son évolutive, sa maintenance et son exploitation.
Bref un système de template est un premier pas important pour faire en sorte qu'une application n'ai pas besoin d'être réécrite tous les 2 ans from scratch, et peut rendre bien des services ;)
[^] # Re: Evidemment que c'est interessant !
Posté par Fabimaru (site web personnel) . Évalué à 3.
Alors je me pose la question: comment ça se passe dans la vraie vie quand le développeur est une personne bien distincte du designer? Ce dernier est obligé de travailler sur une version plus ou moins fonctionnelle du site? Il modifie directement des pages PHP (qui ne contiennent pas directement la logique métier mais juste des trucs comme par exemple les boucles pour afficher les enregistrements d'une requête SQL)?
Ou alors c'est le développeur qui applique les traitements aux pages crées par le designer?
[^] # Re: Evidemment que c'est interessant !
Posté par Temsa (site web personnel) . Évalué à 3.
- les designeurs font une maquette statique du site
- les développeurs modularisent et dynamisent le site, et font leur modif css perso dans un fichier css à part.
Changement du design ?
- les développeurs refabriquent une maquette statique intégrant leur css de développeurs (toujours dans un ou des fichiers à part) à coup de visite sur le site fichier > enregistrer sous.
- les designeurs modifient la maquette statique qu'on leur à fourni
- les developpeurs reintegrent la maquette statique modifiée par les designeurs : entre 2 et 4 jours de boulot, sans compter les "oubli" et les bug provoqués
Avec TAL on échappe énormément de cette complexité puisqu'on reste sur quelque chose de très proche de la maquette statique modifiable aussi bien par les dev que par les designeurs à tout moment.
Le seul véritable problème reste qu'en modularisant le site (mise en commun des header, footer, etc.) la page ne peut pas inclure les differents template sans qu'il soient partiellement intrepreté.
Je ne l'ai pas encore appliqué, mais la solution est assez simple, il suffit de rajouter un javascript (desactivé par TAL lors d'un vrai run) qui va s'occuper de parser rapidement le template et inclure les sous templates nécéssaires, comme ça le designeur peut le faire tourner en local sans même avoir un apache qui tourne (enfin sauf sur IE car le mode "file:///" est buggé pour l'Ajax, certains évènements ne sont pas levés du coup ça peut créer des problèmes).
Dans le cas d'un site utilisant pas mal le JS ceci oblige à utiliser un bon chargeur de fichier/gestionnaire de bootstrap en JS pour éviter les problèmes (genre les scripts se lancent lors de l'event window onload alors que tous les templates ont pas été tous ajoutés au DOM => ça ne marcherai pas).
Néanmoins, malgré ces petits problèmes à régler ça reste très faisable et on obtient alors le site parfait de collaboration dev/designeurs.
Pire, en utilisant un mercurial et en expliquant rapidement comment l'utiliser (avec TortoiseHg par exemple) au designeurs, qui n'ont souvent pas d'accès direct (studio externe, ou interne) au SVN/CVS/etc. on peut même travailler avec eux efficacement (en utilisant les patchs queue... pour lui c'est un click, pour nous des heures de gagnées), au lieu de travailler avec des échanges de zip par mail comme c'est souvent le cas...
[^] # Re: Evidemment que c'est interessant !
Posté par jeffcom . Évalué à 4.
- le dev crée des vues "de base" en html (des templates "type") et quelques tags permettant de placer de contenu dynamique
- le dev dresse une liste des tags pour que le designer sache à quoi ça correspond
ou
- le dev crée des vues "de base" en html (des templates "type") rempli avec des données arbitraires (genre Lorem_ipsum)
puis
- le designer renvoie les templates avec les styles et les images
- le dev replace/vérifie les tags pour le moteur de templates
Complètement d'accord pour TAL. au passage, on trouve certains designers qui connaissent TAL et peuvent l'intégrer directement... un gain de temps incroyable... mais c'est rare tout de même...
# Journal très pertinent
Posté par rewind (Mastodon) . Évalué à 7.
Toutes les explications que j'ai vues en commentaires ne m'ont pas convaincu, au contraire. Il est tout à fait possible de créer des helpers en PHP qui ont la même fonction que des équivalents template genre "box(title,height,width,xposition,yposition, content)". La réalité n'est pas plus ou moins masquée dans un cas PHP. D'autre part, la séparation en MVC n'est pas facilitée ou empêchée si on utilise du PHP (voir symfony par exemple qui utilise des templates avec du PHP). Ceci n'est pas un problème de langage mais de pratique. Il est tout à fait possible de faire des choses propres en PHP/HTML dans des templates qui ne contiennent que de la vue. Quant à la gestion d'un cache, elle est tout à fait possible même avec des templates PHP (voir symfony encore).
Pour moi, le meilleur langage de template est le langage qu'on utilise pour le reste (PHP ou Ruby par exemple suivant les cas) avec de bonnes pratiques du genre n'utiliser qu'un sous-ensemble bien déterminé du langage dans les templates.
[^] # Re: Journal très pertinent
Posté par Erwan . Évalué à 3.
Si tu es tout seul sur ton projet, pas de problème : tu peux être discipliné et séparer proprement les choses. Mais si tu as des collègues qui ont des niveaux de compétences variables, alors tu n'es jamais à l'abri d'un illuminé qui va trouver intelligent de mettre une grosse fonction dans ce qui est censé être un template en PHP. Donc, en plus de rendre le problème du cache bien plus simple, un langage de template va t'assurer de la séparation en empêchant ce genre de bétise.
Les langage de template sont tellement simples qu'il n'y a pas de problème d'apprentissage, faut pas pousser non plus...
[^] # Re: Journal très pertinent
Posté par dinomasque . Évalué à 5.
BeOS le faisait il y a 20 ans !
[^] # Re: Journal très pertinent
Posté par Temsa (site web personnel) . Évalué à 7.
C'est pour celà qu'il est important que le langage de template ne t'autorise pas à faire n'importe quoi (contrairement à PHP), car s'ils le peuvent, les gens font toujours n'importe quoi, du coup ca devient rapidement inmaintenable ... Je le sais très bien parce que je le vois tous les jours :-s
[^] # Re: Journal très pertinent
Posté par cgo2 (site web personnel) . Évalué à 3.
Pour répondre au journal concretement : les moteurs de templates sont une mauvaise réponse à la question "comment séparer la forme (la Vue du modèle MVC) du fond (le code métier, le Modèle et le Controlleur) ?". En effet, c'est indispensable de les séparer _logiquement_ pour toutes les raisons que l'on connait (fiabilité, maintenance, bla bla). Mais cette séparation _logique_ peut parfaitement se faire en PHP. PHP a déjà toutes les fonctions qu'il faut (conditions, boucle, output buffering pour le cache, include, visilibité des variables, etc.) et surtout une syntaxe adaptée (short tag, "echo" qui peut s'écrire avec "=", syntaxe alternative pour les instructions du genre : if/endif, while/endwhile, etc.). Bref à quoi ça sert d'ajouter une surcouche, qui, comme il est très justement signalé, ne fait que réinventer ce que PHP sait déjà faire nativement ? Réponse : à rien.
Un très bon article sur le sujet : http://www.massassi.com/php/articles/template_engines/
Un framework à tester absolument pour son système de template en PHP parfaitement intégré au modèle MVC : Symfony
Personnel j'utilise un système de template assez proche du modèle de Symfony (affecter une variable de classe dans mon controlleur la rend automatiquement visible depuis le template, qui est un fichier php contenant du html et des instructions php quand il faut) et mes applications ne s'en portent que mieux :-)
Allez, encore quelques années et les gens vont aussi finir par comprendre l'inutilité des ORMs en PHP !
[^] # Re: Journal très pertinent
Posté par David Carlier . Évalué à 2.
[^] # Re: Journal très pertinent
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Journal très pertinent
Posté par David Carlier . Évalué à 1.
Par contre pouvoir "traduire" des centaines de tables en leurs classes équivalentes ET les relations entre elles, ça permet de s'abstraire de cette problématique. Clairement sur de gros projets en Java par ex je bosse pas sans Hibernate ou autre sinon autant sauter partout dans mon salon tel un kangourou je serai moins fou !
[^] # Re: Journal très pertinent
Posté par thedude . Évalué à 4.
Ca apporte certes son lot de problemes aussi, mais bon, on est quand meme decharge de tout ce vilain SQL a ecrire et surtout a maintenir...
Entre annoter une classe et faire un getSession().save(object) et un verifier si l'objet a deja ete sauve, si oui, UPDATE table bla=truc where machin = id sinon INSERT INTO toto blablabla avec des objets metiers ayant 25 attributs, dont un bon nombre sont des objets haut niveau (ie ayant autant d'attributs repartis sur qq tables), ben heu, voila quoi.
Idem sur les select, les updates de liste d'objets intelligents etc.
Rajoute a ca le cache, la gestion des transactions, que sais je encore, je ne fait que gratter la surface d'hibernate, donc j'en connais pas tant que ca et ca devient enfin agreable de bosser avec une DB...
[^] # Re: Journal très pertinent
Posté par suJeSelS . Évalué à 4.
[^] # Re: Journal très pertinent
Posté par Antoine . Évalué à 5.
En tout cas ce serait plus amusant que de programmer en Java.
[^] # Re: Journal très pertinent
Posté par Octabrain . Évalué à 2.
[^] # Re: Journal très pertinent
Posté par thedude . Évalué à 4.
L'essentiel de son point (en tout cas ce qu'il en ecrit, son experience est peut etre plus vaste, mais c'est pas ce qui ressort de son papier), c'est qu'il a ecrit son propre ORM en C++ au debut des annees 90, que le truc etait d'une lenteur sans nom et que c'etait impossible a maintenir.
Pour la performance, on est presque 20 ans apres, les ressources a notre disposition ont ete multipliee par 10 000, et honnetement, je suis meme pas convaincu que les perfs d'un hibernate pour ne citer que le plus connu soient en dessous de requete SQL pure. J'ai aucune source sous la main, si ce n'est mon project manager m'affirmant avoir lu qq papiers a ce sujet.
Honnetement, avec le cache active, ca m'etonne pas plus que ca.
Pour la maintenabilite, c'est clair qu'ecrire son ORM, c'est pas une bonne idee a moins d'avoir beacuoup de temps et une armee de developpeur pour pouvoir en affecter une dizaine uniquement sur l'orm.
Mais bon, la encore, on est 20 ans apres, les ORM open source (ou pas) fourmillent, je veux bien croire qu'une partie d'entre eux soient un peu pourris, mais ya quand meme qq projets stables, qui marchent bien.
Toujours pour citer hibernate, si j'ai couille avec, je vais plutot partir du principe que mon code a moi est pourri plutot que d'estimer que le bug se situe dans hibernate.
Bref.
Pas tres pertinent quoi.
[^] # Re: Journal très pertinent
Posté par Temsa (site web personnel) . Évalué à 8.
Après un autre, qui n'arrivera pas a comprendre le code du premier et comme sa fonction marche, il décidera de la copier coller ailleurs. En 3 mois ton code est devenu inmaintenable.
4 mois après on décide de changer de SGBD, et vue que la norme SQL est une blague, faut réécrire toutes les chaînes SQL. En plus comme tu viens de décider qu'il te fallait un pool de connexion et non pas une seule connexion ou une pour chaque requête, bah t'as plus qu'a réécrire l'ensemble des pages. Youpi !
Après un test de sécurité de ton site, tu te rend vite compte qu'il est possible de faire des sql injection a 72 endroits, évidemment ca ne te serai jamais arrivé avec un ORM correct.
Alors bon, ouais ouais ca sert absolument à rien les templates et les ORMs, sauf à avoir des applis qui marchent et que tu peux continuer de développer au bout d'un an.
Par contre, tu soulèves un bon point, un système de template seul n'est pas méga utile, même s'il l'est pour tout un tas de raison que j'ai déjà cité avant. Il ne l'est réellement que dans le cadre d'un développement MVC et plus particulièrement dans le cadre de frameworks tels que Symfony.
En effet, il n'y a que 2 vrais moyens pour faire en sorte que les gens codent correctement :
- qu'il soit plus facile de coder propre que salement
- que ce qui est sale soit impossible à réaliser (par exemple via un système de template trop limitatif pour faire du SQL dans la vue, sans développer un gros truc le permettant, mais dans ce cas... faut les fusiller quoi!)
Par contre oui, tous les bons framework mvc font en sorte que le passage d'un objet du contrôleur vers la vue soit le plus simple possible, et des outils comme spring permettent aussi de câbler facilement ( IOC ) les objets métier dans les contrôleurs ;)
[^] # Re: Journal très pertinent
Posté par cgo2 (site web personnel) . Évalué à -1.
Sinon par curiosité, dans ta vraie vie à toi, tu changes vraiment tous les 4 mois de SGBD ? Parceque chez moi non hein, on autre chose à foutre sur les projets...
[^] # Re: Journal très pertinent
Posté par Bastes . Évalué à 4.
Par exemple : le jour où tu passe de la version de dev sous SQLite (pourquoi faire de la configuration et de la sécurité en monoposte ?) vers la version de pré-prod ou prod.
[^] # Re: Journal très pertinent
Posté par thedude . Évalué à 3.
Une fois ceci dit, si je me trompe lourdement, je serais ravi qu'on me corrige.
Bref.
On peut prendre le probleme autrement aussi.
Il existe des outils qui vont:
- Simplifier enormement ton code (grosse diminution du code sql, gestion du pool de connexion etc.),
- Te rendre independant d'un quelconque SGBD,
- Te decharger d'une partie de la secu de ton appli (l'injection SQL, meme si ca se charge de facon manuelle, ca peut aussi se faire de facon automatique et c'est toujours ca de gagne)
- Potentiellement te faire gagner des perfs (cache d'objets, bon courage pour implementer ca a la main), ou en tout cas pas t'en faire perdre des masses.
Sachant que ces outil sont matures et fiables, quelle est la bonne raison objective de s'en passer?
Oui, on peut faire sans, mais on peut aussi faire avec, et ca apporte reellement toutes ces choses que j'ai citees plus haut, a un cout qui est derisoire.
C'est pas du babysitting comme tu le dis, c'est juste profiter d'un outil pour se decharger d'une part de travail ingrate pour se concentrer sur une partie plus interessante et utile du boulot (peaufiner le code metier et les features).
Mon boulot, c'est d'ecrire des applis metiers efficaces qui rendent le boulot des autres plus simples, pas de maintenir du sql ou de me prendre la tete avec des problemes purement techniques qui sont deja resolus par d'autres.
J'ai l'impression qu'on assiste au meme debat a chaque fois qu'on met au point une techno qui resoud des problemes purement techniques qui etaient inenvisageable qq annees auparavant.
C'etait pareil avec les compilos, avec les jvm, la memoire managee, les frameworks divers et variees, les IDE, que sais je encore.
Personnellement, un mec qui se pointe pour un entretien d'embauche et qui me sort ce genre de theories, il est recale d'office, et le reste de l'equipe pense pareil (et oui, ca nous est deja arrive, le mec etait recalcitrant a Spring, Hibernate et aux IDE).
[^] # Re: Journal très pertinent
Posté par Temsa (site web personnel) . Évalué à 1.
Le langage était du powerbuilder, en langage magnifique puisqu'il te permet de (t'oblige à?) câbler directement ton SQL dans un datagrid et des champs. Sauf que changement de BDD => réécrire entièrement l'appli ou presque (c'est à ce moment là que j'ai découvert que le SQL était une blague).
D'autres questions ?
A présent je bosse en SSII et dans des projets open source, et travailler pragmatiquement en utilisant de bons outils m'évite beaucoup de problèmes (notamment de sécurité, de flexibilité et de performances), me permet une maintenance plus facile, permet d'avoir un code mieux découpé et m'évite d'avoir à écrire des doc et des commentaires à tour de bras car le code est bien découpé et simple à comprendre (les noms de fonctions constituent le gros de la doc, et c'est suffisant pour que quelqu'un rentre dans le projet sans le connaître).
Utiliser dans des projets , étudier, comparer des outils de template de MVC, ou pas, d'ORM ou pas, de ORM maison ou d'ORM opensource, expliquer aux gens comment découper leur code, les aider avec des outils toujours plus performant et toujours plus simple, c'est une bonne partie de mon métier, et je vois directement ce qui marche ou non.
On ne vit pas dans le monde des bisounours et tous les développeurs ne savent pas forcément coder propre(ne serait-ce que sur un point précis à régler d'urgence), surtout sous la pression des délais et des livraisons à 2h du mat qui marche toujours pas, et dans ces moment là, les couches, les bonnes pratiques et tout, ça apporte rien dans les 5 minutes pour régler le problème et achever la livraison, alors tout le monde les envois chier les bonnes pratiques...
Du coup on en revient toujours à 2 points : empêcher les mauvaises pratiques via des limitations, ou favoriser les bonnes pratiques en les rendant plus simple que les mauvaises. Les 2 fonctionnent, et en combinaison ca marche d'autant mieux !
[^] # Re: Journal très pertinent
Posté par astennu . Évalué à 3.
Au-delà de l'usage d'un framework, d'un ORM ou d'un moteur de template, rien ne peut remplacer de bonnes pratiques de développement. Pour l'avoir vécu, je peux assurer que la mise en place d'un bon framework ne protège en rien des développeurs qui pondent du code à grand coup de copier/coller, de méthodes de 300 lignes et de if en cascade , le tout dans la plus grande ignorance des impacts en terme de performance et de sécurité (sans parler des requetes SQL dans le controleur, ainsi que des chaines HTML construites dans ce dernier). Si, on peut plus facilement isoler et refaire ces fonctionnalités car elles n'ont pas été imbriquées dans le coeur de l'application (et protèger ainsi le code "sain").
# Et de l'utilité du moteur Templeet en PHP
Posté par M . Évalué à 5.
# Des syntaxes spécialisées.
Posté par Bastes . Évalué à 6.
1- pour fournir une syntaxe "gentille" pour les non-codeurs
2- pour faciliter la maintenance des vues parce que la syntaxe est "gentille"
3- pour automatiser les mises en cache des vues (tout passe par le moteur de templates qui gère)
4- parce que ça va augmenter la productivité
Bien, ce sont les arguments que j'ai déjà entendu sur le sujet. Il se trouve que je travaille dans le développement d'applications "oueb" (et même "oueb deupouainzéro" il y a peu) depuis plusieurs années, et que j'ai testé différentes approches concernant les vues. Et la seule qui marche vraiment bien, c'est le pattern MVC + la factorisation dans des méthodes du code de vue redondant + des conventions claires et connues de tous les codeurs + du simple code du langage utilisé dans les vues, tout simplement. Oh, j'oubliais : bien choisir son langage. Un exemple de framework qui présente tous ces aspects : Ruby on Rails. Oups, ce n'est pas du PHP ? Justement, j'y reviens plus tard.
Mais alors, pourquoi les bons arguments pour les templates ça marche pas ?
Eh bien :
1- a. Si la syntaxe à besoin de devenir "gentille" c'est qu'elle ne l'était pas à la base. Exemple : PHP, plombé par des scories de C, trop fait pour "coller au web" mais pas assez pour factoriser correctement le code, pas assez accessible pour un profane du développement
1- b. La syntaxe ne sera jamais "gentille" pour le non-codeur, au plus elle sera un tout petit peu moins aggressive, au pire elle fera plus peur. Regardons les choses en face, pour faire du code, il faut apprendre des langages de code, quel intérêt dès lors de forcer des développeurs à apprendre un para-langage super-spécifique ?
1-c. Les non-codeurs, par essence, ne devraient pas avoir à coder. Pour coder, et même pour faire de l'intégration, embauchez des codeurs, ils feront du travail plus propre. Les designers, ils font le design, au mieux ils découpent des éléments pour les codeurs, et ça suffit déjà à les occuper s'ils sont compétents.
1-d. La coloration syntaxique, il faut qu'elle soit adaptée à la nouvelle syntaxe. Ou alors faut coder en daltonien.
2-a. Ca ne facilite pas la maintenance de forcer les mainteneurs à connaître un langage en plus. En fait ça le complique.
2-b. Le moteur de template va évoluer. Faut-il répercuter les évolutions ? Ca coûte du temps inutile tout ça, ça apporte des risques d'effets de bord, et ça rapporte généralement rien de concret. Sauf quand ça corrige des bugs. Donc on le fait quand même ?
2-c. De même que pour développer des vues c'est mieux d'avoir un développeur, pour les maintenir ça peut même être critique. Les vues évolues en se compliquant quand on les laisse suivre leur nature, il faut un bon jardinier pour élaguer les branches mortes sans couper les branches importantes et faire un beau jardin.
3- On peut très bien automatiser les mises en cache sans besoin de moteur de template. Il suffit de faire des conventions claires et de définir un point de passage obligé pour le traitement des vues.
4-a. Au final, au mieux ça va faire baisser la productivité le temps que les développeurs acquièrent l'outil, au pire ça va la plomber durablement parce que les développeurs ne prennent pas le temps d'apprendre les petites subtilités qui permettraient de gagner du temps.
4-b. Et surtout, en utilisant un bon langage et en factorisant on obtient les mêmes effets positifs sur la productivité.
Bref, le moteur de template c'est un peu un pansement sur la béquille d'une personne qui a deux jambes bien portantes.
[^] # Re: Des syntaxes spécialisées.
Posté par Éric (site web personnel) . Évalué à -1.
Argh le mauvais conseil.
L'intégration est une expertise propre. Etre un codeur C, Java, ou même PHP n'apporte aucune valeur ajoutée pour de l'intégration. Ce sont des métiers totalement différents. A la limite l'intégrateur est presque plus proche du graphiste.
Arrêtez de filer le HTML et les CSS au développeur. Le Javascript c'est déjà limite (mais là oui, il faut savoir coder).
Maintenant qu'on soit clair, des intégrateurs ne sachant pas faire des echo et boucles en PHP, je n'en connais pas. Donc il n'y a franchement pas besoin de leur "cacher" le PHP.
[^] # Re: Des syntaxes spécialisées.
Posté par yellowiscool . Évalué à 8.
Envoyé depuis mon lapin.
[^] # Re: Des syntaxes spécialisées.
Posté par Bastes . Évalué à 4.
[^] # Re: Des syntaxes spécialisées.
Posté par David Carlier . Évalué à -1.
==>[]
[^] # Re: Des syntaxes spécialisées.
Posté par Bastes . Évalué à 0.
Par contre, pas d'accord, pour être un bon intégrateur il faut avoir des bonnes notions de dynamique, donc de PHP (ou Ruby, ou Python, ou Pearl, ou Java, ou quelque langage server-side que ce soit). En plus il vaut mieux à l'heure actuelle être à l'aise en JavaScript et avec le(s) framework(s) utilisé(s). Ensuite, le HTML c'est pas du code mais c'est un langage quand même, et s'il y a du JS derrière il vaut mieux qu'il soit clean. Enfin, les CSS c'est aussi un langage, qui a des subtilités chiantes et qui est intérprété différemment sur les différents navigateurs, donc complexe, surtout avec du JS.
Ok, un intégrateur doit aussi savoir faire des bidouilles avec les images et même avec du flash (beurk) mais c'est marginal. Ce qu'on lui demande, c'est de faire en sorte que les vues marchent, restent le plus propre possible, et présentent bien. Dans ces 3 critères, les deux premiers sont très majoritairement du code, alors que le troisième seulement est de la présentation (et si les 2 premiers sont pourris, le 3° sera beaucoup plus difficile).
Donc, pour être un bon intégrateur il faut être un bon codeur, mais pas forcément en C ou en Java je te l'accorde.
# I'm loving it !
Posté par Le Gall Sébastien . Évalué à 1.
* Gestion des langages bien sur !
* Moi je code php. Mais je suis une vrai merde coté disign. Alors je travaille avec des gens qui s'y connaisse en css et html, etc. Et qui n'ont pas besoins de connaître quoi que ce soit au php.
# Keep It Simple, Stupid
Posté par Feeks . Évalué à 1.
En fait, une fois qu'on a compris que le PHP est fait pour faire "du PHP dans du HTML" et non "du HTML dans du PHP", ce problème ne se pose plus (sinon on fait des scripts CGI, on sera plus à l'aise). Et en effet, certains diront que PHP est déjà un moteur de templates. Cela dit, utiliser un moteur de template peut-être une évolution en terme de lisibilité, à condition que ce moteur reste simple et léger, sinon l'intérêt est nul (puisqu'il complexifie le site).
En ce qui concerne la persistance des données et tout le bazar SQL, cela peut être une très bonne chose. Mais si on y réfléchit bien, est-ce que cela vaut vraiment le coup d'utiliser, en plus du code spécifique à un site, un moteur de template, un framework pour la persistence et pleins d'autres choses censées "faciliter la maintenance" ?
Car au final, le mainteneur devra se familiariser avec tout un nouveau jargon, des nouveaux concepts et j'en passe, alors qu'il aurait pu se contenter de maintenir un simple code PHP ?
Je pense que le meilleur moyen de faire un code maintenable n'est pas d'utiliser des tonnes de frameworks, mais tout simplement d'écrire un code clair, structuré et uniforme.
[^] # Re: Keep It Simple, Stupid
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.