1. How does OPT work?

Let's take a look at a sample source code for the popular Smarty 2 template engine:

$smarty = new Smarty;
$smarty->template_dir = './templates/';
$smarty->compile_dir = './templates_c/';
$smarty->caching = true;
$smarty->assign('foo', 'bar');
    $smarty->assign('bar', 'joe');

In the example above, we have a single object of a universal class for everything. Smarty deals with the configuration, collecting the script data, template processing, rendering, caching and many more. It is rather easy to use the library, especially for the beginning programmers who have little experience with object-oriented programming. However, it is not suitable for bigger, objective applications, because it breaks many OOP rules.

Contrary to Smarty, Open Power Template does not have a single, central class. The tasks are divided among several smaller units. Below, we show a simplified UML diagram describing the main part of the library:

UML diagram for OPT

Simplified UML diagram for OPT

There are several smaller classes connected with different relationships:

  • Opt_Class - main class responsible for managing the configuration.
  • Opt_View - these objects represent a template with the data associated to it.
  • Opt_Output_Interface - an output system interface. Output systems are responsible for launching the template execution and sending the result somewhere (i.e. to the browser).
  • Opt_Caching_Interface - caching system interface.

One of the available output systems is Opt_Output_Http which sends the generated content to the browser. In addition, it provides the HTTP header management. The next one is Opt_Output_Return which returns the content as a result of the render() method. The programmer can easily create a new output system that suits the custom needs, i.e. generating the e-mail body. Another extensions, such as implementing a new caching system or adding new methods to Opt_View are simple, too. All we have to do is to extend an existing class or implement an interface.

The practical example of the API usage can be seen below. Firstly, our script must create an object of Opt_Class and save the requested configuration in it. Next, we create one or more views and bind them to templates and the script data. Finally, we put everything to one of the output systems which produces the complete result:

// Configure the library
$opt = new Opt_Class;
$opt->sourceDir = './templates/';
$opt->compileDir = './templates_/c';
// Create views
$moduleView = new Opt_View('modul.tpl');
$moduleView->foo = 'bar';
$layoutView = new Opt_View('layout.tpl');
$layoutView->module = $moduleView;
$layoutView->title = 'Tytuł';
// Render everything
$output = new Opt_Output_Http;

In most frameworks, the Opt_View class would represent the entire view. However, this is not fully correct approach according to the MVC pattern. Opt_View represents just a template with the data, whereas the view layer should also be responsible for retrieving the data from a model and implementing the view logic (i.e. pagination).