And that was fine to start with, but pretty soon your scripts were getting bigger and bigger, with all sorts of if{}else madness going on, and with all that HTML in there, you had no idea what was happening.
=====Enter Template Engine=====
Then one day, while trawling the many PHP sites, you came across something about templating. Reading further you though "Wow! A way to put all that irritating HTML in a seperate place so I can concentrate on the code!". Of course the article told you that the only way to do this right was to place special tags in the HTML files - call them templates, which yout PHP code would use replace with the contents of variables.
=====Back to If/Else=====
So all was fine and you were off again, hacking away until you needed to put the contents of a database query into a table. Hmmm... think that template needs a way to specify which HTML needs to be used for the loop that pulls the rows out of the query. Then you had further difficulties with some HTML in a template that you only wanted to appear under certain circumstances so had to add some more template markup for if{}else conditions. Hey and why not throw in some kind of switch{} while you're at it?
Pretty soon you've written your own programming language, while wondering why your PHP scripts are getting horribly slow.
My point of view is that everything any templating system can do, you can do far better with PHP and [[http://www.php.net/manual/en/function.include.php|include]]() or [[http://www.php.net/manual/en/function.eval.php|eval]](). The only //possible// exception is for those people using offering "Home Page Hosting" where users get to modify template files without having the power of PHP at their finger tips. And even for that rare circumstance, you should still consider [[http://www.php.net/manual/en/features.safe-mode.php|PHP's Safe Mode]] to a localized directory, perhaps with aide of .htaccess files (note Safe Mode even allows you to disable PHP functions by name, note also with PHP 4.3.0 it should be possible to control Safe mode by virtual host and directory, by configuring Apache).
=====The Deadly Sins of Templating=====
It's time to expose the //Deadly Sins of Templating// and show why projects such as [[http://smarty.php.net/|Smarty]] and [[http://www.php-tools.de/site.php?file=patTemplateOverview.xml|patTemplate]] have completely lost the plot.
===="PHP is too complicated for web designers. They just want HTML!".====
Now first let's look at the [[http://smarty.php.net/manual/en/|documentation for Smarty]]. A glance will tell you it's far from simple. In fact if you look under the heading "Smarty for Template Designers", one of the first things you'll find is "functions"! Are they insane? Here's an example of how this is used in Smarty;
{config_load file="colors.conf"}
{include file="header.tpl"}
{if $name eq "Fred"}
You are not allowed here
{else}
Welcome, {$name}!
{/if}
{include file="footer.tpl"}
Notice first of all that the markup used "{tag}" is not XML or HTML compliant - those will show up in HTML documents if they are not parsed by PHP correctly. But your good old PHP syntax doesn't do that;
The PHP open and close tags are HTML-like, so if a browser sees them, it will ignore them.
Also ask yourself, "How many GUI editors, of the type commonly used by web designers, will support the Smarty syntax?". Using PHAkt you can use PHP with Macromedia's Dreamweaver MX, a popular tool amongst web designers.
All that templates do is make PHP coders feel superior to web designers. Walk them through a few sections of the PHP Language Reference and show them how PHP's control structures and simple functions like echo() works and that's all they need. You found PHP easy to learn didn't you? I'm sure they will too.
===="It seperates code from content!".====
Well actually no it doesn't. If you build any kind of interactive software application, at some level code **has** to interact with content. What templating in general does is make your code easier to read. But the code is not completely seperated from the content. It still needs to know where it can be found and needs some kind of map (commonly an array) to identify the template tags to replace. Meanwhile, on the template side of the fence, you have to start putting in markup to handle loops, conditions and a whole load of other stuff which puts code right back into the content. Just not PHP code.
I agree that if you mix PHP with the end result, be it HTML or whatever, you'll end up with a mess. It may sound like I'm being pendantic here, but what's important is that a common extensions of the "Seperates code from content" is "It makes my application N-Tiered". N-Tier application design is a big subject which I'll have to point you at [[http://www.sitepointforums.com/showthread.php?s=&postid=559800|this discussion]], if you want a starting point. Templates could be used as part of an N-Tier design but simply building templates into your PHP application
===="You can cache your templates to improve performance!"====
But if you hadn't chosen to write your own programming language and built an interpreter with PHP to parse it, you wouldn't have slowed down your application in the first place!
There are circumstances where caching can be helpful, such as when you use PHP's Object Orientation to build up page that won't change very often. In such circumstances, you might consider caching the end result; the HTML or whatever, and display that directly the next time the page is requested, rather than rebuilding the entire page.
Check out PHP's native [[http://www.php.net/manual/en/ref.outcontrol.php|Output Buffering]] features. We can incrementally buffer parts of our page and cache them (via ob_get_contents() ).
===="It makes my application easier to maintain!"====
Are you sure? First of all, does your template parser have error handling features? What's it like to debug a template? And home many templates do you have now exactly?
=====PHP Templates!=====
Everything you can do with templates you can do better with PHP and include() or eval(). Using include(), you simply make sure the included file is mainly HTML and as little PHP as possible. For an example try [[http://www.pinkgoblin.com/index.php?view=scripts|AwesomeTemplateEngine]]. The other appoach is rather that using include, you use functions like [[http://www.php.net/manual/en/function.fopen.php|fopen]]() to read the template into a variable then "parse" the variable with [[http://www.php.net/manual/en/function.fopen.php|eval]](). This will be slower, given the intermediate step of assigning the template to a PHP variable, but at least you're not succumbing to the lure of templates.
You also have the option of taking advantage of [[http://www.php.net/manual/en/ref.outcontrol.php|Output Buffer]] for caching, which can be an extremely powerful solution when applied cleverly, and combined with HTTP cache headers.
So note that I'm not saying templates are bad in themselves but rather **template engines are bad**. Using PHP itself, it's perfectly reasonable to use templates.
Although there is another way...
=====The Bottom Up Approach=====
Now templates come from the idea that you probably design your user interface first then match your application to it.
But going back to this point of web designers doing the HTML, first of all, how many PHP coders can honestly say they work daily with a web designer who does all their HTML dirty work for them? Looking at many PHP coders sites (mine included), you can see that in fact they did it themselves, judging by the terrible visuals.
But even if you do have a web designer on hand, should they really be writing HTML like this?
Notice that "size=25"? So your web designer decided for you that the "username" variable will be 25 characters max? Isn't that your job?
The alternative view is that using Object Orientation and a "widget approach" and/or technologies like XML and XSLT. The concept is your code does all the work for generating the HTML - no templates involved, except possibly a globally accepted standard like XSLT. If your designer needs to do something, give them a CSS file to work with.
One excellent example of "widgets" in action is [[http://phphtmllib.newsblob.com/|phpHTMLLib]]. Using this sort of approach it like using PHP DOM API. What's powerful about it is we can create reusable page elements which can place on a page it's rendering "on the fly". Here's an example of building a table with phpHTMLLib;
add( "span.foo { font-size: 1em; font-weight: bolder;}" );
$style->add( "td { padding-left: 5px; text-align: center;}" );
$style->add( "table {border: 2px solid #999999;}" );
$style->add( "th {background-color: #eeeeee; ".
"border-bottom: 2px solid #999999;}" );
$style->add( "caption { font-size: 14pt; font-weight: bold;}" );
$page->add_head_content( $style );
$page->add( html_a($_SERVER["PHP_SELF"]."?debug=1", "Show Debug Source"),
html_br(2) );
$data_table = html_table("500", 0, 0);
$data_table->add( html_caption("A Caption for the table") );
$data_table->add_row( html_th("Column 1"), html_th("Column 2"),
html_th("BAR") );
for($x=0; $x<20; $x++) {
$data_table->add_row("Row #".($x+1),
$x*2,
html_span("foo", "something else"));
}
$page->add( $data_table );
print $page->render();
?>
The output looks like [[http://phphtmllib.newsblob.com/phphtmllib/examples/example2.php|this]]
Widgets are a nice way to do things but are still tricky, given some of the problems with HTML forms, for example, where form tags can be mixed in with any other HTML tags we like. It can often be overkill to use this approach.
For XSLT it's well worth looking at Luis A [[http://phpxmlclasses.sourceforge.net/show_doc.php?class=class_xslt.html|XSLT Class]] which provides a nice wrapper for the Sablotron XSLT extension to PHP. For an introduction to the concepts try [[http://www.webmasterbase.com/article/602|Transform Your PHP with XSLT]].
=====A note on ASP.NET=====
.NET's been much lauded in 2002 for being the next big thing. But just what is it Microsoft are encouraging web developers to do these days. Things like this;
Hello there
!
The time is now:
Can you see it? May be this adjustment makes it clearer;
Hello {asp:label runat="server" id="NameLabel"}there
{/asp:label}!
The time is now: {asp:label runat="server" id="TimeLabel" /}
Got it yet? Fact is Microsoft is widely encouraging people to use a their own template engine. But what's the syntax? Is is VB.NET or C#.NET? No sir. Just good old template tags. Microsoft have taken things a little further than most PHP template engines - the ASP tags equate to "widget-like" classes but it's still a template engine.
And like all template systems, it leads to insane numbers of templates, the application eventually becoming unmaintainable the bigger it gets. This is demonstrated nicely by Microsoft's own IBuySpy portal. Try [[http://samples.gotdotnet.com/quickstart/util/srcview.aspx?path=/quickstart/aspplus/samples/portal/portal.src|counting the templates]]...
Of course ASP.NET tags are [[develop:php_and_dom_the_way_of_the_widget|easily reproducable in PHP]]...
**Further Food for Thought**
[[design:archive:model_view_controller_pattern|The MVC Pattern]]
[[http://www.webkreator.com/php/techniques/php-and-templates.html|PHP and Templates]]
[[http://www.bivio.biz/hm/why-bOP|Why bOP?]]
[[http://www.sitepointforums.com/showthread.php?threadid=67849|Comments by voostind]]
[[http://www.massassi.com/php/articles/template_engines/|Template Engines]] - excellent article that does a better job of emphasing the main point;
"In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code."