I bungled the Savant 2.3.0 release (c.f. how overload() and __call() bit me in ass on PHP 4), but with the kind forbearance of its users, Savant 2.3.1 will make up for that fouled release. Here are the change notes:

* PHP5 Only: Supports __call overloading as an alias to plugin(). No support for overloading in PHP 4; sorry.

* The form plugin no longer generates layout for hidden elements (thanks Alain Petignat)

* Fixed two errors in the Exception error handler (thanks Jeff Surgeson)

* Fixed trimwhitespace filter to handle preformatted blocks with attributes in the tag (thanks Alain Petignat)

Savant is a template system for PHP that uses PHP itself as the template markup language. Savant has plugins, output filters, customized error handling, and allows you to hook in a compiler object to deal with customized non-PHP template markup. I call it the simple, elegant, and powerful alternative to Smarty.

Speaking of which, John Coggeshall used to think that something like Smarty would be a bad idea (see his comments from 2000, on a PHP3 list, here.

The differences between how I work now and how you propose work be done in the future is staggering -- you are asking me to let a designer that I don't trust to write basic HTML to write advanced control loops and logic blocks using a top-end system which converts this pseudo-language into PHP and THEN processes the PHP Code... FINALLY outputting the page to the user... assuming that designer wrote his code right AND the top-level parsing engine actually parsed it correctly.

(As a side-note, I strongly suggest reading the whole thread, which is about whether or not to embed a template system within PHP, and what the markup should be like. There are arguments for and against PHP-based markup -- the "two languages" and "mini-language" points come up multiple times. There are predictions that the new template language would quickly overlap with PHP and make it necessary for developers to know two languages, the real PHP code and the pseudo-PHP template markup code, for no reason other than to call one of them a "template." Zeev Suraski in particular appears to be clairvoyant on these points.)

This was 2000, of course, and at the height of the dot-com bubble, where anyone who could spell "HTML" was counted as an expert. PHP did not then enjoy the widespread acceptance it does now, so it is easy to understand why Coggeshall was unwilling to let a designer have anything to do with "real code."

Coggeshall recently followed up on that post with new comments here, in which he says he needs to eat his own words, although he doesn't really say why (John, if you're reading, I'd be very happy to hear the specifics :-).

Man, considering I've given Numerous Talks on Smarty, am the author of IntSmarty, and this very web site is completely Smarty-powered, this posting is clearly a case of me shoving my foot deep down my throat. In my defense, it was written 4 years ago.... and I do still agree that there are circumstances when Smarty doesn't make any sense... but still -- well, needless to say its quite funny to read that posting now. Since it's out there, I figure I'd bring it to light myself and laugh before someone else beat me to the punch

So I'll say it, everyone mark it down in your calendars -- I was dead nuts wrong.

Coggeshall's contributions to the PHP world notwithstanding, I would say his conclusion was right in 2000, if for different reasons in 2004. In contrast to John, I believe there is only one reason to even think about using Smarty (or a similar system) and that reason is not exactly all-encompassing. More on that in a moment.

First, here is my foundational question: Why would you have one interpreted language act as the interpreter/compiler for another language just to convert it into the first language? Regardless of whether or not you cache the compiled result (*) like Smarty does, using PHP to "compile" a template into PHP makes no sense to me; if it's going to be converted to PHP anyway, you might as well just use PHP as the markup language to begin with instead of some other markup. Using PHP itself means less to learn, less to debug, more powerful functions, cleaner code, forwards compatibility, and so on. This is how Savant works: you get all the power of model-view separation by using the Savant object to interface with a template script, but the template script itself is in PHP, and that template script can use the Savant plugins for custom tasks (such as generating a form).

For me, there is one reason, and one reason only, to "compile" templates: if the template author is a security risk. I don't mean, "the on-staff template designer can't be trusted to use PHP properly" -- if you are in that position, you have a management and training issue, maybe a personnel issue, and not a template system issue. Frankly, if a designer can learn the complex Smarty loop and section markup, that designer can learn minimalist PHP.

No, I mean if the author is an actual security risk; say, if your application allows its users to edit templates via a web form. Then, and only then, is compiling or converting a limited markup to full PHP a reasonable option. Fortunately, Savant allows for this as well; you can hook in a compiler object to convert markup to PHP. Savant comes with an simple compiler as an example implementation.

None of the above commentary applies to XML/XSLT templating because I know exactly squat about that methodology. Having said that, I am happy to be the malcontent noodge in the PHP templating world, and look forward to hearing you tell me why I am wrong, be it in your own blog (remember to trackback!) or in the comments below. Happy templating, all. :-)

--

(*) Yes, I know that the Smarty folks don't call it a "cache" -- but the fact remains that they store the compiled template on disk for faster future access. That sure sounds like a cache to me. They refer to it as distinct from their "output cache" but that's another issue -- why use a template-system cache that is separate from the rest of your application? Again, makes no sense to me; caching seems more like an application-level task, not a template-system task.

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