Idea separacji mechanizmów prezentacji i przetwarzania danych powraca wśród programistów PHP, jak bumerang. Nikt nie wątpi, że powinny być one oddzielone od siebie: programista pracuje nad swoją częścią, webmaster tworzy kod HTML i nikt nikomu nie wchodzi w drogę, gdyż wszystko jest w osobnych plikach. Dyskusje powstają w momencie, kiedy zaczyna się mówić o formie i wykonaniu. Jedną z koncepcji, przez jednych wychwalaną, przez innych krytykowaną, są systemy szablonów. Są to specjalne biblioteki, które potrafią przetwarzać pliki HTML ze specjalnymi znacznikami mówiącymi, gdzie mają się pokazywać dane generowane przez skrypt.
Niekwestionowanym królem systemów szablonów, jeśli chodzi o popularność, jest Smarty. Rozwijany jest on od bardzo dawna, co z punktu widzenia stabilności jest korzystne, lecz ma przełożenie na możliwości. Wielu programistów krytykuje go za zbytnie zbliżanie się do języka programowania, "nieżyciowe" nazewnictwo metod w formie "nazwa_nazwa()", zamiast bardziej "eleganckiego" camel style, czy nawet ograniczenia samej architektury. Smarty przez długi czas miał też problemy z działaniem na PHP 5.
Artykuł ten koncentruje się jednak na innym systemie szablonów, stworzonej w Polsce bibliotece Open Power Template. Na pierwszy rzut oka może się ona wydawać klonem Smarty'ego, lecz bliższe spotkanie ujawnia mnóstwo różnic, zarówno w składni, możliwościach, jak i architekturze. Oto krótka charakterystyka biblioteki:
Open Power Template jest częścią większego projektu obejmującego zarówno aplikację forum dyskusyjnego Open Power Board, jak i zestaw pokrewnych bibliotek (Open Power Driver - nakładka na PHP Data Objects, Open Power Forms - dodatek do OPT koncentrujący się na zarządzaniu formularzami).
Niestety, z wielkim rozczarowaniem doczytałem do końca arta. OPT był mi zachwalany jako genialna alternatywa dla SMARTY, lecz przynajmniej po tym artykule muszę stwierdzić, że OPT nie rozwiązuje problemów, które są w SMARTY (lub nie zostały takowe wspomniane). Moje wrażenie jest mniej więcej takie, że OPT jest bardzo podobne do SMARTY. Twórcy OPT zamiast tworzyć nowy, bardzo podobny silnik szablonów, mogli zaproponować współpracę twórcą SMARTY, lub wydanie alternatywnej wersji.
Muszę powiedzieć, że SMARTY (przynajmniej na razie) góruje nad OPT tym, że jest akceptowany za granicą, co jest plusem dla programistów pracujących również z zagranicznymi firmami.
Tak, czy owak artykuł skłonił mnie do bliższego przyjrzenia się OPT.
Zrobiłem sobie dzisiaj porównanie szablonów między smarty a opt i szczerze powiem, że o ile obydwa systemy szablonów generują pliki php i je później includują do zdobycia danych do wyjścia, to smarty robi to znacznie szybciej (<!-- Skrypt wykonał się w 0.0013339519500732 sekund --> dla smarty, <!-- Skrypt wykonał się w 0.032589912414551 sekund --> dla opt). Reasumując jaki z tego wniosek? Moim zdaniem lepiej napisać prostą klasę, która będzie składowała dane i potem robiła include już napisanego przez nas szablonu w php. A w tym php odpowiednie odwoływanie się do zmiennych przechowywanych przez klasę np. template.
Jestem pod wrażeniem, jakby nie było jest to dość wielka alternatywa dla smarty
Jeśli moglibyście wypełnić ankietę na temat systemów szablonów:
http://ankiety.boby.pl/index.php?module=polls&action=fillup&poll_id=74
z góry dzięki.
Czy OPT w pełni obsługuje obiekty w szablonach? Chodzi mi o kostrukcje takie jak:
{$zmienna->metoda1()->metoda2();}
Smarty sobie niestety nie radzi z takim czymś a znacznie ułatwiło by mi to pracę.
Wszystko bardzo fajnie i ładnie, ale brakuje mi w treści porównań względem Smarty'ego. Jak wiadomo przyzwyczajenie jest silne i dla kogoś kto już używa (używał) Smarty i szuka czegoś innego/lepszego takie porównania i wyjaśnienia były by bardzo wygodne.
Przy porównywaniu chętnie bym także zobaczył informację o wydajności - Smarty jest fajne i baaardzo elastyczne ale z wydajnością nie jest wesoło i informacje o wydajności OPT w stosunku do Smarty mogły by sporo osób skusić do sprawdzenia tego w praktyce.
i tak odchodzi sie od znacznikow w szablonach na rzecz plain php templates - nie oszukujmy sie - kazdy szablon ma jakas logike prezentacji i nie ma co sie oszukiwac ze kiedys maksymalnie to sie uprosci - co jest wazne to separacja i enkapsulacja warstw - a sama skladnia juz nie tak mocno.
sh4dow jeśli oczekujesz odp na te pytania napisz do zyxa lub skorzystaj z openpb.net/forum :) celowo nie daję jako link aby nie było za dużego spamu w tym komentarzu.
Tak sie zastanawiam, jak mozna krytykowac sposob nazewnictwa metod/funkcji. No w sumie i dlaczego camel style ma byc "eleganckim" nazewnictwem ? Wiem czepiam sie ale tak jakos nie daje mi to spokoju.
A co do wsparcia wielojęzykowego to tutaj bym mocno polemizowal i zastanawial sie raczej jak mozna by to raczej poprawic. Bo sorki ale jesli ja mam baze gdzie jest okolo 5000 kluczy i do tego 6 jezykow to nie chcial bym widziec jak te pliki i tablice z tlumaczeniami by wygladaly.