Smarty™ is one of the most known template engines for PHP. There are plenty of articles and other texts about it, however it was designed for PHP4 and some of its features are not implemented as good as we might expect. One of the goals of Open Power Template was to improve the features that we did not like in Smarty, as well as add some new ones, but this required us to make some changes, contrary to that library. This short appendix is written for people who already know Smarty and would like to discover the new template engine quickly and without problems.

Let's begin with a short glossary. Both libraries have elements that have the same name, but they are different things in fact.

OPT initialization is similar to Smarty. The thing you have to watch out is the naming standard. In OPT, all the names are in nameName() style, whereas in Smarty name_name() are preferred. The configuration is loaded only on the PHP level, but there are three ways to do this:

Like in Smarty, we do not have to specify all the options. The only ones that are necessary are: root and compile containing: path to the template directory; path to the compiled templates directory (compilation cache).

OPT can send headers only from the script level. For this, the optClass::httpHeaders() method is used. You can set there the content type and simple caching settings. Note that OPT detects, whether it can send the XHTML header to the browser, depending on its type and the user preferences.

OPT makes use of the new PHP5 features like exceptions. Whole code, where we make any operation using OPT, should be placed inside a try...catch block. If you do not want to write your own handler, you may use the default one: optErrorHandler($exception).

<?php
define('OPT_DIR', 'opt/');
require(OPT_DIR.'opt.class.php');
try{
  $tpl = new optClass;
  $tpl -> root = 'templates/';
  $tpl -> compile = 'templates_c/';
  $tpl -> httpHeaders(OPT_HTML);
 
  // template processing
 
}catch(optException $ex){
  optErrorHandler($ex);
}
?>

The equivalent of Smarty directive compile_check is performance, however you must note one thing: $smarty->compile_check=true is $opt->performance=false and vice versa.

Consider the following template:

<ul>
{section name=i loop=$items}
	<li>{$items[i].title} <ul>
		{section name=j loop=$subitems}
			<li>{$subitems[i][j].title}</li>
		{/section}		
		</ul></li>
{/section}
</ul>

This is the way of Smarty, how to do lists etc. Adding the next level of depth complicates the code more and more. OPT does not like such constructs, because they have many unnecessary elements, which unsually do not help the template designer. Both OPT and Smarty provide complete programming languages for the template side, however OPT prefers to use higher-level constructs and keeping the programming just for the situations, where other solutions failed. So, what do you think? How does the code above look in OPT?

<ul>
{section=items}
	<li>{$items.title} <ul>
		{section=subitems}
			<li>{$subitems.title}</li>
		{/section}		
	</ul></li>
{/section}
</ul>

No play with iterators, no play with the subitems - OPT links everything automatically. We can extend the code in order not to show the UL tags, where the section contains no elements.

{show=items}
<ul>
{section}
	<li>{$items.title} {show=subitems}<ul>
		{section}
			<li>{$subitems.title}</li>
		{/section}		
	</ul>{/show}</li>
{/section}
</ul>
{/show}

Starting from OPT 1.1.0, the library provides a special instruction for hierarchical tree data structure rendering:

<ol>
{tree=mytree}
	{leaf}
		<li>{$mytree.title}</li>
	{/leaf}
	{opening}
		<li>{$mytree.title}<ol>
	{/opening}
	{closing}
		</ol></li>
	{/closing}
{/tree}
</ol>

In OPT, there are more such easy-in-use features and you should become familiar with the fact that many common things can be achieved without any programming knowledge, whereas Smarty requires complicated or strange-looking algorithms from you in the same place. This template engine tries to avoid it - the helpers are useful not only for the non-programmers. Other template designers will find them as easier in use and keeping the code much cleaner and simpler.