Créer son propre moteur de templates

Bonjour à tous ! :)

Alors voilà, j'ai lu les cours du Site du Zér0 et ceux de ce site (POO y compris). Mais maintenant, pour m'entraîner, j'aimerais essayer de coder mon propre moteur de templates. Je sais que c'est pas facile, que ça demande du boulot, mais j'ai de la volonté et je ne cherche pas quelque chose de compliqué. Seulement une classe qui permettrait de parser ces quelques balises en PHP :

{variable}
<if cond=""></if>
<elseif cond=""></if>
<else></else>
<while cond=""></while>

Et éventuellement quelques autres boucles comme for et foreach.

Mais le problème c'est que je n'arrive strictement à rien faire. A chaque fois j'obtiens une page blanche, mon template n'étant pas parsé. C'est pourquoi j'aimerais savoir si quelqu'un pouvait m'aider en me dirigeant vers un bon tutoriel sur la toile ou en m'indiquant le chemin à suivre car je suis totalement perdu :(

Merci d'avance pour votre aide et bonne continuation.

Leop.

Salut Léopard,

ce n'est sûrement pas ce que tu espères comme réponse, mais j'ai du mal à laisser ça tel quel : pourquoi un moteur de template. PHP est en soi déjà un moteur de templates. Partant de là, pourquoi rajouter une couche de traitement supplémentaire ? J'ajoute que ça, ce n'est pas moi qui l'affirme, c'est Rasmus lui-même.

Le petit bout de code que tu montres indique que tu es en train de développer une sorte de pseudo-langage de programmation pour gérer tes templates à la manière de Smarty? Et pourquoi ne programmerais-tu pas directement en PHP ?

Les inconditionnels de Smarty me répondront peut-être que ce moteur gère la mise en cache. OK, et alors ? On ne saurait pas le faire autrement en PHP ??

Donc personnelement (et ça n'engage bien entendu que moi), je ne saurais trop t'encourager à développer quelque chose d'autre pour t'entrainer. Tu veux monter des classes ? Pourquoi ne pas travailler sur de l'accès aux bases de données avec une couche d'abstraction ? Ou encore une classe de gestion de mise en cache. Là tu aurais de la matière utile qui te serait à mon avis 1000 fois plus profitable à court moyen et long terme.

:)

Je désire "simplement" coder un moteur de templates pour m'entraîner car c'est un sujet que j'apprécie et qui pourra m'être profitable par la suite. Quand je dis "moteur de templates", je fais bien évidemment allusion aux scripts tels que Smarty ou Gagatemplate même si, je le rappelle, je ne développe pas dans la même optique qu'eux.

Tu me demandes pourquoi je ne code pas directement en PHP. En effet, c'est une possibilité, mais étant donné que j'ai été recruté en tant que codeur PHP sur un projet de site web, je pense qu'il sera tout à fait bénéfique de séparer le PHP de la mise en page vis-à-vis des designers. Alors oui, un moteur de templates présente des défauts, mais il faut quand même admettre que niveau visibilité, c'est un avantage non-négligeable.

Mais on peut parfaitement séparer la couche de présentation de la couche de traitement sans utiliser des templates au sens où la plupart des développeurs l'entendent actuellement.

Dans l'immédiat, je suis au bureau, je n'ai pas trop le temps, mais ce soir j'essayerai de mettre un exemple de ce qu'on peut faire en PHP directement. J'ajoute que j'ai moi-même codé la plus grande partie du site internet actuel de auchandirect.fr sans utiliser de templates... et ça fonctionne fort bien.

Je reviendrai sur le sujet, je trouve le débat malgré tout intéressant. Emacs, ton avis sur le sujet serait tout à fait bienvenu aussi ;)

Bonjour Leopard et bienvenue sur Apprendre-PHP.com,

Je partage complètement l'avis de Cyrano. Nous avons tous deux suffisamment d'expérience avec les projets web PHP pour affirmer que les moteurs de templates sont une abbération totale. Je te déconseille donc fortement de te lancer dans l'écriture d'une telle application pour te former à la POO.

Un moteur de template c'est généralement une seule classe (donc niveau POO c'est assez pauvre car il n'y a pas d'intéraction entre objets) et c'est surtout un travail de maîtrise des expressions régulières à mon sens. D'autre part, un moteur de templates implique une surconsommation de ressources mémoires importante, bien souvent non justifiée.

Je partage à moitié ton argument sur la lisibilité du code et la séparation en deux couches distinctes du code PHP et de la vue HTML. Pourquoi ? Simplement parce que si ton code est bien écrit, ta vue HTML sera réduite à quelques instructions PHP simples. PHP possède d'ailleurs nativement une syntaxe proche de celle des moteurs de template. En voici un exemple :

<h1><?php echo $titre; ?></h1>
<?php if (count($articles)>0) : ?>
  <p>
    Liste des articles
  </p>
  <?php foreach($articles as $article) : ?>
  <div class="article">
    <h2><?php echo $article->getTitle(); ?></h2>
    <p>
      <?php echo $article->getSummary(); ?>
    </p>
  </div>
  <?php endforeach; ?>
<?php else: ?>
<p>
  Il n'y a pas d'article dans la base de données !
</p>
<?php endif; ?>

Ce code d'illustration est très lisible et facile à comprendre. Un designer et / ou intégrateur HTML doit être capable de pouvoir utiliser et comprendre ce genre de code pour réaliser ces maquettes graphiques. Il vaut mieux qu'il apprenne ce genre de code simple directement plutôt qu'un pseudo code de templating qui sera sûrement encore plus difficile à relire et implémenter.

