Comment produisez-vous votre HTML ?

[jjDai]

Bonjour à tous

Perso j'utilise un peu toutes les méthodes (sauf le mélange html php ingérable en maintenance), et je les choisi en fonction des contextes
pour développer des composants par exemple une liste déroulante saisissable ou un spin-button: la méthode echo reste une solution légère et efficace, sauf que je mets tout dans un tableau et seulement à la fin je fais un echo du tableau.

Des qu'il y a ds formulaire un peu complexe, j'opte pour des templates essentiellement pour faciliter la maintenance (avec une préférence pour smarty que je maitrise mieux).
Les performances je m'en fous un peu, les sites que je fais n'auront jamais l'audience des google, ebay...

La problématique de chacun est différente, et il n'y a pas de solution absolue.
Par contre je pense qu' il faut se poser les bonnes questions du style:
- WEB, intranet, extranet
- Est-ce du jetable, du pérenne, une expérience
- Dans quelle mesure l'application devra évoluer dans le temps
- Quelle sont les contraintes clients et celles de l'environnement.
- Qui devra assurer la maintenance de l'appli
- Quelle sont les compétences internes, celles à maintenir, celles à développer
- Quelle est l'audience cible
- Etc, etc , .....

Il me semblerait plus judicieux d'établir une check list de ces questions, et d'orienter les choix compte tenu de ces réponses.

Je travail dans deux contextes différents celui de l'entreprise, et dans un contexte perso pour des associations. Les techniques que j'utilise sont radicalement différentes.
L'utilisation d'un SVN en équipe par exemple, oblige à mettre en place une méthodologie commune surtout quand on ne connais pas les autres intervenants du projet.
Alors que pour un site associatif, je suis seul alors je peux me lâcher.

Sur-ce je vous souhaite une bonne journée
JJDai

[Matthieu Vergne]

Je fais rien de pro dans le développement Web (que des projets persos ou pour des connaissances), mais la clarté du code reste une priorité, ne serait-ce que parce que je peux pas me souvenir de tout et donc ça doit être facile à comprendre, pour vite reprendre en main un code qu'on n'a pas vue depuis un moment.

Pour la génération du HTML, je fais du HTML+PHP seulement au niveau de l'index (pour intégrer les appels PHP haut niveau qui génèrent le contenu), pour le reste j'ai mes propres classes. Pour un modèle MVC, les classes V héritent toutes d'une interface commune avec une fonction de génération de code HTML (après il y a les composants génériques, puis les spécialisés, ... qui implémentent tout ça). Du côté M, ce sont des classes du type structures de données, notamment avec des setters/getters, qui peuvent s'enregistrer en BDD ou non. Pour le C, c'est au besoin.

Même si je n'utilise pas du MVC partout, je reste généralement avec cette structure de classe haut niveau pour simplifier au max l'index.

[ludochm]

J'ai choisi PHP/Twig, parce qu'il partage avec Python/DTL et Erlang/ErlyDTL la même syntaxe et le même principe d'héritage.

Comme j'aime développer avec ces trois langages, je n'ai qu'une seule syntaxe a retenir, ce qui est pratique.

Quand au système d'héritage de blocs sur ces moteurs, c'est autre chose que les vieux include de base de PHP.

Le pire étant Prestashop avec smarty, les bouts de templates ne ressemblent à rien, tu as une balise body ouverte dans un fichier, fermée dans un autre.

Tu as des fichiers qui ferment 5 balises d'on ne sait où. Les variables commencent par '$' parfois, parfois il faut les entourer de " … C'est n'importe quoi smarty. Je n'ai pas regardé les dernières versions, peut-être ont-ils corrigé ça.

Edit: sur les tous petits projets je mix PHP/HTML avec la syntaxe alternative de PHP. C'est très lisible je trouve.

[grunk]

Envoyé par _skip

Donc à première vue, si le rôle du moteur de template est de paraphraser PHP en utilisant d'autres mots clé comme dans l'exemple d'une boucle citée sur la page précédente j'ai presque envie de rejoindre CyberDenix.

Soyons clair ce que fait un moteur de template , on peut le faire en php pure , certainement plus rapidement avec un peu de codage supplémentaire.

En plus de ce que j'ai expliqué sur ce post il y'a des chose dans les moteurs de template (twig pour ma part) qui sont réellement pratique :

- Par défaut tout ce qui est affiché est échappé , donc faille xss limitée. (rien que ça, ça vaut la perte de perf pour moi)

