PHP's Smarty releases version 3.0 | Hacker News Reader

PHP's Smarty releases version 3.0

groups.google.com

13 pointsecaron22 comments

I. HATE. PHP. TEMPLATING. ENGINES.

Back when php was relatively new (2002 - 2003), our company hired a few php developers to build several ecommerce solutions. They swore up and down at the time that smarty and pear would get the job done faster and better.

Long story short, after implementing the solution rather quickly we spent more money deleting giant gobs of lame templating code and re-writing the rest of code in very lean php than we did on the original project.

Never again will I use any templating engine on top of a scripting language. It's actually a written core requirement for any new project I contract ("no lame templating engines").

Templating junk can also make it more difficult to get lean standards-compliant html that you need for reliable javascript behavior.

Don't use templating to junk up your code. You've been warned.

There are lots of "find'n'replace" template engines which really suck.

But have a look at http://PHPTAL.org — its attribute-only syntax not only preserves structure of HTML well, but PHPTAL actually parses XHTML and enforces its well-formedness (i.e. you can't produce HTML with misnested or unclosed tags).

I've found that the quality of a PHP project tends to be fairly independant of whether it uses a templating library.

One benefit of Smarty is that it forces at least some seperation of business and display logic. People will still try and shove business logic into the templates, but at least you know you're not going to find SQL statements halfway though the rendering of a table.

I've used smarty (version 3 RC) for a recent project and I have to say I'm very pleased with it. Short tags are bad. They are going to be deprecated in PHP6, and they senselessly take away a little of your application's compatibility across all servers.

I don't understand all the hate against Smarty. How would the "PHP is already a templating language" argument explain the rise of all these PHP frameworks we have no, almost all of which contain some means of templating.

Smarty allows me to not have to worry about boring presentation layer crap (ie htmlentities) without having to commit to a large framework. Plus its syntax is pretty nice.

Short tags are not going to be deprecated in PHP6, it's been settled long time ago.

http://www.php.net/~derick/meeting-notes.html#remove-support...

Unless you have a more recent source.

Granted Smarty certainly isn't anyone's poster-child of internet-awesomeness (looking at you, XHP), and given the uprising in 2008 & 2009 against it the project's taken a few hits, but 3.0 really shows that some of PHP's core is learning lessons and that projects of the past don't always have to go the way of the dinosaur.

given the uprising in 2008 & 2009 against it

Could you elaborate? What happened to Smarty during those years?

Among PHP developers, the idea that "PHP is already a templating language" became pretty much memetic. I use an older version of this engine in my work and never really bought into actively hating Smarty, although I stopped using it for my own projects.

One of the core arguments against it, I think, was PHP developers suddenly remembering short tags and alternative syntaxes for control structures (if, foreach) that made working with templates in straight PHP just as easy, much more flexible, and shaving a few milliseconds off load times -- it's a sizeable library to load.

I've always thought that the problem with that viewpoint is that PHP is actually a pretty bad templating language.

    <?php echo htmlentities($name); ?>

In Django templates:

    {{ name }}

Things get a bit better if you write your own "h" function:

    function h($var) { echo htmlentities($var); }

The htmlentities issue isn't anything a little upstream logic couldn't fix; just the same as Django's templating engine does.

<?= $name ?> is my preferred method of printing inline, which shortens it up quite a bit.

Mine, too, although I usually do my escaping/encoding in the template itself, so it becomes:

  <?= h($name) ?>

Which isn't that terrible.

The PHP developers don't make this easy though, as "short tags" are officially recommended to be disabled, so to write portable PHP you'd have to do

  <?php= h($name) ?>

Every time, which adds visual noise that gets worse the more tags you write.

I am not here to defend php (Okay, I guess I am...) but the form

<?= htmlentities($name) ?> is a lot better...

We have to have an i18n layer anyway for all output so it ends up being a lot of <?= Msg('message-name') ?> calls. Use some code gen macros and it's tolerable.

Also, XHP seems pretty rad. It gives me ideas. :)

