Savant and The Right Reverend Jim

RevJim has a great critique on one of my many posts about Savant vs. Smarty. His analysis is accurate, fair, and open. You really should read the whole thing. In the mean time, here are some highlights of what I want to respond to:

As of a few verisons ago, PHPSavant has a compiled templates option. In the event that your security needs would keep you from allowing template authors direct access to PHP, you can author a PHPSavant template compilation class that will, when activated, convert template markup of your own design into proper PHPSavant template code.

Smarty has the advantage over PHPSavant because the template compiler and, therefore, the language of the template is already written. This means, first and foremost, that I don’t have to write a full-featured, flexible template compiler like I would with PHPSavant. This also means, though this is less important, that users of differnet Smarty based applications can join forces to teach one another and lead by example when it comes to what Smarty is capable of. With PHPSavant, those authoring templates in PHP would be able to help one another. But the users of applications that employed PHPSavant with a template compiler would find themselves in less company.

He concludes, “if PHPSavant were to implement a template compiler that was as featureful as the Smarty template language and provide a means in which to request template compilation only if a template had been changed, Smarty would, unless there are any major speed differences, have no reason to exist whatsoever as PHPSavant would cover the needs of both the ‘pure PHP template junkies’ and the ‘template tag sugar addicts’.”

Jim, please tell me you didn’t try to set me up for this one. 🙂

Such a compiler already exists in basic form as part of the standard Savant2 distribution. It converts a limited markup, and only compiles when the template source has been modified. While not 100% locked down, part of the plan is to add a feature suggested by Joshua Eichorn to have the PHP tokenizer extension pass through the script to make sure only “whitelisted” PHP has been generated.

The markup is as follows:

Markup Action
{$this->var} Prints an assigned variable
{$var} Prints a local variable
{if (…): } Starts an if block
{elseif (…): } Starts an elseif block
{else (…): } Starts an else block
{endif} Ends an if/else/elseif block
{for (…): } Starts a for loop
{endfor} Ends a for loop
{foreach (…): } Starts a foreach loop
{endforeach} Ends a foreach loop
{while (…): } Starts a while loop
{endwhile} Ends a while loop
{[‘pluginName’, $this->arg0, $arg1, ‘arg2’, …]} Activates the plugin named ‘pluginName’ with an argument list
{* … *} comments
{tpl ‘template.tpl.php’} Includes a template

The markup is converted directly to PHP and matches very closely the PHP an author himself would write; the compiled PHP code is very clean and easy to debug.

While this basic example compiler is not as full-featured as the Smarty compiler, any basic functions that are missing can easily be added, if for no other reason than the codebase is much prettier (it adheres to the PEAR standard) and nicely object-oriented. Savant is also a lot lighter than Smarty, so there’s less code to slog through.

Does this mean there’s no reason for Smarty to exist? Certainly not; while I have no use for Smarty, that does not mean there is no use for it period. But the existence of this basic compiler, I think, goes a long way toward satisyfing some of RevJim’s desires regarding a non-Smarty template system.

On a related note, Jim is dead-on about collaborative effort between users of different markups; because Savant does not dictate what compiler you must use, anybody can come up with any kind of markup they want. It would be easy for this to lead to chaos on the compiler front.

However, I see this as a strength, not a weakness. Because the compiler is separated from the core templating system, the “best” or “most useful” compilers can evolve separately from the core template functions. Different communities can write compilers to suit their particular needs, all while using the same core functions and plugin sets. Thus, you get the best of both worlds; a relatively static core package (top-down) that provides an easy, dynamic, and well-defined way to extend and enhance the functions of that package (bottom-up).

UPDATE: See the Savant2_Compiler_basic documentation for more information.

UPDATE: Jim responds! It’s bloggy ping-pong! 🙂

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

2 thoughts on “Savant and The Right Reverend Jim

  1. Something that springs to mind in reading both RevJim’s posting and your own is that perhaps the core Smarty markup could be written for the Savant2 compiler — which would allow those who use Smarty to easily use Savant2. Then, once the stat for template changes has been implemented in Savant2… well, Smarty could live as a compiled language for Savant2.

Leave a Reply

Your email address will not be published. Required fields are marked *