Jeśli chcesz mieć pętle oraz instrukcje warunkowe, to faktycznie, używanie Smarty'ego itd. jest wynajdywaniem koła na nowo, gdyż poza klamerkami praktycznie nic się nie zyskuje, a zamiast tego są nawet ograniczenia, gdyż w PHP od biedy można sobie pomóc obiektówką itd.

Ale czy sam PHP jest najlepszy? PHP to język imperatywny, jak chcesz mieć listę albo wyświetlanie drzewka, musisz sobie zaprogramować to samodzielnie od A do Z za każdym razem, gdy potrzebujesz tego użyć. PHP nie rozumie, co ten kod ma robić, on ma listę kroków i wykonuje zadanie, jak leci, bez patrzenia na sensowność. Opcjonalnie, można to popakować w klasy itd., ale wtedy stracimy kontrolę nad treścią takich pętli, a do czego prowadzą próby rozwiązania tego typu problemów, wystarczy spojrzeć na frameworki. Przykro mi to stwierdzić, ale WSZYSTKIE frameworki mają schrzanioną warstwę widoku równo, jak leci, gdyż autorzy właśnie rzucili się na PHP. I tak np. w ZF mamy takiego potworka, jak "placeholderLoop()", który robi... pętlę! Skoro osobny język szablonów jest "zły", to dlaczego takie coś jest cacy, skoro to jest to samo i różni się opakowaniem? I też prowadzi do wzrostu liczby plików, bo treść takiej pętli musimy podać w osobnym szablonie. Więc twierdzenie autora, że paranoje są tylko w Smarty'm, jest jak najbardziej błędne. Druga rzecz jest taka, że ten sam problem (zdefiniowanie wyglądu jakiegoś komponentu) frameworki rozwiązują inaczej dla każdego komponentu. Chcesz skonfigurować formularz, musisz uczyć się jednego sposobu, chcesz skonfigurować wygląd stronicowania, do nauczenia jest druga technika i kolejne API, właśnie z powodu niedomagań PHP jako "najlepszego języka szablonów". Pomijam już fakt, że taka konfiguracja potrafi zająć kilka ekranów tekstu, bo w końcu gdzieś muszą się te dziesiątki warunków znaleźć.

Oprócz programowania imperatywnego jest też wiele innych stylów programowania, np. deklaratywne, gdzie określamy tylko, co chcemy uzyskać i nie martwimy się o implementację (takim językiem jest np. SQL - ile osób w ogóle zna jakieś imperatywne języki komunikacji z bazą danych?). Tworząc nowy język szablonów, możemy wpłynąć na cały jego kształt i porządnie zrealizować te elementy, które w PHP są trudno wykonalne lub wymagają kombinowania do trzeciej potęgi. Możemy właśnie zmienić styl programowania, zrobić język deklaratywny i okaże się, że możemy nim robić to samo, co w PHP, ale znacznie szybciej, bo nie musimy martwić się o implementację. Do tego dziedziczenie szablonów, mechanizmy ponownego wykorzystania kodu dostosowane do potrzeb HTML-a, a nie implementowania algorytmów. Nie ma czegoś takiego, jak "najlepszy język", są jedynie różne podejścia, a niedowiarkom polecam powrót do klepania skryptów do stron WWW w assemblerze - PHP powstał dokładnie z tego samego powodu, z którego powstają dedykowane języki do tworzenia szablonów...

"Teraz szablony pochodzą z idei, że prawdopodobnie zaprojektujesz najpierw interfejs użytkownika, a następnie dopasujesz aplikacje do niego." - autor tekstu tym komentarzem do góry dnem postawił projektowanie systemów, jako pierwsze wykonuje się zazwyczaj w modelu systemu informatycznego diagramy przypadków użycia, ew. diagramy sekwencji, w wypadku aplikacji www dołożyć można do tego diagramy stron oraz ważny jest na samym początku dobrze zaprojektowany interfejs użytkownika następnie dopiero przystępuje się do prac związanych z budową diagramu klas który stanowi podwaliny pod projekt bazy danych, potem zaś następuje pisanie kodu i ew. poprawiania w kolejnych fazach pewnych el. diagramów gdyż nie wszystko da się przewidzieć, jest to moim zdaniem absolutne minimum. Wracając do tematu stosowanie szablonów takich jak Smarty poprawia czytelność kodu aplikacji i pozwala prościej oddzielić od siebie warstwy, to jest dla mnie główna zaleta i tak najbardziej dopracowaną architekturą jest dla mnie J2EE, za swą kompletność i przemyślaną architekturę oraz wsparcie Suna ale to jest już moja subiektywna opinia.