- On peut définir un template "global" dans lequel on défini des "block". Ensuite chaque template peut hériter de ce template et implémenter ou non les différents block. Bien plus pratique qu'un simple include php mais évidemment plus lent.

- Comme tu le dis certains moteur de template implémente des helper html. Tu passe par exemple un tableau à une balise et il te génére la liste d'option html tout seul.

[BPiero]

J'utilise le moteur de phpBB customisé en standalone. Pour ceux qui reprochent aux moteurs de template d'être trop lents, c'est la solution. Pour ceux qui reprochent aux moteurs de template de remplacer la syntaxe php par une autre aussi verbeuse, c'est la solution.
Avantages:
-rapidité
-cache (les fichiers de cache ne sont rien d'autre que du phtml généré avec les templates, d'où la rapidité)
-syntaxe simple, propre et peu verbeuse
@+
Piero

[BPiero]

Envoyé par *Serval

phpBB est considéré comme un moteur de template depuis la version 3.0 ?

depuis le début, mais ça n'est pas phpBB lui-même, c'est son moteur de template.

Envoyé par *Serval

Il fut un temps où c'était simplement un moteur de forum (qui utilisait son propre moteur de template).

Voilà, et ce temps n'est pas révolu, mais p-ê voulais-tu simplement souligner que phpBB est cité comme moteur de template dans la news, alors qu'il ne s'agit pas de phpBB en lui-même mais bien de son moteur de template. Dans ce cas je te rejoins à 100%.
@+
Piero

[laffreuxthomas]

Envoyé par FirePrawn

Et j'exècre particulièrement la méthode echo que je trouve immonde

À mon avis, la méthode des "echo" se justifie lorsqu'on génère le code HTML depuis des objets PHP. Tant qu'on reste dans le code d'un template, le code PHP devrait être inclus dans le HTML :

Code :

<article class="<?php echo $cssClasses; ?>"></article>

Mais si on génère en POO par exemple un calendrier : un objet "HtmlCalendar" contenant des objets "HtmlDay" et d'autres objets "HtmlEvent" par exemple, chacun produisant des portions d'éléments et aucun n'ayant l'ensemble de la structure, alors un code à base de "echo" est plus lisible.

Je précise qu'en parlant de template, je parle de la manière WordPress par exemple : de la syntaxe PHP appelant des API PHP. Concernant les "moteurs de templates" en surcouche de PHP mon avis rejoint celui de CyberDenix moins les insultes.

[Djakisback]

Personnellement, j'ai rencontré et rencontre 2 problèmes avec l'utilisation d'echo. Pas de complétion, validation, coloration etc. du html/js dans les IDE, générant une perte de temps.
D'autre part, tu te tapes forcément l'intégration si tu tombes sur des graphistes ne connaissant rien au PHP, HTML ou autre. Ne pas oublier aussi que certains graphistes ne s'occupent même pas de la source générée par leur Dreamweaver out autre et malheureusement on ne choisit pas toujours ses partenaires.

J'ai toujours très peu utilisé de moteur de templates pour les raisons citées : surcouche, syntaxe, etc. et ai toujours trouvé cela inutilement lourd mais l'argument de grunk au sujet de la répartition des accès me semble intéressant même si finalement ça n'a rien à voir avec la définition d'un système de templates de manière générale, non ? (idem pour le cache ?)

Ce qui me dérange aussi dans ce type d'outils (mais surtout au niveau des CMS en fait) et que quand une faille est trouvée, une "campagne de hack" est lancée. Tu dois donc toujours absolument être au fait des MAJ, etc. Le côté open source n'arrangeant évidemment rien.

[laffreuxthomas]

Envoyé par vaild

L'argument de la lenteur des moteurs de template est absurde : PHP en étant un lui-même, si c'est de la perf à tout prix qui est recherchée, on n'utilisera bien évidemment pas un langage de script !!

La performance est un souci constant des développeurs de PHP. Ça n'a peut-être pas suffi à Facebook mais c'est réel que PHP est véloce. Du moins si le développeur adapte sa manière de programmer au langage plutôt que l'inverse ; je pense notamment aux habitudes acquises en Java qui sont bénéfiques en Java mais contre-performantes en PHP.

Le seul intérêt des surcouches que vous défendez est l'intégration avec un système de cache. Sauf qu'un cache peut tout aussi bien être mis en place via des API PHP. Tous les développeurs que je connais et qui se sont frotté à Smarty ont râlé, et j'en fais partie. Qui choisit Smarty sur un projet ? Surement pas les développeurs.

[Matthieu Vergne]

Envoyé par Djakisback

