Spójrzmy na przykładowy kod dla popularnego systemu Smarty 2:

$smarty = new Smarty;
$smarty->template_dir = './templates/';
$smarty->compile_dir = './templates_c/';
$smarty->caching = true;
 
$smarty->assign('foo', 'bar');
$smarty->display('szablon1.tpl');
 
if(!$smarty->is_cached('szablon2.tpl'))
{
    $smarty->assign('bar', 'joe');
}
$smarty->display('szablon2.tpl');

Mamy tutaj jeden obiekt jednej, uniwersalnej klasy do wszystkiego. Smarty zajmuje się zarządzaniem konfiguracją, gromadzeniem danych ze skryptu, przetwarzaniem szablonów, wyświetlaniem, cache'owaniem i całą masą innych rzeczy. Korzystanie z biblioteki jest dość proste, zwłaszcza dla początkujących programistów niemających jeszcze doświadczenia z programowaniem obiektowym, ale nie sprawdza się zupełnie w większych projektach, gdyż łamie wiele zasad projektowania obiektowego.

W przeciwieństwie do Smarty'ego oraz wielu innych systemów szablonów, w Open Power Template nie ma jednej, centralnej klasy. Poszczególne zadania rozdzielone są między kilka różnych klas, z których każda jest odpowiedzialna za jeden, konkretny aspekt działania. Poniżej przedstawiony jest uproszczony diagram klas UML obrazujący główną część biblioteki:

Uproszczony diagram klas dla OPT

Mamy tutaj kilka mniejszych klas połączonych przez różne związki:

• Opt_Class - główna klasa zarządzająca konfiguracją.
• Opt_View - obiekty tej klasy reprezentują pojedynczy szablon z przypisanymi do niego danymi.
• Opt_Output_Interface - interfejs tzw. systemu wyjścia. Systemy wyjścia odpowiadają za uruchomienie wykonywania szablonu oraz zdecydowanie, co zrobić z wygenerowanym przez niego wyjściem.
• Opt_Caching_Interface - interfejs do obsługi cache'owania.

Jednym z rodzajów systemów wyjścia jest Opt_Output_Http, który wygenerowaną zawartość wysyła do przeglądarki oraz dodatkowo umożliwia zarządzanie nagłówkami HTTP. Z kolei Opt_Output_Return zwraca ją jako wynik wykonania metody render(). Programista może bardzo łatwo stworzyć własny system wyjścia dostosowany do jego potrzeb (np. do generowania zawartości e-maila). Identycznie przedstawia się sprawa obsługi cache'owania czy dodania paru nowych metod do widoku. Wystarczy rozszerzyć odpowiednią klasę lub zaimplementować jakiś interfejs, a wszystko zacznie działać.

Możemy teraz bardzo łatwo opisać filozofię pracy z OPT. Nasz skrypt musi na początku stworzyć obiekt Opt_Class i zapisać w nim konfigurację. Następnie tworzymy jeden lub więcej widoków, do każdego przypisujemy szablon oraz dane, a na końcu wszystko umieszczamy w jednym z systemów wyjścia, który wygeneruje kompletny wynik:

// Konfiguruj biblioteke
$opt = new Opt_Class;
$opt->sourceDir = './templates/';
$opt->compileDir = './templates_/c';
$opt->setup();
 
// Utworz widoki
$moduleView = new Opt_View('modul.tpl');
$moduleView->foo = 'bar';
 
$layoutView = new Opt_View('layout.tpl');
$layoutView->module = $moduleView;
$layoutView->title = 'Tytuł';
 
// Renderuj wszystko
$output = new Opt_Output_Http;
$output->render($layoutView);

W większości frameworków klasa Opt_View zostałaby utożsamiona z warstwą widoku we wzorcu MVC, jednak technicznie nie jest to do końca poprawne rozwiązanie. Opt_View reprezentuje jedynie szablon z przypisanymi danymi, tymczasem zadaniem warstwy widoku powinno też być pobranie tych danych z modelu i przypisanie ich do szablonu.