Je ne comprendrai jamais l'intérêt d'avoir la logique de génération du template en dehors du template lui même, particulièrement tout ce qui concerne les blocs.
L'intérêt d'un template à la base, c'est de séparer complète la logique métier/controleur, de la génération de la vue. Le code métier injecte les données dans la vue, et basta, il n'a pas à se préoccuper de comment va être rendu à la page, de comment vont être utilisé les données dans l'affichage. Il fourni juste les données.
Et le problème, à mon sens, c'est que Hyla Tpl et consort cassent complètement cette logique MVC.
Ainsi, si on veut changer la manière dont le bloc est affiché, il faut à la fois changer le code du template, mais aussi le code controleur qui manipule le template.
Un exemple : on a un template avec un bloc affiché par une boucle. Et on voudrait adapter le template pour faire un traitement particulier pour le premier élément affiché par exemple, ou casser le bloc en deux. Bref, refaire un remaniement. Avec hylat tpl, il faut modifier le template, mais aussi le code php qui manipule le template.
Alors qu'avec un moteur de template comme smarty (que je n'aime pas particulièrement à cause de sa lourdeur et de sa syntaxe, mais c'est un autre problème), où les instructions de boucles sont dans le template. Il y a une vrai séparation entre le code métier et le code de la vue. Si l'intégrateur veut casser son bloc ou autre pour x raisons, il n'a pas à aller fouiller et modifier le code PHP.
# Interet ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau moteur de gabarit : Hyla Tpl. Évalué à 1.
L'intérêt d'un template à la base, c'est de séparer complète la logique métier/controleur, de la génération de la vue. Le code métier injecte les données dans la vue, et basta, il n'a pas à se préoccuper de comment va être rendu à la page, de comment vont être utilisé les données dans l'affichage. Il fourni juste les données.
Et le problème, à mon sens, c'est que Hyla Tpl et consort cassent complètement cette logique MVC.
Ainsi, si on veut changer la manière dont le bloc est affiché, il faut à la fois changer le code du template, mais aussi le code controleur qui manipule le template.
Un exemple : on a un template avec un bloc affiché par une boucle. Et on voudrait adapter le template pour faire un traitement particulier pour le premier élément affiché par exemple, ou casser le bloc en deux. Bref, refaire un remaniement. Avec hylat tpl, il faut modifier le template, mais aussi le code php qui manipule le template.
Alors qu'avec un moteur de template comme smarty (que je n'aime pas particulièrement à cause de sa lourdeur et de sa syntaxe, mais c'est un autre problème), où les instructions de boucles sont dans le template. Il y a une vrai séparation entre le code métier et le code de la vue. Si l'intégrateur veut casser son bloc ou autre pour x raisons, il n'a pas à aller fouiller et modifier le code PHP.