Po lekturze dokumentacji ZENDa i Code Igniter nabrałem wątpliwości co do idei własnego systemu szablonów w widoku. Smarty, phpBB i inne posiadają własne systemy tagów wstawianych w kod HTMLowy by je później pozamieniać na zmienne lub przeprowadzać dalsze operacje. Nie rozumiem tylko, jaki jest sens tego wszystkiego, gdy sam silnik php daje takie możliwości.
Oba frameworki, z którymi się zapoznałem w ostatnim czasie stosują w widoku szablon jako obiekt, który przyjmie zmienne z ich wartościami, a następnie za pomocą kodu php wyświetli te zmienne w odpowiednich miejscach.
Dla mnie logiczniejsze jest wyjście drugie - zapewnia nam te same możliwości (jeśli nie więcej!) co plik z własnym zestawem tagów, nie wymaga uczenia się nowego systemu szablonów. Odpada czas potrzebny na parsowanie szablonu przez nasz skrypt, no i co znacznie ułatwia pracę - większość narzędzi łatwo rozpoznaje php i chociażby samodzielnie podświetla składnię. Gdy otworzymy w przeglądarce szablon smarty'ego albo OPT naszym oczom ukaże się dokument z dużą ilością niezrozumiałych fraz objętych w klamry. Gdy otworzymy szablon z Zenda, do przeglądarki nie dotrze nic, co było objęte w <? ?>.
Rozumiem, że stosując systemy szablonów w wersji Smarty lub podobnej, odbieramy sporo narzędzi twórcy szablonu, by ten nie powyczyniał tam cudów. Tylko po co, kiedy sami jesteśmy najczęściej twórcami szablonów?

Było już wiele dyskusji o tym na sieci.



Tutaj wydaje mi się, że się pogrążyłeś. Bo to raczej świadczy o tym, że robisz małe projekty - jednosobowe, więc w sumie wszystko jedno czy będziesz używał systemu szablonów czy nie. W mojej poprzedniej firmie szablony strony składała osoba, która nie miała pojęcia o programowaniu, znała tylko HTML i ze smarty jakoś sobie radziła, po prostu wstawiała html i tyle, a znaczników nie dotykała. Jakby tam były jeszcze jakiś php to sorry, ale ja nie miałbym czasu by jej tłumaczyć co popsuła, albo co tu ma zrobić. Druga sprawa to administator nie pozwalał klientowi grzebać w php, ale klient chciał czasem coś zmienić w wyglądzie toteż poprzez webdav miał dostęp do tych szablonów i mógł sobie mieszać, ale nie mógł dostać żadnego php, który mógłby spowodować jakiś wyciek danych czy włam.

To prawda, jestem jedyną osobą zajmującą się php. Grafik jeśli wprowadza jakieś zmiany, to i tak zazwyczaj ja je przerabiam.

Argument o tym, że ktoś się jako tako łapie w Smartym a w php nie, nie bardzo do mnie dociera - na prostszym poziomie smarty zachowuje się tak jak prosty kod php z tym, że zamiast {var} jest <?=$var?>. Później się zaczyna robić ostro, ale do tego, to wg mnie warto znać już php lub inny język programowania

Jeśli chodzi o wyciek danych.. Cóż. Prawda. Chociaż z drugiej strony, do szablonu można przesyłać tylko te dane, które są w danym momencie potrzebne tak, by obiekt szablonu nie przechowywał powiedzmy hashu hasła.

Wnioskuję, że w stuacji, gdy projekt jest większy, a dostęp do szablonów mają także osoby nie zaznajomione z php wygodniej jest dać im Smarty, natomiast, gdy osób pracujących nad projektem jest niewiele, nie ma sensu się babrać z Smartym i podobnymi, tylko zostawić wszystko w kodzie tak jak w klasie widoku w Zend. Dobrze rozumuję?

Indywidualna sprawa. Ja lubię smarty i mi się lepiej z tym pracuje, nawet w pojedynczym projektach.

PdM -> Smarty domyślnie udostępnia głównie zestaw funkcji programistycznych, więc nic dziwnego, że pojawia się tu wątpliwość co do sensowności takich działań. Jednak zauważ, że wszystkie większe systemy szablonów dają się stosunkowo łatwo rozszerzać, np. jeśli potrzebujesz nowego rodzaju pętli dla pewnych konkretnych zbiorów danych, możesz go sobie bez trudu dodać. W php już Ci nie pójdzie tak łatwo; nawet opakowując kod w funkcje/OOP, i tak twoje rozwiązanie będzie bardziej skomplikowane. Niektóre systemy mają także nieco inną strukturę składni, która daje znacznie większe możliwości manipulacji, niż czysty php. Weźmy np. OPT* czerpiący z XML-a - szablon może być tu reprezentowany jako takie drzewko a'la XML, dzięki czemu instrukcje mają duże pole do manipulacji nim (np. mogą wyłączyć cały jego fragment z przetwarzania, przenieść go w inne miejsce lub przetworzyć tylko wybrane fragmenty według swego uznania). Napisałem sobie do tego jeszcze kod do automatyczniej obsługi formularzy i w ten sposób korzystanie z szablonów nawet w pojedynkę nabiera dużego sensu, gdyż mam banalnie prosty kod, który odwala za mnie całą brudną robotę i wprowadzanie do niego zarówno małych, jak i poważnych poprawek, jest formalnością. Wystarczy uruchomić wyobraźnię .

* - nie chcę tu jakiejś wybitnej kryptoreklamy robić - niech każdy używa, co mu pasuje.

Przekonałeś mnie. O taką odpowiedź mi chodziło! Dzięki!