autor albo bardzo nie lubi albo nie potrafi uzywac Smarty, poteznego i b.szybkiego silnika

w kazdym swoim duzym projekcie korzystam ze Smarty, probowalem chyba wszystkiego i nic nie dalo mi takiej swobody i elastycznosci jak ten system

argument, ze to nie tylko szablony ale i wbudowane funkcje, jest tylko zaleta dla bardziej zlozonych projektow

i do tego to ASP na koncu...mozemy zrobic zawody w czym szybciej napiszemy aplikacje, w PHP czy ASP, nawet najprostsza

test

a ja zgodze sie z autorem.
smarty zamiast prostych szablonow dostarczaja nam dodatkowy jezyk aplikacji ktory jest zbedny.
pozatym , czy php jest naprawde takie trudne?

mialem stycznosc z grafikami w firmach ktore robia strony profesjonalnie , i wszyscy znali tam podstawy php.

pozatym sam uzywam obiektow w czasie generowania stron i operuje na buforze , a niestety przez smarty nie mam dostepu do wielkiej funkcjonalnosci ktora daje nam php,

imho to zadanie ktore lezy po stronie autorow php do stworzenia natywnej i prostej biblioteki do obslugi szablonow, tak samo jak bylo z stworzeniem zend framework...

Nie wyobrażam sobie tworzenia stron za pomocą phpHTMLLib. To mija się z celem. Parsery szablonow są to się aby ułatwić sobie tworzenie nowych stron. Operowanie na czystym htmlu jest dużo łatwiejsze. Poza tym osoba nieznająca sie na php moze stworzyć własny szablon. Łatwiej jest aktualizować taką klasę. Dodać pluginy, wtyczki itp. chociażby obsługa jezyków jest wygodniejsza.

Podoba mi sie natomiast pomysl autora z renderowaniem w locie. Musze pomyseć o tym w mojej klase ;)

Gdybym nie miał doświadczeń ze Smarty, ten art napewno by mnie zniechęcił. Autor wyrządza krzywdę tym początkującym. Proszę mi wierzyć - wiele razy słyszałem bluzgi grafików którzy mieli przerabiać niby HTML'ki ze mieszane z kodem PHP. Do co dla nas może być oczywiste (choć nie uważam że czytelne), dla kogoś kto zajmuje się tylko stroną wizualnie, dostaje szału widząc PHP wbudowany w HTML. Powiem więcej - te same osoby kiedy dostały pierwszy raz templaty w Smarty teraz nie wyobrażają sobie czegoś innego (mimo początkowej niechęci). Teorie wysnuwane w tym artykule (poparte niewybrednymi przykładami) są strzałem kulą w płot.

nie no tekst dalej uswiadamia ludzi ze nie warto uzywac szablonow xD

ale to co na koncy jest przytoczone to jest ciekawe ale jak sciagnolem sobie phphtmllib to stwierdzilem ze wole bez ;p

O czym tak wlasciwie jest ten artykul? W sumie, nie wnosi nic nowego. Moznaby go strescic: "nie warto uzywac szablonow". To tak jakby znienawidzic Jave dlatego, ze potrzebuje wirtualnej maszyny... :/

Myslalem podobnie, dopoki nie zaczalem uzywac Smarty :-)

Czy ktos moze mnie oswieci co autor artykulu mial na mysli w tym fragmencie:
"Innym zagadnieniem jest używanie zamiast include() funkcji takiej jak fopen(), aby załadować szablon do zmiennej, a następnie "sparsować" ją przy pomocy eval(). Będzie to wolniejsze, dając pośrednie wyjście w przypisywaniu szablonu do zmiennej PHP - przynajmniej nie będziesz pod urokiem systemów szablonów."

A tak swoja droge tekst fatalnie przetlumaczony, niestety nie tylko ten. Niektore fragmenty wygladaja jak przetlumaczone przy uzyciu tlumacza komputerowego.