Discussion :

[X0000]

Heuuuuu PHP n'est il pas déjà un compilateur de template à la base ? Pourquoi y remettre une surcouche ...? Rien empêche de séparer le traitement et la présentation

[Grimly_old]

J'admet dans mes applications web que l'utilisateur est aussi "limitée" dans l'utilisation d'un navigateur que ma copine. Elle n'a pas à ce jour désactivé une seule fois le javascript (elle ne sait pas le faire quand je lui demande)

Du coup mes pages HTML avec l'aide de CSS et Javascript sont purement statiques. Le PHP ne me sert qu'aux services pour que mon application trouve ses informations.

[Gats]

Le plus souvent, quand j'ai le choix, j'utilise un moteur de template (smartyV3 ou Twig).

pour les raisons suivantes (spécifiquement pour du Frontend) :

- confort grâce à la séparation de code claire
- fonctionnalités disponibles très utile (héritage, gestion de cache etc)
- gros projet avec beaucoup d'intervenant (développeurs, graphistes etc)

Bien entendu sur la conception de script Backend je n'en aurai pas vraiment l'utilité ^^

[Thiht]

Petite question étant donné que je suis non-pro et que j'ai jamais eu l'occasion de travailler avec des graphistes : pourquoi est-ce que l'un des arguments qui revient souvent en faveur des moteurs de templates est "ça facilite le travail du graphiste car c'est plus séparé et y a pas de code partout etc." ? Le graphiste n'est pas censé travailler sur le code HTML généré (ne serait-ce que pour visualiser son travail) ?
Et finalement pour un graphiste sans notions de programmation, entre voir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<ul>
<?php for($i=0; $i < 10; $i++): ?>
 
	<li>Liste</li>
 
<?php endfor; ?>
</ul>

ou (Twig)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<ul>
{% for i in 0..9 %}
 
	<li>Liste</li>
 
{% endfor %}
</ul>

ça change réellement quelque chose ?

[bigsister]

Petite question étant donné que je suis non-pro et que j'ai jamais eu l'occasion de travailler avec des graphistes : pourquoi est-ce que l'un des arguments qui revient souvent en faveur des moteurs de templates est "ça facilite le travail du graphiste car c'est plus séparé et y a pas de code partout etc." ? Le graphiste n'est pas censé travailler sur le code HTML généré (ne serait-ce que pour visualiser son travail) ?
Et finalement pour un graphiste sans notions de programmation, entre voir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<ul>
<?php for($i=0; $i < 10; $i++): ?>
 
    <li>Liste</li>
 
<?php endfor; ?>
</ul>

ou (Twig)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<ul>
{% for i in 0..9 %}
 
    <li>Liste</li>
 
{% endfor %}
</ul>

ça change réellement quelque chose ?

+1
Je rajouterai que j'ai eu à bosser avec plusieurs boîtes ou freelances et la plupart du temps le résultat est le même : Des visuels OK mais du HTML/CSS tout pourri. Depuis je ne demande plus que les sources PSD ou AI des images créées et je préfère faire le reste moi-même...

Néanmoins cette syntaxe présente l'avantage pour le développeur de pouvoir peut-être plus facilement passer de PHP à ASP par exemple sans avoir à modifier ses vues... Ceci dit ... c'est comme PDO : Qui concrètement a eu l'occasion de changer tout le SGBD derrière son appli pour voir si ça tournait mieux : 1% des développeurs ?

[ABCIWEB]

+1
Néanmoins cette syntaxe présente l'avantage pour le développeur de pouvoir peut-être plus facilement passer de PHP à ASP par exemple sans avoir à modifier ses vues... Ceci dit ... c'est comme PDO : Qui concrètement a eu l'occasion de changer tout le SGBD derrière son appli pour voir si ça tournait mieux : 1% des développeurs ?

A mon avis tu es très au dessus avec 1%. Suivant les tables, des fonctionnalités dans les requêtes peuvent se comporter différemment. Alors croire qu'avec PDO on a tout résolu pour les éventuels problèmes de migration est une légende. Cela facilite la migration certes, mais la plupart du temps il faut repasser derrière, pour dire qu'on ne le fait vraiment que si l'on y es contraint

[Thiht]

Après pour PDO, je vois plus l'intérêt comme pour le dév, s'il a pour habitude de travailler avec différents SGBD selon ses projets (un projet avec MySQL, le suivant avec Oracle DB, etc. par exemple) , il n'aura pas à jongler avec les API fournies par ces SGBD, seulement avec les subtilités syntaxiques/fonctionnelles de chacun (et c'est déjà bien suffisant). L'intérêt pour la migration est pas flagrant, même pour du requêtage basique (le coup du LIMIT non standardisé par exemple).

