quels sont les avantages d'utiliser un moteur de modèle

la réponse réside dans le développement de votre application. Pourquoi utilisez-vous un framework au lieu de PHP pur? Pourquoi s'embêter avec la programmation orientée objet quand PHP procédural / droit est plus rapide?

il y a bien sûr de nombreuses raisons et c'est une longue discussion. Le résumé est la facilité d'utilisation et la maintenabilité.

il en va de même pour Volt. Vous pouvez utiliser les modèles de volt pour faire ce qu'il vous faudra beaucoup plus longtemps si vous créez des fichiers PHTML (HTML avec des balises PHP). Les exemples que je peux vous donner sont l'héritage du modèle, les partiels, les calculs dans le modèle (pour/chaque boucle) etc.

en ce qui concerne les performances, il y a toujours un impact sur les performances lors de l'utilisation d'un modèle de moteur. Volt heureusement fait partie de Phalcon donc la performance hit est minime puisque Phalcon fait tout le travail dur en mémoire au lieu d'utiliser des fichiers inclus ici et là pour offrir ses fonctionnalités.

la décision vous appartient. Volt, Smarty, Twig et d'autres sont là pour vous aider dans le développement de votre application. Votre décision est ce qui vous fait utiliser le moteur de modèle ou pas.

C'est une vieille question, mais je veux ajouter quelques idées.

vous avez demandé pourquoi vous devriez utiliser Volt, le moteur de template Phalcon, mais dans votre explication vous voulez savoir, plus généralement, pourquoi vous devriez utiliser un moteur de template. La réponse courte à votre question est: vous utilisez un moteur de template pour éviter de mélanger PHP avec HTML.

Mais je veux répondre à la question principale. Pourquoi Volt? La surcharge de Volt est minimale par rapport à tous les autres modèles de moteurs là et ce n'est pas parce qu'il est écrit en C, mais parce qu'il génère un fichier PHP unique pour votre vue.

la brindille est probablement le moteur de gabarit le plus complet là-bas. Twig a beaucoup plus de caractéristiques que Volt, il est plus stable et plus vieux. Twig, en tout cas, ne génère pas un fichier PHP unique, mais un tas de classes PHP avec des méthodes qui s'appellent les unes les autres. Peu importe si vous utilisez L'Extension C de la brindille, la brindille sera lente de toute façon.

la brindille est vraiment très lente comparé à Volt et même au bon vieux Smarty. Donc, si vous utilisez Phalcon est probablement parce que vous voulez atteindre les meilleures performances, servant beaucoup de demandes de page; dans ce cas Volt est votre ami.

quand L'histoire de PHP commence, c'était standard, que le HTML soit généré directement à l'intérieur des scripts PHP. Mais il arrive de générer certains problèmes quand il est devenu l'un des langages de programmation web les plus populaires jamais.

Pour garder les personnes qui travaillent dans d'énormes projets à l'aise avec leurs tâches ie. lors du développement de services web, où a été inventé un modèle architectural MVC. MModèle est utilisé pour stocker des données et les manipuler dans un maintenable et répétable. V View une partie, qui est responsable de générer une sortie appropriée. C Controller qui sont responsables de l'envoi des commandes aux modèles etc., au cœur de la logique de l'application.

lorsque l'utilisateur envoie une commande à service, le contrôleur la gère et la comprend. Déclencher des changements sur les modèles appropriés et peut-être transmettre des actions à d'autres contrôleurs aussi longtemps que le contrôleur de vue est atteint. Vue contrôleur prend une bonne vue, il injecte dans les données générées et l'exécute pour créer une sortie qui est renvoyé à l'utilisateur. Si template for view n'est pas encore généré, il déclenche template engine pour le faire.

la mise en œuvre correcte de MVC complet aide grandement les programmeurs, les architectes de système, les devs front-end, etc. Mais quand d'un côté il arrive difficile de maintenir des bases de données (ainsi ORM ont été développés), de l'autre côté du système il était difficile de maintenir des vues.

l'Un des les principes de MVC est que la logique (avec un énorme "L") est seulement dans les contrôleurs. Il n'y a donc pas de logique dans les opinions. L'utilisation de moteur de gabarit renforce la facilité de réaliser cela en raison de la mauvaise prise en charge de la logique par eux-mêmes. Ce n'est pas un secret, que les programmeurs sont "paresseux" - donc s'ils ont l'occasion de mettre un peu plus de logique avancée en vue, ils le feraient.

je suppose que tous les dev frontend ont des compétences de programmation. Le problème est de les faire rester avec vous. Travail sur projet énorme, avec beaucoup de les vues (et donc les modèles hudge) avec PHP mélangé dans eux les rendra fous. Il est beaucoup plus facile de lire le code écrit pour le moteur de modèle.

idée de moteurs de modèle est d'ajouter une partie de plus au système, qui offre éventuellement langage simple permettant d'utiliser la logique de base comme des boucles et si consolidés. D'un côté, le moteur de template reçoit une sorte de fichier textuel pour le transformer en fichier PHP avec une dose hyper mélangée de tous les HTML importants.

Si vous êtes seul développeur, il est important pour personne que vous utilisiez des fichiers qui mélangent PHP et HTML. Il semble probablement proche de ceci:

<html>
<head>
    <title><?=$title?></title>
    <? foreach($metas as $meta) { ?>
    <meta name="<?=$meta['name']?>" content="<?=$meta['content']?>"/>
    <? } ?>

mais n'importe quel développeur frontend préférerait travailler sur le fichier en regardant de cette façon:

<html>
<head>
    <title>{{ title }}</title>
    {% for meta in metas %}
        <meta name="{{ meta.name }}" content="{{ meta.content }}" />
    {% endfor %}

pour plus de lisibilité. Il arrive extrêmement pratique lorsque le modèle inclut une sorte de javascript inlined. Après tout, vous vous retrouvez avec le même fichier, vous pouvez créer à la main, mais ce fichier est généré et stocké, il n'est donc pas plus généré tant que le fichier de base n'est pas modifié. Nous générons nos gabarits pendant deploy ce qui a 0 hit sur la performance, surtout maintenant, quand le moteur de Volt est écrit en C.

une autre chose pratique au sujet des moteurs de gabarit est que (avec un peu de votre effort) il est possible de générer des gabarits minimisés à la volée. Vous ne serez jamais minify votre modèle Fabriqué à la main, sauf quand la planification de se suicider.

Donc, globalement, c'est un cas de:

si vous pouviez passer .volt fichiers à un front-end gars

mais c'est un effet de travailler dans le modèle MVC. Et Phalcon est fait pour respecter les principes MVC. Je n'essaye même pas de deviner, comment vous avez réussi à travailler avec ce morceau de logiciel pendant ~2,5 ans sans utiliser le moteur de modèle. Peut-être que vous travaillez seul.

chaque personne a des goûts différents, mais je vous dis ma vision.

je pense que la volt est utile parce que:

• comme tout le cadre de phalcon, Volt a une performance excelente.
• Avantages de moteurs de template (je n'ai pas envie de répéter que déjà d'autres réponses, dit)
• Rendu hiérarchique: plus d'info - > https://docs.phalconphp.com/en/3.0.2/reference/views.html#hierarchical-rendering

j'aime le phalcon le rendu hiérarchique, parce que est propre, facile, et n'importe qui peut comprendre où peut trouver la vue de quelque chose, idéal pour un designer, ou autre personne non technique

et pour ajouter de la valeur, je modifie certaines parties de phalcon pour appliquer ce Rendu hiérarchique en utilisant des modules app, c'est tout ce dont j'ai besoin.