Chapter 1. Przedmowa

Niewątpliwie jednym z najczęściej zadawanych pytań na forach PHP jest: jak mogę uniezależnić moje skrypty PHP od grafiki? Dopóki PHP zbudowany jest jako „język skryptowy osadzony w HTML-u”, wciąż mieszana jest logika z wyglądem, jednak po napisaniu kilku projektów łączących PHP i HTML w końcu przychodzi nam do głowy pomysł, że odseparowanie formy i zawartości to Dobra Rzecz [TM]. W dodatku w wielu przypadkach role grafików i programistów są od siebie niezależne, co jest koejnym argmentem to rozdzielenia ich pracy. W rezultacie, następuje poszukiwanie systemu szablonowego.

Na przykład w naszej firmie rozwój aplikacji przebiega następująco: Po udokumentowaniu wymagań, projektanci interfejsu tworzą projekt interfejsu i przekazują jego projekt programistą. Programiści implementują logikę PHP i używają projektu interfejsu do utworzenia szkieletu szablonów. Projekt jest wtedy przekazywany w ręce konstruktora strony web, który doprowadza szablony do „pełnego blasku”. Projekt może krążyć tam i z powrotem , pomiędzy projektantem stron web a programistą, nawet kilka razy. Dlatego jest to bardzo ważne aby mieć odpowiednie wsparcie szablonów ponieważ programiści nie chcą mieć nic wspólnego z HTML i nie chcą aby projektanci stron HTML zmieniali coś w kodzie PHP. Projektanci HTML potrzebują wsparcia dla plików konfiguracyjnych, dynamicznych bloków oraz innych wymagań interfejsu, ale nie chcą mieć nic wspólnego z zawiłościami programowania w PHP.

Szukając w wielu systemach szablonowych dostępnych dzisiaj dla PHP, zorienienyujemy sie, że większość z nich dostarcza elementarnych możliwości zamiany zmiennych w szablonach i tworzyć ograniczone funkcjonalności dynamicznych bloków. Ale my potrzebujemy czegoś więcej. Nie chcieliśmy żeby programiści mieli coś wspólnego z wyglądem strony , jednak było to niemal nieuchronne. Na przykład, jeżeli grafik chciał aby kolory tła występowały naprzemiennie w dynamicznych blokach, musiało to być opracowane przez programistę z niezłymi umiejętnościami.;)) Chcieliśmy również aby konstruktorzy mieli możliwość korzystania ze swoich własnych skonfigurowanych plików i przenoszenia z nich zmiennych na szablony.

Rozpoczęliśmy ponowne spisywanie specyfikacji dla silnika szablonów pod koniec 1999 roku. Po ukończeniu specyfikacji, rozpoczęliśmy prace nad silnikiem systemu szablonów pisanym w C co z pewnością byłoby przyjęte w połączeniu z PHP. Podczas naszej pracy napotkaliśmy wiele technicznych przeszkód i niejednokrotnie gorąco debatowaliśmy na temat tego co właściwie taki silnik powinien a czego nie powinien robić. W końcu uznaliśmy, że silnik powinien być napisany w PHP jako klasa, tak aby każdy mógł go używać jak tylko mu pasuje w zależności od potrzeb. Dlatego też napisaliśmy silnik działający w taki właśnie sposób i tak powstał SmartTemplate ( ta klasa nigdy nie była zaprezentowana publicznie). Była to klasa, która robiła prawie wszystko co chcieliśmy aby wykonywała: stały czynnik zmian, wspomaganie zawierające inne szablony, integracja ze skonfigurowanymi plikami, osadzenie kodu PHP, ograniczenie zwrotu ‘if’ w funkcjonowaniu i wiele innych silnych dynamicznych bloków, które mogą być różnorako osadzane. Wszystko to oparto na wyrażeniach regularnych przez co kod stał się raczej, można powiedzieć, hermetyczny.. Ponadto był on zauważalnie powolny w dużych aplikacjach dla wszystkich parsowań i wyrażeń regularnych pracujących przy każdym wywołaniu. Największym problemem z punktu widzenia programistów była cała konieczna do wykonania praca w arkuszu PHP aby móc układać i przetwarzać szablony i dynamiczne bloki. Jak zatem uprościliśmy ten proces?

Wtedy pojawiła się wizja czym ostatecznie będzie Smarty. Wiemy jak szybki jest kod PHP bez parsowania szablonu. Wiemy również jak skrupulatny i władczy może wydawać się język PHP dla przeciętnego projektanta, może to być zasłonięte przez dużo prostszy templating synax. Co więc stanie się jeżeli połączymy dwie siły? Tak więc, narodził się Smarty....