Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Matthieu Napoli

blog technique

Quel langage de templating utiliser avec PHP ?

C'est une question qui revient souvent, et auquel le nombre non négligeable de moteurs de templates pour PHP complique la réponse.

De mon point de vue, pas besoin de chercher trop loin : PHP est parfait pour ça.

PHP est à la base un langage de templating. Il fournit la majorité des outils nécessaires, pour ceux qui manquent, il n'y a qu'à les développer (principe de View Helper par exemple).

La liste des avantages de PHP vis-à-vis des autres langages est sans appel :

  • Pas d'apprentissage d'un nouveau langage
  • Auto-complétion et validation dans l'IDE (bien que pour des langages basés sur XML il est possible d'avoir ces fonctionnalités aussi)
  • Possibilités d'extensions/fonctionnalités "illimitées"
  • Rapide (un langage interprété par du code PHP est forcément plus lent que d'utiliser directement du PHP)
  • Pas de limitations lors de l'utilisation d'objets (peu de langages de templating permettent d'utiliser les attributs ou getters d'un objet)

Des réponses aux critiques souvent faites à PHP pour du templating :

  • « PHP est verbeux »

Je prends l'exemple de Twig qui propose, à la place de ce code PHP : <?php echo $var ?>, la notation suivante : {{ var }} car beaucoup plus courte.

Ce qu'ils ont passé sous silence dans leur exemple, c'est le short tag pour echo... Autant avant PHP 5.4, son utilisation était un vrai choix à faire, car cela nécessitait d'activer tous les shorts tags dans la configuration PHP (désactivés par défaut). Mais depuis cette nouvelle version, c'est reconnu comme faisant 100% partie du langage car le short tag suivant est toujours actif, peut importe que les "autres" short tags soient activés :

<?=$var?>

Ça n'est plus très verbeux. Dans le même genre <?php echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?> peut être très facilement (et je le recommande) remplacé par un helper : <?=$this->escape($var)?>.

Au contraire, je trouve que PHP rend le code moins verbeux. Par exemple (Fluid de FLOW3) :

<f:if condition="{post} == {currentBlogPosting}">
    <f:then>
        <div class="post selected"></div>
    </f:then>
    <f:else>
        <div class="post"></div>
    </f:else>
</f:if>

Alors qu'il suffit de :

<?php
$selected = "";
if ($post == $currentBlogPosting) {
    $selected = " selected";
}
?>
<div class="post<?=$selected?>"></div>

(sans compter la duplication de code évitée)

  • « Un langage de templating permet à des non-développeurs de lire/travailler sur le template »

Mais dans ces non-développeurs, qui n'a pas un minimum de rudiments de PHP ? Si un webdesigner doit intégrer un design dans un template, on s’attend généralement à ce qu'il ait la base en PHP (j'entends si c'est à lui d'intégrer le design dans le template).

Et si ça n'est pas le cas, pour afficher une variable, écrire un if ou un for, le langage de PHP n'est pas plus compliqué qu'un autre langage de templating. Et ça lui sera beaucoup plus utile d'apprendre PHP que d'apprendre un nouveau langage de template pour chaque projet/client.

Et avec la syntaxe alternative pour les blocs, c'est très lisible et la signification coule de source, même pour un novice :

<?php if ($a == 5) : ?>
     <strong>A égal 5</strong>
<?php endif; ?>
  • « Un langage de templating empêche d'avoir de la logique métier dans le template »

Ce point là est un peu plus intéressant, car il est vrai, on peut se retrouver avec du code métier dans le template. En interdisant PHP, on est sur de ne conserver que l'élémentaire (boucles, branchements conditionnels, formatage...).

Mais ce point seul ne justifie pas l'effort à mes yeux. Sinon, en suivant cette logique, autant avoir un langage séparé pour chaque couche de l'application pour garantir encore plus leur séparation.

Cette solution traite les conséquences du problème et non pas la source : bien coder (tout simplement :p). En réalité, ce problème n'existe pas avec des développeurs qui comprennent le principe de séparation des couches. Leur enlever cette réflexion (ce code appartient-il bien à cette couche) avec des verrous, c'est leur demander de moins y réfléchir, de moins se soucier de ça, et au final alimenter le problème (mélange des couches ailleurs, nécessité de mise en place d'autres verrous, etc...).


Pour conclure ce billet, je ne peux que souligner les regrets de voir FLOW3 utiliser un langage de templating. C'est bien un des rares défaut que je vois à ce framework tellement prometteur (ce mot est-il encore valide maintenant qu'une version stable est sortie ?).

D'autre part, je suis conscient qu'il manque quelques petits plus à PHP pour augmenter son usabilité, mais cela reste la meilleure solution à mes yeux.

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: lundi 12 mars 2012 14:17 par MadMatt
Classé sous : ,

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- SharePoint : Bug sur la gestion des permissions et la synchronisation Office par Blog Technique de Romelard Fabrice le 07-10-2014, 11:35

- SharePoint 2007 : La gestion des permissions pour les Workflows par Blog Technique de Romelard Fabrice le 07-08-2014, 11:27

- TypeMock: mock everything! par Fathi Bellahcene le 07-07-2014, 17:06

- Coding is like Read par Aurélien GALTIER le 07-01-2014, 15:30

- Mes vidéos autour des nouveautés VS 2013 par Fathi Bellahcene le 06-30-2014, 20:52

- Recherche un passionné .NET par Tkfé le 06-16-2014, 12:22

- [CodePlex] Projet KISS Workflow Foundation lancé par Blog de Jérémy Jeanson le 06-08-2014, 22:25

- Etes-vous yOS compatible ? (3/3) : la feuille de route par Le blog de Patrick [MVP SharePoint] le 06-06-2014, 00:30

- [MSDN] Utiliser l'approche Contract First avec Workflow Foundation 4.5 par Blog de Jérémy Jeanson le 06-05-2014, 21:19

- [ #ESPC14 ] TH10 Moving mountains with SharePoint ! par Le blog de Patrick [MVP SharePoint] le 06-01-2014, 11:30