Beyond The Template Engine

This is a dedicated thread for discussing the SitePoint article ‘Beyond The Template Engine

Nice Article,

shows how simple is always beautiful. Of course you could get rid of that nasty <?=$abc ?> syntax by using eval() for the fetch method. But that is a matter of taste I guess. The important thing is, like you say, “separate your business logic from your presentation logic”

While I appreciate the article, the problem still remains, trying to keep the HTML and php logic together in the presentation does not work unless you are a graphic designer AND php programmer. Once again another template related article fails to bring up pure CSS/XHTML as the obvious solution. eg… see for an example

Please tell me how using eval() could remove the “nasty” syntax.

It would be possible to use eval() to do this. However, the eval() statement would replace only the include() statement. It’s just a matter of convenience. If you’re loading a template from a file, you can use include(). If you’re loading a template from a string variable (for example, after pulling it from a database), then you could use eval().

It’s a good article, and it makes some good points about the usefulness of some popular templating systems, including the point that PHP itself makes a good template system, eliminating the need to learn another syntax.


you could read:

I liked this article a lot, specially since it gives me good hope of creating a nice template system without learning another language, just a smart way of using PHP. I still have to learn classes though, but was gonna anyway hehe.

Thank you… You explained why Smarty and the other templates are so hard to sort out. Your artical was written so that I could understand the process.
Thanks so very much…

Why smarty and not php code in the template? Well, smarty is easier for people that don’t know how to program php, smarty compiled templates have the php extension (thus are cachable by an accelarator), you control exactly what functions designers have access to, and in html editors and browsers the smarty tags look better than php ones. All of this for a small overhead…

Excellent article… Ready for my collection of utils…

I have been playing around with your template class. It seems to work as expected for your basic variable interpolation, however, I can’t seem to figure out how to go about seperation when more than variable interpolation is required. Would it be possible to get an example of using a basic for loop with this template class?

Or if anyone else out there is using it, could you provide an example? :slight_smile:

on a side note, anyone else have problems getting the printable version of that article to pint from firebird?

Warning: Unknown(/Users/moo/Sites/template/examples/caching.php): failed to open stream: Permission denied in Unknown on line 0

Warning: (null)(): Failed opening ‘/Users/moo/Sites//template/examples/caching.php’ for inclusion (include_path=‘.:/Library/PHP4/lib/php’) in Unknown on line 0

I get that on all files, even the user_list one, and I can’t make any sense of it :confused:

What about caching If I want to have a template inside another one?

Should I do like this:


$path = './templates/';

$file = 'list.tpl.php';

$cache_id = $file . $_SERVER['REQUEST_URI'];
$tpl = & new CachedTemplate($path, $cache_id, 900);
$body = & new CachedTemplate($path, $cache_id, 900);

if(!($tpl->is_cached())) {
   $tpl->set('title', 'My Title');
   $tpl->set('intro', 'The intro paragraph.');
   $tpl->set('list', array('cat', 'dog', 'mouse'));

if(!($body->is_cached())) {
   $body->set('user_list', fetch_user_list());

$tpl->set('body', $body->fetch('user_list.tpl.php'));

echo $tpl->fetch_cache($file);

If you want to use php as a templating system by imbedding php directives in html then it doesn’t get any easier than Harry’s AwesomeTemplateEngine at


nice :wink: But why is my code not working? when i go this page all i get is the user_list.tpl.php not the list.tpl.php =/

I like this article, especially the comments about extra layers of templating structure delivering little new functionality but lots of new complexity.

However, I would go a step further and question the value of even this limited “Template Class”. It seems that all it really adds to plain old php is caching.

But why do we need caching anyway? Isn’t the need for caching just a sympto m of the same structure bloat that template engines are guilty of?

Over-layering causes the performance problems which caching solves by yet more layering!

In any case, caching is increasingly useless for sophisticated e-commerce, where the content of any page needs customisation on the basis of the immediate request history of the viewer.

And, at least in my experience, final performance for the end-user seems to be always limited by retrieval of third-party external content i.e. advertisements, referal counters etc.

I would argue that plain old php, (a templating technology right from the start), is the best tool. It just needs further development e.g.
a) Security: dynamic control over available php commands.
b) Partial includes: include of a file section and not just the whole file
c) Macros: dynamic recursive code snippets.

Unfortunately all of these are made impossible by the concentration on a high-performance parser, (Zend), to cope with over-structured code! Personally I would rather have more functionality and less unnecessary performance.

This is a terrific article, that does a pretty good job of explaining why template engines generally do the wrong things, and so are a bad idea.

The need for templates comes from the need to reconcile two opposed positions:

1- Site performance is dependent on: bandwidth, disk i/o, memory, and mips (in roughly this order).

2- Development performance is dependent on: abstraction, expression, composition. (All of which are increased by expending more disk i/o, allocating more memory, or using more mips.)

Instead of saying ‘img src=“path/foo”’ it’s easier for me to write and call a function “show_image(foo)”.

I then build up to

show_image_palette(foo, bar, baz)

and from there to


and from there to


Every time I increase the distance between the developer and the HTML, I improve the performance of my “development engine” – more expression per byte written.

But doing so in “pure php” comes at the cost of burning mips and memory and disk i/o to pull in all the classes and templates and who-knows-what needed to translage




The solution, of course, is to use “software judo” to put abstraction and expression to work on the whole mips/bandwidth expenditure issue.

The best answer to date is of course the one proposed in the article:

1- Provide an abstract interface to the separation of business from presentation logic. Partitioning the code into “business parts” and “display parts” is a good idea, regardless of what languages are used for either part. (You could get away with a big horizontal line in your source code, if it comes to that:

#----------- HERE BE PRESENTATION ----

2- Develop a caching mechanism so that abstract code like page_header(…) only has to be converted to html once.

Someone made the comment that caching was just covering up inefficiency. This is untrue. Caching is to PHP what compilation is to ‘C++’. PHP doesn’t get compiled to binary code, despite what the Zend wonks tell you. PHP is compiled to HTML, every time the user clicks the mouse. THAT is the ultimate output, so that’s where the highest benefit is derived.

To restate: This is a fine article, and a nice start at recognizing the ‘real’ requirements for a templating system. Kudos!


Caching is useful for intranet projects, i.e. large (1MB) reports. Without caching, that adds LOTS of overhead to your SQL engine.