I’ve used the Smarty template engine on a large PHP project for many years now. Back in my younger days (2002 or so) we thought it was great – we could finally get good separation of concerns on our web applications – no more view logic (and lots of echo statements) mixed in with our business logic. Unfortunately, there have been a few bumps in the road since then, and I’ve begun to reconsider Smarty’s usefuless, and whether it even meets its declared goals.
Separation of Concerns
Here’s how the Smarty web site answers the question “Why Use Smarty?“:
One of Smarty’s primary design goals is to facilitate the separation of application code from presentation. Typically, the application code contains the business logic of your application, written and maintained in PHP code. This code is maintained by programmers. The presentation is the way your content is presented to the end user, which is written and maintained in template files. The templates are maintained by template designers.
Well-designed web applications strive to do exactly this – keep the view layer separate from the business logic. In MVC architecture, that would be the V for view and M for model, respectively. You might also include the “C for controller” layer with the business logic part.
Smarty tries to enforce this separation by introducing its own template language. Their argument is that allowing PHP code in the templates will result in all sorts of chaos. Ironically, there’s the {php} tag, which lets you embed PHP in your templates when you “just can’t get around it.” Overall, Smarty has succeeded for us in this regard, but are the gains worth the quirks?
Ease of Use
Smarty claims to shorten the template development process with its easy template syntax that is “not much different than plain HTML.” For example, displaying the value of a variable is about as concise as it gets:
{$variable}
But really, how much harder is it to type this:
<?php echo $variable; ?>
If you have enabled short PHP tags, you can do:
<?= $variable ?>
Having worked in Rails a bit, I tend to like this, which is available if you turn on ASP-style tags in PHP:
<%= $variable %>
Smarty also has variable modifiers, which let you filter the output of a variable through a function first:
{$variable|modifier}
Yes, it’s easy to type, but how much easier than:
<?= modifier($variable) ?>
I suppose the one thing Smarty has going for it here is that the template is more data-oriented, with the variable name coming first, than the function-oriented nature of plain PHP. Hey, but I’m a programmer, right, so calling functions feels natural to me.
Smarty gets a little more sketchy when you want to access the values in an associative array, or call a method on an object. Sure, you can do this:
{$hash_variable.key}
{$object->method()}
The former will work, as long as your associative array has keys that are alphanumeric strings. You’ll get breakage if your keys are numbers, or contain spaces or punctuation characters. The latter works great, but you can’t chain method calls. This won’t work:
{$object->method()->another_method()}
Maintenance
Smarty is a “compiling” template engine, meaning that it transforms templates written in its own Smarty language into PHP code, saving the result out to disk to avoid repeated compilation. This tends to fill up your disk with lots of compiled templates, and you must ensure that you have a folder on your disk that is writable by your web server. Occasionally, I’ll get a PHP Fatal Error in one of the compiled templates, and they’re nearly impossible to read.
Design
Smarty is a hybrid of object-oriented and procedural code. The template parser and compiler is implemented as a class, but Smarty plugins and modifiers are simply PHP functions. I find it handy to keep related custom view code together in a class, but it’s not easy to do with the current design.
Conclusion
Smarty has served well and I’ll likely continue to use it on some ongoing projects, mostly because of the sheer amount of work required to switch to something else. I’m looking into the methods used by other PHP frameworks, like Zend Framework, since they have adopted a PHP-only approach to templating. So far I’m a bit concerned about the baggage that comes along with these full MVC frameworks. For now, I want only the template (“view”) portion.
I have something in the works here, and I’ll write about it later. If you look hard enough, you might find it.
