When we forked Reblog from Feed On Feeds, we were starting with raw-PHP display code mixed in with database calls, and it was a freaking disaster. One of my first design goals was to make it hacker-friendly, clarifying and documenting as many seams as possible so people could make localized changes more easily. I’d like to be using Python under the hood with Smarty on top, though there’s a lot to be said for using commonly-known tools like Smarty in apps where you want to encourage modifications.

And Wordpress…. oh, Wordpress. My eyes roll back in my head when I’m forced to touch its convoluted innards. I pushed hard for a Reblog plug-in API specifically so I could cheerfully deprecate the old-style Wordpress plug-in. =)

And for people who wonder why one would need a template engine: I work with designers and I don’t want them to mingle application code. By setting up a shared folder which contains the templates, they can safely work on design and never need to touch my controller or module files. Especially since this template engine has a tokenizer/compiler, they can’t call unsafe PHP functions (only those that you, the programmer, register).

Perl (not PERL), btw, has the Template Toolkit on the CPAN, which is the spiritual father of Smarty. (And it’s vaguely more defensible in Perl’s case becase Perl is not a template system; though constrated with Perl the deficiencies of TT’s mini language are just all the more painfully obvious.)

By all of which I mean to say that whether people use languages in stupid ways does not mean the language is the problem; not in either PHP’s or Perl’s case.

I also don’t see why you need a templating system to implement caching; in fact, having caching coupled with the template engine sounds like a bad distribution of responsibilities. (Indeed, Template Toolkit has no such facilities.) But there’s the Cache::Cache family of modules on the CPAN, which you can use to cache things completely independently of what is being cached – whether it be the output of a template, or the query results themselves, or anything else, which might not even have anything to do without any output you generate.

Coming from the PERL background and previous php template systems I’ve been very happy with Smarty in general, even if there are a few things that could be done to speed up the learning curve.

May be worthwhile jumping on the dev team and making some suggestions.

The benefits you describe with Smarty would seem to come with any decent web development system. Separating logic and presentation are the general idea behind templating, and some sort of caching is a must no matter what you’re using as a presentation-side tool. My beef is that, out of all the templating systems I’ve used, Smarty is one of the ugliest.

Smarty solves some fantastic problems and the cacheing system is beyond fabulous at this level.

I’ve used Smarty on several projects and have been using it now exclusively for 4 years. Of course, I used others but it was getting sick coming to a new phase in a project and finding out the template system had become RIP….abandoned before their time.

Smarty has done two great things for me, and I’ll speak about them until the day that PHP is abolished:

1. Smarty has reduced my code to a reasonably sized, scan-able, masterpiece. Having the logic and presentation seperate is so nice. I recently rewrote one of my old projects using smarty and all of a sudden it made sense! No more php in the html and no more html in the php. And that’s something you can’t solve without templates for you juniors out there.

2. Smarty’s caching has turned monster db queries into non issues. Consider this. A top 10 list from all-time sales. I’m talking about searching a db with sales spanning 6 years for all items purchased and creating a top sales page. Easy! Smarty does it once and caches the results until I decide they need to be refreshed. Took a 4 second execution time down to less than 0.4 seconds. And all without having to implement a CMS or otherwise. Even if you have limitless resources to buy new hardware, caching like this still makes sense. And the intermediate php/html cache is brilliant. Everything is so much faster with smarty.

I can’t deny, I love Smarty.

Smarty for Dummies?

Just write better code!!!

The only defense seems to be using the tokenizer functions to build a PHP parser that validates templates against a “whitelist” of allowed operations. Savant’s Restricted Compiler is about the only implementation out there, but it’s not quite complete and seems to be more of a proof-of-concept than battle-tested code.

Whatever Smarty’s faults, it solves the untrusted templates problem nicely.