Je parle en connaissance de cause. Jusqu'à maintenant, je n'ai jamais rencontré dans les deux sociétés où je / j'ai travaill(e/é) de designer utilisant les syntaxes de template. Tous utilisent directement ce genre de code PHP. Je travaille aujourd'hui chez Sensio Labs, la société qui édite le framework MVC symfony. Symfony n'utilise pas de moteur de template et s'appuie sur le code que je t'ai montré. Nous sommes une quarantaine de salariés dans les bureaux. Une dizaine de développeurs PHP, une demi douzaine de designers et 4 ou 5 intégrateurs HTML / CSS. Les intégrateurs ne développent pas mais savent tous utiliser les codes simples de PHP pour monter les interfaces graphiques que le pôle de création graphique leur a transmises.

Bref, je t'invite à te trouver un autre exemple plus intéressant comme écrire une couche d'accés à la base de données (abstraction et / ou ORM) comme te l'a évoqué Cyrano, modéliser une vidéothèque ou une discothèque ou une bibliothèque, développer une gestion d'utilisateurs entièrement orientée objet avec users, groupes, permissions, authentification... Si tu pars sur un tel système de moteur de template, tu ne vas rien apprendre d'intéressant au sujet de la POO et tu vas perdre ton temps.

En espérant que mes conseils t'aideront. Je t'invite même à essayer le framework symfony pour que tu puisses découvrir les bonnes pratiques de programmation, le découplage en MVC, et bien sûr la POO puisque symfony est complètement orienté objet.

A bientôt,

Hugo.

Pour illustrer, voici le même code que celui présenté par Emacs selon une méthode que personnellement je préfère :

<?php
$page = <<<CODE_HTML
<h1>{$titre}</h1>
CODE_HTML;
if (count($articles) > 0) :
$page .= <<<CODE_HTML
<p>Liste des articles</p>
CODE_HTML;
    foreach($articles as $article) :
        $titre    = $article->getTitle();
        $sommaire = $article->getSummary();
$page .= <<<CODE_HTML
<div class="article">
  <h2>{$titre}</h2>
  <p>{$sommaire}</p>
</div>
CODE_HTML;
    endforeach;
else:
$page .= <<<CODE_HTML
CODE_HTML;
$page .= <<<CODE_HTML
<p>Il n'y a pas d'article dans la base de données !</p>
CODE_HTML;
endif;
echo($page);

Ce n'est pas plus compliqué. La première chose à construire, c'est une maquette HTML complète de la page avec un contenu du genre lorem ipsum qui sera ensuite remplacé par des variables. On fait un code propre qu'il reste ensuite à découper en différents éléments selon qu'il s'agit de telle ou telle partie de la page, certains éléments pouvant être génériques, d'autres spécifiques au contenu dynamique.

Le seul défaut de la syntaxe HEREDOC, c'est qu'on ne peut pas utiliser de fonctions ni de conctantes directement dans le code, mais une nouvelle syntaxe a été présentée sauf erreur de ma part avec PHP 5.3 qui y ressemble pas mal et permettra cette fois d'utiliser fonctions ou constantes sans devoir créer des variables à part comme j,ai du faire sur les lignes 12 et 13 du code ci-dessus.

On ajoute pas de moteur de template, PHP est déjà là pour ça.

Bonsoir et merci de vos réponses !

Je dois dire que je suis très surpris par les codes que vous me proposez. En effet, je n'avais jamais entendu parler de ce type de syntaxe et j'avoue que même si c'est un peu moins lisible qu'avec un moteur de templates comme Smarty ou autre, cela reste tout à fait raisonnable et je suis sûr qu'un codeur XHTML saurait s'y retrouver. Mais comme je l'ai dit, je n'avais jamais vu de tels codes auparavant (et pourtant, Dieu sait que j'ai parcouru des centaines et des centaines de topics sur le Site du Zér0 !) donc si vous connaissez un site web où je pourrais approfondir mes connaissances sur la matière, je suis preneur ! ;)

Merci encore et bonne soirée. Grâce à vous j'aurai appris un nouveau concept et dorénavant je n'entendrai plus "moteur de templates" de la même façon.

Désolé du double-post.

J'ai lu attentivement ce tutoriel du SDZ qui explique les bases de l'utilisation du modèle MVC. Jusque là, j'ai compris, mais ensuite j'ai téléchargé le framework symfony et j'en suis vraiment désolé, mais j'ai STRICTEMENT rien compris. J'imagine que toutes ces classes et tous ces fichiers ont pour but de normaliser dans un cadre plus ou moins précis la façon de coder du développeur mais là, franchement, j'avoue que ce n'est pas de mon niveau :(

Bonne soirée malgré tout et merci de votre aide.

@Leopard : Pour symfony, il est clair que pour réussir à le prendre en main quand on débute, cela prend du temps. Pour bien débuter avec symfony, je t'invite à télécharger la sandbox de la version 1.1, puis de commencer le tutoriel "My First Project" qui t'apprend à monter un blog avec symfony en quelques heures.

@Cyrano : la syntaxe Heredoc me laisse perplexe, je trouve qu'elle nuit énormément à la lisibilité du code HTML.

À propos de la syntaxe Heredoc, il est vrai que la lecture du HTML n'est peut-être pas facilitée.

Mais à ce stade, on ne lit plus le HTML : le HTML doit déjà être prêt sous la forme de maquettes des différentes pages du site. On découpe pour n'utiliser que les parties du code de page nécessaire pour telle ou telle vue. On remplace le contenu en dur qui a servi à ajuster la mise en forme et on remplace par des variables.

C'est avec ce système que j'ai, en 2007, fait pratiquement toutes les pages du site actuel de auchandirect.fr : mais encore une fois, j'avais déjà préparé mes maquettes HTML. Je n'avais pas à me poser de question sur la structure de la page.

Le résultat est que ça fonctionne sans surcouche de traitement.