Another Smarty Emigrant

This guyHasin Hayder has finally realized that there’s no need for Smarty’s template language any more (even after writing a book about Smarty).

Harry Fuecks and Brian Lozier made the same conclusion four years ago, and based on those articles, so did I. It turns out that Smarty tries to solve (mostly) the wrong problem

You may have heard that you need to keep your PHP and HTML separated, but that’s not quite the case. Instead, what you need is to keep your "business logic" separate from your "presentation logic", and that’s a different thing entirely.

Thus, all that’s required is a way to keep your views and controllers separated, and perhaps provide helpers for common view tasks. Then you can use plain PHP in your view scripts (templates), without needing a whole new language.

That line of thinking led me to write Savant first in 2004 (and versions 2 and 3 later), along with its more-recent ideological descendants Zend_View and Solar_View. Even the Cake and Symfony guys got the point early on (and — dare I say it? — the Rails crowd as well with eRB templates).

It’s so funny to see the comments in Hasin’s article; all the same old tired arguments come up. Here’s the deal: if you think you need to protect your business logic from your graphic designer, you don’t have a technical problem, you have a hiring/management/training problem.

Update (2008-01-11): Apparently some readers thought “this guy” in the first paragraph meant me; changed it to “Hasin Hayder” to be more explicit. (I’m looking at you, Kimsal.)

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

28 thoughts on “Another Smarty Emigrant

  1. I don’t know if/where this may have been discussed, but it may be worth considering that Smarty could still be a reasonable solution for those wishing to offer design control to customers without allowing them to inject PHP in the design templates. Smarty provides an easy way to solve this. Maybe this is done in better ways, but this article does not seem to address the possibility that a business requirement may exist that designers who are customers must not have access to write arbitrary PHP code. It’s one thing to say that “I have no use for Smarty,” but I think it’s a stretch to assert that no one would ever have a need for it without addressing this use case.

  2. I agree with what you are saying.

    However, I also agree with Lukas, what’s wrong with XSL as a templating langauge.

    I also have another issue I have not got a decent solution to (in my head):

    Suppose I wish to build a CMS. I would like to give users control over their templates through an administration interface. I find it hard to visualise how to programatically manipulate a PHP-based template. Initially I thought I could use a XHTML based template (with special elements) and use DOM to manipulate it, allowing me to give users well defined control over the templates. Any ideas on this?

  3. For when you don’t have to protect your application from designers and you have an intermediary testing platform, you can’t go far wrong with require_once().

  4. There are a few cases a template engine can be useful, ONLY
    – user generated template
    – sandboxed
    – readability

    I am the Author of H2O template engine, a django template port for PHP (compiled, fast), its sole purpose because of above cases. Letting user to know/learn your underlying language is uncool.

    @Daniel Skinner – i ran to similar discussion when i had to open up template in cms, so user can edit them.

    XSLT is a preview place to do presentational logic, however, its verbose syntax, hard to read, did i say its fragile?

    For web application development – View template is the RIGHT thing to do, it uses the same programming language for its construction, however guided by a few simple convention and exploit alternative syntax available in the language. You no longer need the cross language moment, (switch off PHP, switch on Smarty) . If your view template is still ugly, its time to retune your coding style.

    That is exactly What makes Rails ERB, Code Igniter worked. one for output and one for statement. and don’t get me started on the (PHP short open tag ) discussion, it fits naturally in View templates,

    ASP styled, available in Ruby, PHP, ASP


    PHP short open tag


    Django template

    {{ output }} {% statement %}

    for those who argues embedding PHP in a file with (*.xml) extension because its not valid xml, PHP parser shits itself, they have serious problem, PHP is not xml, not even close.

    Kudos for Code igniter, even writing a pre-processor encouraging/supporting usage of alternative syntax (short open tag) even your php configuration said otherwise.

  5. ASP styled, available in Ruby, PHP, ASP
    <%= output > <% statement >

    PHP short open tag
    <?= output ?> <? statement ?>

    Django template

    {{ output }} {% statement %}

  6. I think you are all looking from the developer side at this. Here at my company we have 3 “integrators”, people who are brilliant at HTML and CSS – but all 3 can’t write a single line of PHP. And they’s rip my head off if I told them that they had to learn (even simple) PHP Syntax…

    Don’t get me wrong, I will never use a Smarty template again in my life, I love Zend_View, but that’s a completely different story. Our CMS uses Zend_View in the Backend (coded by the developers) and Smarty in the Frontend (coded by the integrators).

    We tried it the other way round, hired several guys who could code HTML/CSS _and_ PHP and it was a mess. They had knowledge in both sides, but weren’t that good to compete with out other integrators…

    So I think that there IS need for something like Smarty – as long as I don’t have to use it 😉

  7. We might be able to use token_get_all() to create a whitelist for the PHP in templates. It may not protect against infinite loops, parse errors, etc. but could possibly provide some level of safety against accessing arbitrary variables/functions.

  8. I agree with you on most parts, but I have to say there will always be a place for Smarty in cases where PHP is too powerful. For example, if a site uses user designed email for mail campaigns, you don’t want just any user to have all the power of PHP. In this case, a templating language is ideal.

  9. You know, for a long time I was a major proponent of templating engines just because of how clean you could express view output in them without all the coding logic in them. I started first with a port of the phpBB template class, then moved into TemplateLite, a lighter, faster version of Smarty.

    Soon after that I found Savant, and at the time, thought it was terrible (who wants all that PHP in the template?!?!?!) but I began developing more and more for larger scale sites in environments where other developers were contributing, I realized that learning a whole new language just to output PHP using an application that was basically doing what PHP was doing natively made me question the template engine/parser.

    Then I found Solar and looked at how the Solar dev team implemented Solar_View and I fell in love with the flexibility and control you can have in the templates, even when it comes to having non-PHP devs working in the template. Paul and the Solar team have really opened my eyes to how a great application architecture should look and work. And it has totally changed my opinion on template engines.

  10. I whole-heartedly agree with the Author.

    I realized Smarty was a waste of time about 4 years ago too 🙂

    I’ve been using Savant ever since 🙂 and on occasion XSLT

    PHP was birthed as a template language and the template syntax is available to this day:

    eprint($item,’htmlentities’) ?>

    I love it! FYI eprint() is a Savant method

  11. Anybody have a comment on PHPtal? It has a truly unique approach to templating that could be beneficial for Designers and Programmers.

  12. Someone asked here about PHPTAL. I like it a lot. It easily allows the MVC pattern.

    Some people question the value of separating PHP code from HTML, but I think it’s valuable to be able to design views as HTML pages and be able to preview them before the logic is ready to supply data to be merged with the templates. PHPTAL allows that (because it uses HTML element attributes for its instructions). Many other template engines don’t.

    XSLT doesn’t allow that and is too wordy. And it requires that input be XML, which can be an overhead. XSLT would be a better approach if having the code portable across platforms/languages is important.

    • I would agree with this, been using PHPTAL for a few years, never want to go back to embedded php in my interface. Works real nice and sooooo tidy! The guys who ported PHPTAL really did have a goal in mind, I can now separate design from business and interface logic and ensure my sites are maintainable by both php experts and HTML experts, best of both world, rather than a half-baked framework that’s over complicated and average at best.

  13. […] ???? Smarty ???????? Smarty ??????? Smarty ????????????????????????????????????? (?????????? Beyond The Template Engine ????????? ) ?????????????????????????????????????????? Smarty ??????????????????????????????????Smarty "revelations" ? Another Smarty Emigrant […]

Leave a Reply

Your email address will not be published. Required fields are marked *