

PHP's Smarty releases version 3.0 - ecaron
http://groups.google.com/group/smarty-announce/browse_thread/thread/5c28b9e9cdca0b04/bbaf3e2445180bd1?

======
citizenkeys
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.

~~~
toolate
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.

------
jstirrell
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.

~~~
Myrth
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...](http://www.php.net/~derick/meeting-notes.html#remove-support-for-
and-script-language-php-and-add-php-var)

Unless you have a more recent source.

------
ecaron
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.

~~~
byoung2
_given the uprising in 2008 & 2009 against it_

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

~~~
tyrmored
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.

~~~
simonw
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); }

~~~
owyn
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. :)

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

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

------
Jach
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.

~~~
DanHulton
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.

~~~
Jach
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.

------
pornel
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.

------
joelg87
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.

