Live data from Hacker News

PHP's Smarty releases version 3.0

groups.google.com

11–20 of 23 posts

Re: PHP's Smarty releases version 3.0

#11
post #5
post #4

Earlier quoted context omitted.

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 m…

I've always thought that the problem with that viewpoint is that PHP is actually a pretty bad templating language. In Django templates: {{ name }} Things get a bit better if you write your own "h" function: function h($var) { echo htmlentities($var); }

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.

Re: PHP's Smarty releases version 3.0

#13
post #4
post #3

Earlier quoted context omitted.

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 m…

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.

Re: PHP's Smarty releases version 3.0

#14
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.

Re: PHP's Smarty releases version 3.0

#15
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.

Re: PHP's Smarty releases version 3.0

#16

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 i…

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

Re: PHP's Smarty releases version 3.0

#17

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 i…

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.

Re: PHP's Smarty releases version 3.0

#18
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:

    
      ID: {$user['id']} 
      Name: {$user['user_name']} 
      Input: $userinput
    

    EOD;
    }
    ?>
I've used Smarty in the past though, and I didn't mind it.

Re: PHP's Smarty releases version 3.0

#19
post #18

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…

I prefer something a little more like:

  
    
      ID:  
      Name:  
      Input:  
    
  
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.

Re: PHP's Smarty releases version 3.0

#20
post #18

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…

I prefer something a little more like: ID: Name: Input: 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 for…

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.

Post reply on HN