PHP en tant que langage de modèle, ou un autre script de modèle PHP?

Question

Le PHP en lui-même est-il un assez bon langage de templating, ou devrait-on utiliser quelque chose comme Smarty pour écrire des templates PHP?

Answer 1

N'oubliez pas que le but initial de PHP était d'être un langage de templating. Je travaille selon le principe des "conditionnelles et boucles" : en général, je n'utilise que les conditionnelles et boucles de PHP dans mes templates, et seulement pour générer du code HTML. Tout traitement de données, logique métier etc. se fait ailleurs (comme dans un modèle ou un contrôleur). Il EST possible d'être discipliné avec le templating en PHP.

Alex P a cependant raison. Si vous ne faites pas confiance aux autres personnes qui pourraient travailler sur ce code, vous devrez peut-être les forcer à utiliser quelque chose comme Smarty.

Answer 2

Je n'aime pas utiliser un langage de modèle par dessus PHP, car comme on l'a noté, PHP a été initialement conçu comme un langage de modèle, et fonctionne très bien pour cela. J'ai entendu Rasmus Lerdorf (le gars qui a écrit PHP à l'origine) faire une présentation et dire quelque chose dans le genre de "Finalement, quelqu'un écrira un langage de modèle simple en utilisant Smarty" (en plaisantant sur la complexité de Smarty).

Il y a des situations comme Udo l'a souligné qui nécessitent l'utilisation d'un langage de modèle séparé. En interne cependant, tant que vous avez un peu de lignes directrices de codage (comme ne pas mettre la logique métier/base de données dans la couche de présentation (modèle), vous êtes bien.

Un moyen facile et agréable de garder le code séparé:

function showTemplate($filename, $variables) {
   extract($variables);
   include('templates/'.$filename);
}

Vous pouvez vous compliquer les choses avec ceci, et utiliser la mise en tampon de sortie et autres pour le faire retourner des valeurs. Mais efficacement, cela vous donne un espace de noms séparé pour exécuter chaque modèle. S'ils définissent des variables, cela n'écrase aucun de votre autre code (tant qu'ils n'utilisent pas "global" -- ceci devrait faire partie des lignes directrices).

Utiliser ceci est assez facile. Dans votre code appelant (business):

$valeurs = array(
  'title' => 'Mon Site',
  'username' => $currentUserName,
  'version' => VERSION_DE_MON_SITE,
);
showTemplate('main.php',$valeurs);

Dans le modèle:

Bonjour, , bienvenue sur 

`

Efficacement, vous obtenez ce que Smarty vous offre, sauf que la syntaxe est légèrement différente ( au lieu de {{ }} ou peu importe ce qu'ils utilisent), vous n'avez pas besoin d'apprendre un nouveau langage, et cela s'exécute à la vitesse native de PHP (au lieu de la vitesse d'un langage interprété fonctionnant à l'intérieur d'un autre langage interprété).

`

Answer 3

Il dépend de vos goûts et de vos exigences en matière de langage de modèle. PHP est bien sûr un langage de modèle en soi, et l'utiliser à cette fin vous permettra d'obtenir plus d'efficacité dans l'utilisation des ressources d'exécution, une complexité de code moindre et une manipulation plus facile. Gardez à l'esprit que PHP n'est pas Java, la plupart du temps il n'est pas nécessaire d'encombrer inutilement le système juste pour ajouter un autre élément à la liste des fonctionnalités pour votre CMS coûteux ou quelque chose de similaire.

Il existe cependant quelques indications claires où un langage de modèle séparé pourrait être nécessaire, selon votre jugement bien sûr :

Sécurité du code : Une fois que vous autorisez les utilisateurs à modifier du PHP à l'intérieur de votre application, vous leur donnez les clés de votre serveur web. La granularité de l'exécution du code est très difficile à atteindre en PHP, il n'est tout simplement pas conçu pour cela. Cela signifie que l'éditeur d'un "modèle" a automatiquement accès à tout l'environnement PHP, y compris les parties internes de votre logiciel. Bien que certaines méthodes de restriction d'accès existent, il est parfois plus facile d'utiliser un langage de modèle qui ne fournit pas de fonctionnalités critiques pour commencer.

Prévention de la négligence : Pour la plupart des projets, il est logique de séparer la logique métier de la logique de présentation. Encore mieux, vous pouvez opter pour un paradigme modèle-vue-contrôleur, qui est très en vogue de nos jours. Cependant, il existe toujours la tentation de mettre du code "métier" dans vos modèles. Avoir un langage de modèle permet d'éviter cela.

Validation : Le succès de l'exécution d'un modèle PHP sans erreurs d'exécution ou de compilation dépend souvent de l'état exact et du contexte de l'environnement. Cela signifie que dans la plupart des projets, il devient difficile de juger de manière programmatique si un "modèle" donné s'exécutera sans générer d'erreurs. Les fonctionnalités limitées d'un langage de modèle peuvent vous permettre de valider l'intégrité d'un modèle à l'avance, en déplaçant les erreurs possibles dans la logique du modèle ou du contrôleur, où elles pourraient être plus faciles à identifier et à déboguer.

Il existe de nombreuses autres raisons pour et contre l'utilisation de langages de modèle, toutes sont certainement valables dans différents contextes. De plus, le choix du langage lui-même est important pour la tâche que vous souhaitez accomplir. Personnellement, je choisirais de ne pas utiliser un moteur de modèle séparé sauf dans des circonstances très spéciales, mais comme toujours, il n'y a pas de substitut à votre propre jugement. ;-)

Answer 4

Non assez bon

PHP rend facile la sortie de balises non valides, mais difficile de s'assurer que (X)HTML est valide et bien formé.

Vous devez penser à ajouter htmlspecialchars() à chaque fois que vous affichez des données en HTML. Si vous oubliez, le site semblera fonctionner correctement 99% du temps, mais il peut être vulnérable aux attaques XSS et CSRF (sans parler du fait qu'il sera mal formé).

Il y a beaucoup de constructions courantes qui sont faciles à rater - les crochets des if se perdent parmi les balises. Lorsque vous enveloppez facultativement quelque chose dans un élément, vous devez répéter la condition pour l'ouverture et la fermeture de la balise. Les balises PHP à l'intérieur des balises HTML sont affreuses.

Ma solution préférée à ce chaos est PHPTAL. Il est conscient de la syntaxe X(HT)ML et la vérifie pour vous. Il ajoute également automatiquement des entités partout - vous n'avez pas à vous en souvenir tout le temps (comme avec PHP ou Smarty).

Answer 5

Vous devez considérer si les avantages d'introduire Smarty justifient le temps d'apprentissage et le surcoût de performance par rapport au PHP pur :

1. Si vos pages sont codées par des développeurs non-PHP, éviter la syntaxe PHP pourrait être bénéfique
2. Vous pourriez soutenir que Smarty améliore la lisibilité

cependant, puisque le PHP est en soi un langage de templating, vous n'avez en réalité pas besoin d'autre chose.

Si vous n'aimez pas intégrer des balises dans votre HTML, vous pouvez utiliser des heredocs. Par exemple :

$title

$content

DYNAMIC\_CONTENT;
?>