Ce qui me dérange aussi dans ce type d'outils (mais surtout au niveau des CMS en fait) et que quand une faille est trouvée, une "campagne de hack" est lancée. Tu dois donc toujours absolument être au fait des MAJ, etc. Le côté open source n'arrangeant évidemment rien.

Ça c'est valable partout, c'est pas spécialement un argument contre ce genre d'outil, mais contre les outils utilisés de manière généralisée : quand un défaut est trouvé, si la nouvelle se répand c'est tous les utilisateurs qui sont impactés. Ça vaut aussi pour le moteur PHP que tu utilises (à moins que tu l'ai fais toi-même {^_^}).

Utiliser un programme perso, c'est profiter du côté secret mais au dépend de la robustesse (tout seul on pense à moins de choses, et on a moins le temps). Utiliser des programmes génériques c'est l'inverse, profiter de la robustesse au détriment de l'intérêt que les crackers peuvent lui porter. Le tout est de savoir ce qu'on veut.

[laffreuxthomas]

Envoyé par mawachi

Donc la question de la rapidité d'exécution ne se pose plus...

On se demande pourquoi les programmeurs de drivers bossent encore en assembleur et pas en langages évolués.

[grunk]

Envoyé par laffreuxthomas

Qui choisit Smarty sur un projet ? Surement pas les développeurs.

C'est sur que si tu as tester que Smarty , et avec un peu de chance en version 1 ou 2 t'a vite faite fait de plus jamais toucher à un moteur de template ^^ , c'est comme conduire une ligier et dire que les voiture c'est tout pourri

[CyberDenix]

Envoyé par laffreuxthomas

La performance est un souci constant des développeurs de PHP.

Vrai !

Envoyé par laffreuxthomas

Ça n'a peut-être pas suffi à Facebook mais c'est réel que PHP est véloce.

Oui, l'écosystème PHP est véloce, d'autant plus si on lui adjoint des extensions comme APC, Memcached, XCache... etc.

Cependant, pour illustrer et donner un ordre d'idée, il est généralement admis que le résultat d'un compilation en C d'un code PHP avec HipHop est généralement 3 fois plus rapide que ce même code PHP avec APC.

On parle certes de millisecondes, mais dans le cas d'une application fortement AJAXée avec du resfresh temps réel constant (zéro cache) telle que Facebook, cette différence peut devenir significative). Un appel qui dure 200ms au lieu de 600ms reste visuellement perceptible.

Envoyé par vaild

si c'est de la perf à tout prix qui est recherchée, on n'utilisera bien évidemment pas un langage de script !

Tout dépend de l'offre logicielle que l'on peut opposer à PHP.

Si il existe des serveurs web dédiés au langage C, tels que G-WAN (qui se vante d'être le plus rapide), ceux-ci souffrent de grosses lacunes (pas de rewrites...) et je ne vois sincèrement personne utiliser le langage C pour coder des pages web.

La moindre copie de chaîne en C est un supplice, alors imaginons un peu la gestion de fonctionnalités de plus haut niveau, telles que les cookies, les sessions, les regexs, les tableaux associatifs, la lecture des fichiers XML, la connexion à une BD... etc. Tout ce travail de traduction en un environnement optimisé et intellectuellement plus abordable a déjà été fait par Rasmus & l'équipe Zend avec PHP. Et je leur en suis chaque jour très reconnaissant.

[laffreuxthomas]

Envoyé par grunk

C'est sur que si tu as tester que Smarty , et avec un peu de chance en version 1 ou 2 t'a vite faite fait de plus jamais toucher à un moteur de template ^^ , c'est comme conduire une ligier et dire que les voiture c'est tout pourri

J'en utilise un : PHP.

Envoyé par CyberDenix

Tout dépend de l'offre logicielle que l'on peut opposer à PHP. […] Tout ce travail de traduction en un environnement optimisé et intellectuellement plus abordable a déjà été fait par Rasmus & l'équipe Zend avec PHP. Et je leur en suis chaque jour très reconnaissant.

Voilà. Et parmi les qualités de PHP, il y a un bon niveau de performance. Dans des projets où la performance est particulièrement critique PHP peut cependant se révéler insuffisant…

… mais la montée en charge spectaculaire de Facebook ces dernières années, et les solutions palliatives qui ont dû être trouvées au niveau performance, n'est pas un argument contre les performances de PHP. Bien au contraire. Le cas de Facebook est plutôt une preuve que PHP n'est pas une impasse même sur les projets anticipant une affluence gigantesque.

Si PHP n'est pas une impasse, qu'en est-il des surcouches ? Personnellement je demande à voir des exemples de sites qui démontreraient la performance des moteurs de template comme surcouches de PHP. Si vous voulez mon avis ils ne sont performants que tant qu'on ne les exécute pas : sur des sites relativement statiques où le cache répond à 95% des requêtes.

[dev14]

J'ai voté "echo".

Mais en réalité je passe tout dans une variable php et je "l'echote" à la fin.

Moi c'est la version mi-HTML mi-PHP que je trouve indigeste et affreuse

Mais je n'aime pas utiliser 406 echo en même temps non plus.

[I_believe_in_code]

Que du php avec plein de echos. Je fais tout ce qu'il ne faut pas faire. Mais ce n'est pas grave, car ce n'est pas sur des projets pros.

[dragonjoker59]

Moi, j'utilise echo.
Je déteste le mélange PHP/HTML que je trouve ... moche en fait.
Même l'absence de coloration syntaxique me gène moins visuellement que ce mélange de syntaxes. C'est d'ailleurs pour ça que ma page index.php ne fait généralement que déclarer les html, head, meta et body, le reste est fait dans des fichiers PHP séparés qui de ce fait ne contiennent que des echos. D'ailleurs je ne fais pas un echo mais autant que de lignes que j'écris.

[laffreuxthomas]

Envoyé par laffreuxthomas

Du moins si le développeur adapte sa manière de programmer au langage plutôt que l'inverse ; je pense notamment aux habitudes acquises en Java qui sont bénéfiques en Java mais contre-performantes en PHP.

Ces histoires de performances m'ont inspiré un billet.

[tonnebrre]

il y a des framework java qui sont sympa tel que JSF

[vaild]

je vais rebondir sur ce que disais CyberDenix.

[perso]
Bon, c'pas moi qui ai commencé avec les attaques perso, c'est toi avec ton "abruti et noob". je l'ai mal pris, j'avoue. et selon moi, être certifié PHP n'a aucun intérêt, à part peut-être pour un CV un peu light
[/perso]


1) je maintiens que quelqu'un qui n'a jamais utilisé de templates, fut-ce que par curiosité intellectuelle, est un débutant, et ce quel que soit le langage, pourvu que ce soit du web. mais j'imagine que tu en a déjà utilisé, sinon tu n'en ferais pas une critique aussi virulente (et impolie !)

2) certains moteurs de templates, pas du tout codés en PHP mais utilisable par lui ne souffrent d'aucune critique sur leur perf