[newinn]

perso : http://www.webtoolkit.eu/wt

ce frammework est tellemen puissant et cpp c'est autrement plus beau que php ou toute les autres forme de script qui peuvent servir dans le web !

Cpp mon amour !

[ypicot]

Avec un framework MVC, c'est du HTML intégrant du PHP.
Perso, j'aime beaucoup la syntaxe alternative, qui permet de construire une page basique contenant des "blocs PHP" à partir de laquelle le graphiste peut construire ce qu'il désire (au passage, j'affirme qu'il existe des graphistes qui connaissent un peu de PHP et qui ne font pas que des c....).

En reprenant l'exemple donné par Benjamin dans le msg initial, un découpage MVC (à la CakePHP, CodeIgniter ou assimilé) donnerait en gros :

Pour le controleur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
<?php
$user = "Jean";
$messages = array(
    'Lorem ipsum dolor sit amet, consectetur adipiscing elit.',
    'Cras sit amet mi quis mauris varius dignissim id et ipsum.',
    'Quisque id lacus lorem.'
);
?>

Et pour la vue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<!DOCTYPE HTML>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Mes messages</title>
</head>
<body>
    <? if (!isset($user)): ?>
    (...)
    <? endif ?>
</body>
</html>

Variables en lecture seule dans la vue = code plus propre.

Yvan

[stailer]

Pour les incultes qui répondent :

Moi je fais du RAZOR grâce à Asp.net MVC

Il faut savoir qu'il existe non pas 2 (aspx ou razor) mais des dizaines de moteur de templates en PHP.

Le moteur RAZOR est utilisé principalement avec ASP.NET MVC, prenons un équivalent Zend Framework:

