Je vais écrire un CMS, mais je vous écris maintenant toutes mes idées et j'essaie d'obtenir tous mes concepts tout droit avant de commencer. L'une des choses que je suis déchirée est d'utiliser une langue de modèle et d'analyser les pages du site Web et de remplacer les étiquettes de modèle avec des éléments de contenu, ou de développer simplement le site avec PHP droit et que le CMS génère des structures de données qui aident. Par exemple: vs. Le premier est plus propre mais cela impliquerait d'inventer une langue, plus l'analyse de chaque page avant l'affichage. Ce dernier est moins propre mais je pense que cela pourrait fonctionner vraiment si le CMS vient de fournir des données pour tout le code. Mais cela serait-il considéré comme une logique de mélange avec la présentation? Une autre alternative que j'ai envisagée consiste à utiliser des fonctions PHP similaires aux étiquettes de modèle: Quelles sont vos pensées? Gardez à l'esprit que je ne peux pas Il faut faire quelque chose de plus compliqué que comprenant une page à un endroit donné ou écrire une liste non ordonnée; Le reste doit être géré par CSS.
6 Réponses :
Vous voudrez peut-être examiner Smarty- http://smarty.php.net Smarty est un très Moteur de modèle puissant qui vous donne le meilleur des deux mondes. Il a une prise en charge intensive pour les modules personnalisés et les plugins.
J'ai construit un CMS personnalisé avec Smarty et PHP et n'ai que de bonnes choses à dire à ce sujet.
Le code PHP à utiliser Smarty ressemble à ceci < / p> Le code de modèle est quelque chose comme ceci
Je recommanderais Dwoo [Dwoo.org] sur Smarty. A la plupart des caractéristiques de Smarty sans le gonfleur.
+1 J'ai utilisé Smarty pour un certain nombre de projets, bien qu'il y ait il y a quelque temps, il y a donc d'autres moteurs pour vérifier également (Dwoo, comme mentionné Mitmaro, par exemple). La préoccupation primordiale avec les langues de modèle, dans mon expérience, est de garder la logique commerciale de se faufiler. Cela signifie généralement un peu de travail supplémentaire pour vous assurer que seules les informations que vous souhaitez afficher sont fournies au modèle, laissant uniquement la structure de formatage et d'affichage dans le code de modèle.
J'étais un très heureux utilisateur Smarty depuis longtemps, je ne crois plus en des langues spécialisées de modèle.
Un modèle de modèle ne vous empêchera pas de mettre une logique inappropriée dans votre code de présentation, cela vous obligera à écrire un mauvais code dans la langue du modèle.
Il est assez trivial de rouler votre propre système de modèles qui utilise PHP dans les modèles. Créez ensuite différents aides pour conserver votre code de modèle propre (comme votre «Fonction de navigation ()»).
Je pense que l'approche prise par Zend_View est plutôt bonne. Les trucs de la couche de vue de Symfony sont assez soignés aussi, mais pourraient être un peu intimidant. Vous n'avez pas à utiliser un cadre pour en obtenir quelque chose. Il suffit de regarder une partie du code de modèle dans les exemples et de voir ce qui vous inspire.
Bottom Line: oubliez une langue spéciale pour les modèles - Appliquez simplement un bon sens de conception à votre code d'affichage, en facilitant la complexité des scripts de vue et dans des assistres réutilisables.
Modèle Langues pour PHP sont un exemple d'anti-motif appelé " effet interne-plate-forme . " Smarty est un exemple de structure de modèle pour PHP, mais même Hasin Hayder, auteur d'un livre sur Smarty indique que Smarty est mort et il n'y a plus besoin de l'utiliser plus.
Il peut y avoir de bonnes raisons de développer une langue de modèle, par exemple si vous utilisez des concepteurs non codeurs ou des éditeurs de contenu utilisant votre CMS et que vous ne voulez pas les submerger avec la complexité de PHP (ou laissez-les écrire code qui pourrait casser votre site Web).
Mais vous n'avez pas décrit cela comme objectif, je suppose donc utiliser PHP lorsque votre langage de modèle de page est le mieux dans ce cas. Ce sera moins de travail car vous n'avez pas à développer votre propre nouvelle langue, et cela fournira une plus grande flexibilité pour les cas peu communs où vous avez besoin d'un type de contenu dynamique spécifique.
Ne pas écrire des fonctions PHP pour encapsuler des blocs de sortie HTML. Au lieu de cela, utilisez Vous pouvez également utiliser un cadre MVC tel que Symfony, Kohana, Solar, CodeChIriter ou Zend Cadre pour vous aider à conserver la discipline de la séparation de votre code de modèle PHP du reste de votre code d'application. inclure () pour tirer dans des fragments de HTML. Cette technique est parfois appelée "partielles".
Je le construis sur Cadedigniter. De plus, si certaines parties du HTML doivent être spécifiées dans le PHP? Pour la sortie d'une liste (comme dans mon exemple), je pensais que l'utilisation de l'inclut serait inutile. Pas besoin d'écrire une "navigation individuelle-navigation.html" et l'inclure, non? Quant aux pages, celles ne seront pas générées à la volée.
Mon point est que je garde tout HTML dans des fichiers de modèle, alors que j'écris des fonctions PHP (comme l'exemple Navigation () Vous mentionnez) uniquement pour fournir des données au modèle. N'étressez jamais des balises HTML sans écho même dans le modèle. Drop de Block lorsque vous souhaitez des balises HTML littérales.
Je pensais juste que c'était plus propre d'écrire que d'écrire
@Carson: Bien sûr, bon point, je suis d'accord. Néanmoins, j'essaie en général de minimiser "Echo" de balises HTML complètes.
Juste curieux si vous ressentez toujours la même chose à propos de la modélisation.
@Johnny, je n'ai pas fait de codage de présentation Web ces dernières années, je peux donc être obsolète en ce qui concerne les dernières nouvelles bibliothèques de modèles. Mais je suppose que les mêmes idées s'appliquent toujours: L'utilisation d'un moteur de modèle peut être pratique pendant le développement. Mais en termes d'efficacité d'exécution, je ne vois pas comment cela pourrait être meilleur que d'utiliser PHP en plaine.
La réinventer la roue est la plupart du temps une mauvaise idée.
php est déjà une langue de modèles. Vous n'avez pas besoin de mettre en œuvre votre propre.
Quant à Smarty, c'est le système de modèles le plus complet pour PHP et c'est toujours une mauvaise idée.
Quelques articles sur le sujet:
une fois Un temps il y avait Smarty! par Hasin Hayder. Il a effectivement écrit un livre sur Smarty et il ne le recommande pas.
PHP et modèles par Harry Fuecks (auteur de la 1ère édition de l'anthologie PHP)
Si vous voulez regarder les modèles L'objectif final est bien sûr d'avoir un code plus facile à maintenir en favorisant la séparation
Je me demande pourquoi noone a mentionné quelle est l'une des utilisations les plus importantes d'une langue de modèle: une sortie automatique s'échappant.
Il est facile d'oublier un htmlspecialchars () ici ou là, donc une langue de modèle qui fournit des directives telles que {$ nom} doit s'assurer que le nom de $ est automatiquement transmis via HTMLSpecialCalchars, avec le charert approprié et tout.
Bien sûr, cela implique également que vous puissiez spécifier un "contexte" différent pour une sortie variable, tels que par exemple. alerte ('salut {$ nom | contexte = singlequotes}!'); où l'interprète de modèle échapperait au contenu de NOMT afin qu'il soit impossible de sortir des guillemets simples, au lieu de XML l'échappant (qui devrait être la valeur par défaut).
De tels contextes peuvent également inclure des éléments tels que INT (pour forcer un numéro), et il peut également être étendu à accepter des paramètres supplémentaires pour formater la sortie, etc.
Mes 2 cents. Je ne sais pas s'il y a une solution open source qui le permet (serait intéressée d'en entendre parler!), J'ai roulé mon propre interprète pour ces affaires au travail. Puisque le "code intermédiaire" résultant est PHP pur, il peut également être très facilement "mis en cache" (comme Smarty et d'autres systèmes TPL et d'autres systèmes TPL).
C'est un bon point que je n'avais pas envisagé auparavant. Mais cela ne pourrait-il pas être fait aussi facilement avec des fonctions PHP au lieu des tags de modèle?
Oui, mais le point est qu'il est facile d'oublier d'appeler HTMLSpecialchars () ou d'échapper à des citations dans un bloc
À peu près sûr que cela a été posé à plusieurs reprises auparavant.
DUP: Stackoverflow.com/Questtions/731743/PHP-VS-Template-Engine Stackoverflow.com/questions/436014 / ... Stackoverflow.com/Questtions/62605/...