`htmlentities()` defaults to ISO-8859-1 encoding, so the short form is useless in practice, and you need:

    <?= htmlentities($name, ENT_QUOTES, 'UTF-8'); ?>

Adding an extra layer of abstraction to have somewhat nicer looking source code doesn't seem worth it though.

I definitely agree. Especially when I'm passing my code to designers who are scared of code.

Giving them a template file with something like {$CustomerFirstName}. Which they can then move around without fear of breaking the page makes sense.

And let's be honest there aren't that many websites in the world which have to really worry about the performance implications of using smarty.

I'm with you there...I like that Smarty covers up some of PHP's quirks, like htmlentities($var) vs urlencode($var) becoming {$var|escape:'html'} and {$var|escape:'url'} respectively.

There are also nice little shortcuts in Smarty, like wrapping templates in {strip}{/strip} to strip newlines and whitespace which would be tricky in PHP without using output buffering.

Not only that, it was also that Smarty2 is PHP4 code, and in recent years anyone reasonable moved to PHP5 and its' reacher OOP features - you still could use Smarty there but a) it could produce some technical problems B) it was totally not cool. In the meantime some other template engines were made (e.g. Dwoo or Twig) and they were better written, probably faster and have some great, new features (template extending). What further undermined Smarty's position was that php.net stopped to support the project (though I don't remember when it had happened exactly, might be well before 2008).

But aside of all of that, the 3rd version of Smarty puts it back on the right track.

Call me insane, but I actually like using the Heredoc syntax in my own PHP templates. The client loads a page, it passes through index.php to determine a class to create, a function is determined to be called, function may display a template (or may be a simple json-getter/poster) in which case I load up some options (like what template, vars to pass, etc.), send them to a function which displays the template and I'm done. Inside the .tpl file, I might have something like:

    <?php
    foreach ($users as $user) {
      $userinput = htmlentities($user['userinput']);
      echo <<<EOD
    <div>
      ID: {$user['id']} <br />
      Name: {$user['user_name']} <br />
      Input: $userinput
    </div>

    EOD;
    }
    ?>

I've used Smarty in the past though, and I didn't mind it.

I prefer something a little more like:

  <? foreach ($users as $user): ?>
    <div>
      ID: <?=$user['id']?> <br />
      Name: <?=$user['user_name']?> <br />
      Input: <?=htmlentities($user['userinput'])?> <br />
    </div>
  <? endforeach; ?>

That said, I know I'm INSTANTLY going to piss off the "NEVER USE SHORT TAGS EVER" camp, but if it's on a server I control (which is 99% of the time), or I can modify PHP init settings via .htaccess or ini_set (which is the other 1% of the time), it literally doesn't matter.

The main takeaway is the alternate control structure (foreach: endforeach; instead of foreach {}). I find that way cleaner than heredocs.

Well, you could use USERS_FOREACH as your delimiter instead of EOD... I don't mind the short tags (and agree you should be able to enable/disable them in almost all cases) but just don't find them worth it, what I do dislike is the abundance of angle brackets and question marks and calling a function at the moment of output. (It just looks odd, and when people use their own h() function it just muddies the water. I liked Smarty for removing this.)

I think PHP and Perl got it right when they allowed embedding of normal vars in strings without any special syntax thanks to the $ sigil, we should take advantage of it where possible. When you have a bunch of non-PHP I think it makes sense to drop out into normal HTML, but otherwise, PHP strings are fine and your editor should support syntaxifying them as HTML.

It's good that it finally has option to escape all variables. IMHO this should be enabled by default.

Most PHP programmers say that it's not a big deal, as one can simply insert `h()` in every echo… but when I review PHP code, I find XSS everywhere. You can't just rely on self-discipline. It doesn't work.

I must say, I've gone back and forth with templating engines for PHP. I've never really bought it, but I do like the experience I had with haml in Ruby.

Recently, I really like the look of Moustache Logic-less templates - http://mustache.github.com/ - yet to try it though.

Reply on news.ycombinator.com