De base le moteur de vue est PHP, ce qui est très bien : au moins c'est le même langage... MAIS mieux qu'ASP.NET MVC (même si j'adore ce framework) , Zend Framework permet grâce aux adapters d'utiliser les X autres moteurs de template sur le marché.

Merci de vous renseigner un minimum avant de balancer n'importe quoi.

EDIT : Je ne compare absolument pas ASP.NET MVC et le ZF, c'est pas le sujet et comme je viens de le dire : j'adore les 2.

[polymorphisme]

Bonjour,

j'utilise XSL dans un modèle MVC. XSL est pris en charge par de nombreux langages et clients Web.

[CyberDenix]

Avec un echo.

Enfin, je veux dire, une fonction qui stocke une chaine de caractères, et que je release en sortie.

C'est la manière la plus performante de procéder.

[CyberDenix]

ça change réellement quelque chose ?

Ça ne change rien.
D'autant plus que Rasmus Lerdorf (Créateur de PHP) l'a dit à de multiples reprises, PHP est déjà un moteur de templates.

Il n'y a aucun argument en faveur d'un tel type de surcouche (Twig, Smarty...). C'est contre productif et surtout contre performant (dans le sens rapidité d’exécution). Mieux vaut utiliser un système de cache custom à base de Memcached plutôt qu'utiliser un système de templating à la con. Pire que tout, avec les templates, tu bouffes deux fois plus de mémoire lors de l'assignation de tes variables : elles existent dans ton code PHP et dans ton template au moment de l'assignation.

[grunk]

On est tous d'accord php est un langage de template , mais voici au moins une bonne raison d'utiliser un système de template tiers :

Sur de gros projet sensible , il peut être nécessaire de limiter l'accès au code des différents intervenants. Un intégrateur n'a pas à manipuler du php et encore moins à accéder à une base de données.
Dans un fichier de template "classique" généré par PHP simple , il peut si ça lui chante te coller un mysql_connect et faire tout un tas de chose qu'il ne devrait pas faire.
Le développeur doit donc repasser en revue ce que l'intégrateur à fait.

Avec un moteur de template , on à pas ce soucis puisque php n'est pas interprété dans un fichier html. L'intégrateur à accès a un nombre limité de variables, quelques fonctions de base (boucle, condition) et c'est tout. On sait qu'il ne pourra pas mettre en danger le reste du code puisque que son champs d'action est strictement encadré.

Les moteur de templates c'est la même problématique que les frameworks :
Suis-je prêt à sacrifier de la performance pour du confort / de la sécurité / du temps de développement ?

[mawachi]

Quelques petits extraits de la doc symfony2 au sujet de twig et qui illustrent l'intérêt que j'y porte dans mes projets :

De par sa conception, le système de template Twig s'occupe de la présentation, pas de la logique.

Pour respecter le MVC, le système de template apporte un cadre qu'on est pas tenté de transgresser. Inutile de rappeler le gain de temps pour la maintenance qui découle de l'adoption de ce design pattern.

Twig peut aussi faire des choses que PHP ne pourrait pas faire, comme le contrôle d'espaces blancs, le bac à sable et l'inclusion de fonctions et de filtres personnalisés qui n'affectent que les templates.

Twig contient de petites fonctionnalités qui rendent l'écriture de template plus facile et plus concise. Prenez l'exemple suivant, il combine une boucle avec l'instruction logique if :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<ul>
    {% for user in users %}
        <li>{{ user.username }}</li>
    {% else %}
        <li>Aucun utilisateur trouvé.</li>
    {% endfor %}
</ul>

Twig est rapide. Chaque template Twig est compilé en une classe PHP natif qui est rendue à l'éxécution.

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

Bon, je ne vais pas citer toute la doc mais y a plein d'autres avantages comme le système d'héritage qui est assez puissant ainsi que divers helpers ou encore le fait de pouvoir générer du html mais aussi d'autres types de format.

Bien sûr, comme maintes fois répétées, tout est une question de goût et aussi de taille de projet (on va pas sortir le bazooka pour tuer une mouche... encore que parfois... ) mais le fait de lire que les templates c'est fait pour les abrutis ou les noobs m'a fait bondir (excusez-moi d'être si prude... )!!

Je n'ai pas eu l'occasion de pratiquer 10 000 systèmes de templates mais rien qu'avec un seul on peut s'apercevoir du gain en termes... de tout j'ai envie de dire. Alors par respect pour tous ces développeurs qui se sont brisés les noix pour nous sortir ces beaux outils, j'apporte ma petite réaction

[spoutbe]

Pour l'exemple de boucle avec le if de Twig, il suffit de faire une petite fonction helper de vue et le tour est joué.
De plus, le debug n'est pas tjs génial avec un moteur de templates... là où PHP t'indiquera une erreur succincte.

Bref, je ne comprend tjs pas l'intérêt...

[Invité]

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 !!

Prenons le cas facebook : codé en PHP & python, il a été "compilé" en code C++ par un outil de leur cru (avant d'être compilé lui-même) quand les performances sont devenues cruciales...

Il vaut mieux dire qu'elle manque de pertinence dans un cadre précis.
Un moteur de template peut prendre VRAIMENT un sens selon les problématiques rencontrées. Celui qui n'en a jamais utilisé ne fait en fait que débuter dans le métier.

Personnellement, j'utilise un système MMVC (je préfère au MVC) avec des vues génériques qui affichent les données du modèle passé par le contrôleur... Selon un template. Léger, parce que sinon ça devient vraiment trop lourd pour moi. A maintenir autant qu'à exécuter.

[*Serval]

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

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

[CyberDenix]

Un moteur de template peut prendre VRAIMENT un sens selon les problématiques rencontrées. Celui qui n'en a jamais utilisé ne fait en fait que débuter dans le métier.

Tu comprends bien que si ya zéro avantage à les utiliser, ces usines à prout relèvent de la branlette intellectuelle et sont bonnes pour la poubelle...

Prenons le cas facebook

Justement, parlons-en de Facebook.

Ils sont suffisamment intelligents pour ne pas utiliser de moteur de template comme Smarty ou Twig par dessus PHP.

Facebook utilise XHP, un module PECL de leur cru, afin étendre les capacités de l'instruction echo, et ainsi obtenir un meilleur rendu visuel dans leurs fichiers par la suppression de la gène visuelle occasionnée par la coloration syntaxique, elle-même engendrée par les quotes du echo.

http://www.facebook.com/notes/facebo...p/294003943919
http://www.quora.com/Where-does-Facebook-use-XHP
https://github.com/facebook/xhp/wiki

Ce qui revient à dire que Facebook utilise du echo.
La manière la plus performante de coder.
Comme moi.

[_skip]

Je ne suis pas un grand développeur PHP, mais je m'interroge.

J'ai surtout utilisé l'approche proposée par entre autre codeigniter, soit un controller qui fait le boulot, remplit une map avec des variables et finalement "charge" une view sous forme d'un fichier PHP, lui rendant disponibles les variables préalablement annoncées.

De mon point de vue de développeur c'est déjà une séparation entre la vue et le controller. Je n'ai jamais travaillé avec des gens qui étaient à ce point-là irresponsables qu'il aurait fallu leur trouver un système qui émet une décharge électrique lorsqu'on ouvre un fichier ailleurs que dans le répertoire "views".

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.
En revanche, je me demande s'il y a d'autres avantages que "youpie c'est un nouveau langage que le mr. photoshop y connaît pas", je pense peut être à des macros ou des composants qui pourraient par exemple construire facilement des widgets fastidieux style table éditable avec javascript ou ce genre de chose?