Concernant les templates PHP, c’est effectivement plus facile à dire qu’à faire. Il y a probablement plus de 20 choix aléatoires, et pear contient à lui seul 5 modèles différents, ce qui est vraiment un casse-tête.
Ne vous contentez pas de suivre les opinions des autres et de dire que celle-ci est bonne et celle-là est mauvaise. Avant de choisir un modèle, vous feriez mieux de comprendre d'abord quel est le véritable objectif du modèle ? En termes simples, l’objectif principal d’un modèle est le travail d’équipe. Il existe deux manières principales de fonctionner :
1. La séparation du HTML et du PHP rend la coopération entre les concepteurs Web et les programmeurs PHP plus agréable.
2. La séparation de la logique d'affichage et de la logique de transaction rend plus facile et plus flexible la modification de la logique de transaction principale et l'extension des applications, ce qui signifie que la coopération entre les programmeurs est plus agréable. (Ce point est souvent négligé ou mal compris par les gens. Ils pensent toujours que retirer PHP du HTML s'appelle séparer la logique d'affichage et la logique de transaction. Si tel est le cas, pourquoi s'embêter à mélanger PHP et HTML en premier lieu ?
) objectif réel de ce modèle Qu'est-ce que c'est, il sera plus facile de faire le bon choix.
Si vous êtes le seul programmeur PHP mais que vous devez travailler avec d'autres concepteurs Web, choisissez un modèle capable de séparer HTML et PHP, phplib (semble désormais être intégré à Pear http://pear.php.net /package/HTML_Template_PHPLIB ) ou
FastTemplate est quelque chose comme ça, très simple et facile à utiliser.
Si l'interface de votre site Web est laide et est principalement complétée par des programmeurs, mais que les fonctions sont plus complexes et nécessitent des fonctions d'extension puissantes, et que vous devez séparer différents niveaux, y compris la logique d'affichage, alors n'utilisez rien de spécial, PHP lui-même est le meilleur modèle. . Il convient de noter que dans ce cas, vous devez concevoir votre programme très soigneusement et toujours penser à séparer non pas PHP et HTML, mais la logique métier et la logique de présentation. C'est pourquoi j'ai toujours été très résistant à des choses comme Smarty, car la syntaxe de Smarty est trop complexe et puissante, réinventant presque un langage de script (même les programmeurs PHP doivent le réapprendre). Ce qui est encore plus déroutant, c'est que plus ce script est puissant, plus il est facile pour les utilisateurs de mélanger la logique métier et la logique de présentation, détruisant ainsi l'intention initiale du modèle.
Si vous souhaitez séparer HTML et PHP et obtenir une meilleure conception visuelle, mais que vous souhaitez également que l'ensemble du système dispose de capacités d'extension très puissantes pouvant s'adapter à diverses interfaces HTML, XML et WML sans avoir à apprendre une syntaxe complexe tout en offrant une niveau d’efficacité opérationnelle, il s’agit alors d’une question assez difficile. La mauvaise nouvelle est qu'il n'existe actuellement aucun modèle mature qui puisse réellement répondre à de telles exigences. La bonne nouvelle est qu'il n'est pas difficile de réaliser un tel modèle. Si vous essayez Zope ou ColdFusion, vous trouverez l'ombre de ce modèle.
(wact http://wact.sourceforge.net/ et phptal http://phptal.sourceforge.net/ évoluent dans ce sens et devraient être très prometteurs).
Il existe deux manières principales de combiner des modèles et des données (appel de modèle) : la méthode push et la méthode pull.
La façon de pousser consiste à utiliser PHP pour pousser les données vers le modèle, ce qui signifie que le programmeur doit explicitement attribuer une valeur à chaque variable du modèle et les lier.
La méthode d'extraction revient à mélanger PHP et HTML. Les variables du modèle extraient activement les données.
En parlant de modèles, nous devons mentionner deux autres choses :
phphtmllib et quickform ( http://pear.php.net/package/HTML_QuickForm ). Ces deux choses utilisent des méthodes traditionnelles pour compléter le HTML à travers divers composants de la page. La page est entièrement entre les mains du programmeur. Peut-être que de nombreux programmeurs qui ont écrit des programmes de bureau à interface graphique traditionnelle préfèrent cette méthode.
Une plus belle solution
Si vous créez un logiciel commercial, Flash devrait être une plus belle solution (ne vous méprenez pas, ne pensez pas que ce n'est pas parce que PHP prend en charge les bibliothèques Ming et Swaf qu'il peut générer dynamiquement du Flash. Je parle de.) Ce que je veux dire C'est une solution qui prend en charge Flash Remoting. Ce genre de chose est la combinaison vraiment significative de PHP et de Flash. Le concepteur visuel termine la partie flash et le programmeur PHP envoie les données au client en flash via flash remoting.
Il existe actuellement deux solutions :
AMFPHP
Puisque Macromedia Flash Remoting utilise un format de données unique et plus efficace lors de la transmission des données, AMFPHP construit le format de données correspondant côté serveur en analysant le format de données PHP. classe pour recevoir, analyser et encoder ces données pour réaliser la fonction d'échange d'informations (tout comme Samba, cela devrait être une sorte de piratage).
PHPObject
http://ghostwire.com/resources/phpobject/
PHPObject utilise une autre méthode pour transmettre des données via du savon au format ouvert en intégrant certains composants ActionScript dans Flash.
En fait, les modèles PHP posent de nombreux autres problèmes, et je ne peux pas écrire beaucoup de choses en peu de temps.