3) on ne décide pas toujours de l'environnement sur lequel on travaille. ceux qui bossent depuis un moment le savent, parfois on nous impose une techno qu'on aime pas, parce que les responsables y voient un avantage plus important que de légers gains de perf, que parfois notre vision du projet ne nous permet pas de déceler. ou alors ce sont des incompétents notoires et on finira par prendre leur place s'ils n'ont pas fait couler la boite avant

4) tu parles d'extensions PHP utilisées par Facebook ? moi je maintiens transformation en C++. HipHop, dont tu parles toi-même, c'est eux qui l'ont conçu pour se débarrasser de PHP jugé trop light en perf sur certaines ressources critiques (voir ceci, par exemple)

5) [troll]le PHP n'était d'ailleurs pas le bienvenu partout chez Facebook, puisque leur chat était pendant un temps fait avec du Python ^^ (peut-être l'est-il encore ?)[/troll]



bref, je dis pas qu'il y a une solution miracle. pour un petit projet ou un projet perso, je vois pas l'intérêt des moteurs de template...
pour un projet de groupe, ça peut être intéressant si on préfère la maintenabilité et/ou la séparation nette des tâches à la performance.
mais encore une fois, même s'il est bon dans ce domaine, particulièrement avec certains compléments, PHP est limité. si on cherche la perf à tout prix... soit on a effectivement un site qui en a besoin, et dans ce cas une alternative à PHP serait une hypothèse, soit on s'est viandé dans l'optimisation de son code.


encore une fois, dire qu'une techno ou une manière de faire vaut mieux qu'une autre est ABSURDE. il vaut toujours mieux dire que dans un contexte spécifique, une chose est plus pertinente qu'une autre.

c'est toujours ce que répondront les personnes objectives qui ont vécu un minimum d'expériences différentes, au lieu de partir sur des débats stériles en défendant à tout prix un point de vue unique. je ne me considère pas comme expert, mais je sais qu'un point de vue ne peut se défendre que dans un contexte.

[troll]par conséquent, le topic même est absurde, comme tous les topics à troll...[/troll]