There has been a lot of talk about how Smarty, a popular template engine for PHP, is bloated and not useful because PHP is already a templating engine and that you’re essentially creating a template engine out of a template engine. As everything I read could just say that it was bloated without backing up their statement, I decided to investigate it myself and see why it’s just like your regular PHP template engine.
Here’s a short snippet of the article.
The popular argument against Smarty is that PHP is already a template engine, so why not just write template files in PHP using the PHP syntax? But, with Smarty, you are effectively doing this; you just don’t know it. When you do
$smarty->display('template.tpl');you are causing the Smarty engine to lookup template.tpl in it’s compiled cache and run that code. Check out your compiled directory in Smarty’ll look like bad formatted PHP code, but that’s because a human is never intended to read it. The important thing is that it’s PHP and that’s what Smarty is executing.
Drop by, give us a read and if you like, share with us your Smarty tricks.
Comments
The argument that Smarty is bloated is not rooted in the assumption that its templating syntax is interpreted at runtime (which it isn't), but in the fact that you have to load the (not too smallish) Smarty base class just to have Smarty lookup the cached version, check for a potential new version of the template, if it exists, compile it an load from cache, if not, just load the cached version. That's the overhead people are complaining about.
Other template engines mostly share the same concerns, it's not just Smarty that works this way. So basically saying Smarty is bloated compared to pure PHP templating is effectively saying: Template engines are bloated.
CU
Markus
Using the PHP is a Template Engine argument, though technically accurate, ignore the benefits of a separate compiler step. With a compiler stage, you can can prevent third party's adding malicious PHP, for example. There are others, from Smarty's modifiers and filters to a template engine's independence from other PHP layers.
Sorry, but I can't see the link to the article. Am I missing something, or is it simply not there?
Thanks.
Sorry, the link got removed as part of the editing process and I forgot to put it back in. It’s back now.
=C=
That PHP can still be embedded into HTML doesn't justify it being called a template engine. Can you use PHP as template language in a blog or a wiki without serious security risks? Can you easily port a "PHP template" into another system? Can you avoid graphic designers from meddling with your business logic using PHP as a template engine?
Seriously, PHP can no longer be used as a template engine, and we don't have the need to, because Smarty works just fine (till someone decides we should all switch to xml+xslt). We now can do some other cool things with PHP, like Web Services, or concentrate on the really important things, like keeping your business logic clean and working.
First you should consider if you need templating at all. Maybe your objects generate by themselves all html needed to render things, or you're sadly prisioner of an old architecture with code inmersed inside html, and SQL inmersed inside code.
If you definitively use a template aproach of things, you sure aren't going to find more functionality in a template language than in PHP. I mean, if Smarty is done in PHP.. you now, it means it can do same things, only that you find a lot of code already made, and prepared for simplicity, so your template file has few lines of code that are self explanatories.
The security separation is an important point, but i think that an evil programmer charged with the task of only preparing templates, is going to find the security holes he/she needs... if he/she belongs to the dark side.
My experience as a manager: is easier for me to find a programmer that knows PHP than Smarty, and has more material to learn how to foreach thouse arrays. But also is my experience that designer (not programmers) doesn't like at all programming languages (or they became instantly programmers in my mind), but are also more open minded at templating engines, and having few documentation to dig could appeal to them, instead of being a problem.
We use some singleton objects, kind of zend_controller, mixed up with some automatic html generation (for creating selects inputs for arrays, and things like that), that look beautifull in sort of a way of templating, but that in true it's fully PHP. I could explain the architecture in further messages if it's of interest.
But in the end, i would buy anytime a template engine that has some "visual designer", that my graphics designer can work with, because they are sensible beings that love beauty and not code. I've tried to open PHP documents in visual HTML designers with some success, but can't relay in them because they tend to eat important code that consider wrong html (damn, they also tend to eat right html).