[sbarre]

I would actually argue that using PHP as the templating language in a PHP MVC application has become the majority use case.

Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?

There are cases where you may need to do this (if you can't "trust" the templates for example and you need to enforce some kind of validations or restrictions on them) but otherwise you just need to follow/enforce business rules about what can go in your views, and just use plain ol' PHP..

[Kudos]

> Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?

From past experience: to stop shittier developers at your company putting controller logic in the templates. Using something that does nothing but templating ensures that your templates do nothing but present data.

[sbarre]

I addressed that in my post actually. If you have shitty developers in your company who can't follow business rules, PHP isn't your problem.

[Joeboy]

I actually agree with you. It's been a while since I used PHP much, but the last time I did some work in, erm, I think it was Symfony, I remember thinking that PHP was pretty nice for the template layer. That may partly be because I'd got used to Django, which had an aggressively simplistic template layer at the time.

Edit: By which I mean, Symfony improves things by working around PHP's suboptimal default.

[krapp]

With templating systems which 'compile' templates down to php anyway, that might be a distinction without a difference.

[sbarre]

Fair enough. I know Smarty does this and caches the PHP-ized version.

I guess the difference could come from how efficient the template-to-PHP compilation is, but I bet you're right and it's trivial in most cases.

[krapp]

Twig too, and you can sandbox functions and auto-escape data. To me, using templates is more or less the same as using a framework with PHP -- it does add overhead and you could get by with, say, plain PHP and having urls point directly to resources but sometimes I think the benefits of that extra abstraction, even if it is a bit recursive, outweigh the potential costs of not having logical buffers between a request and its execution. An app that's too dumb can come back to bite you just as hard as one that's too clever by half.

Blade (used by Laravel) seems to be more along the lines of "bare PHP/bind to PDO object" but I haven't studied it too hard because i'm such a twig fanboy.