Systemy szablonów - podsumowanie
Nadeszła pora na podsumowanie tematu systemów szablonów. Nie da się ukryć, że większość aktywnych programistów nie widzi już potrzeby korzystania z systemów szablonów. Świadczą o tym wpisy na blogach zagranicznych np. Paul M. Jones czy Hasin Hayder, który nawet napisał swego czasu książkę o Smarty. Warto także dodać, że do powolnego odchodzenia od Smarty (bo to głównie ten system szablonów był używany) znacząco przyczynił się brak nowej wersji, która nota bene właśnie nie dawno wyszła w wersji 3.0 alpha. Spóźnili się jednak o kilka lat. Powinno to wyjść w tym samym czasie co PHP5.
Wróćmy jednak do początku, dlaczego powstały systemy szablonów to chyba każdy wie? Ale dla porządku krótkie przypomnienie. Chodziło o oddzielenie warstwy logicznej od prezentacji. Było to za czasów kiedy jeszcze w PHP nikt nie korzystał z wzorca MVC, a programowanie obiektowe raczkowało. Dzięki korzystaniu z szablonów programistom łatwiej było tworzyć uporządkowany kod, przede wszystkim dzięki ograniczeniu liczby dostępnych funkcji w szablonach. Mieli mniejsze pole do popisu by robić cuda. Oczywiście jak ktoś się postarał to i tak potrafił zrobić bajzel.
Składnia w systemach szablonów jest bardziej przejrzysta niż ta w PHP. Osoby, które zajmują się HTML na pewno przyjemniej patrzą na kod napisany przy użyciu szablonów. Jednak nie może to być czynnik decydujący w mojej ocenie. Bardziej skomplikowane elementy i tak musi podłączać programista. Nauka umieszczania znaczników PHP nie będzie znacząco dłuższa niż tych z systemu szablonu.
Tak samo mało przekonującym argumentem dla mnie (tym razem przeciwko stosowaniu systemów szablonów typu Smarty) jest fakt, że szablony wolniej działają. Są przecież zamieniane na kod PHP więc co najwyżej wygenerowany kod PHP nie jest tak super zoptymalizowany, ale przecież tutaj nie ma żadnych ważnych wyliczeń więc to są mało znaczące różnice.
Są jednak serwisy/projekty, w których użycie jakiegoś systemu szablonu jest konieczne. Przykładem mogą być systemy blogowe, gdzie użytkownik ma możliwość dostosowania wyglądu do swoich potrzeb. W takim przypadku dostęp do funkcji PHP nie mógłby być możliwy, toteż zastosowanie systemu szablonów (a może powinienem napisać listy znaczników) jest jedynym, słusznym wyjściem.
Kolejny przypadek, który mi przyszedł do głowy to utworzenie np. systemu CMS, który chcemy sprzedawać, ale z zamkniętym kodem. Czyli stosujemy jakiś PHP Encoder. Kod PHP jest zabezpieczony, a dzięki zastosowaniu szablonów istnieje prosty sposób modyfikacji wyglądu strony.
W innych przypadkach nie bardzo jest chyba sens stosowania systemu szablonów. Z takim nastawieniem wyszli programiści prawie (wszystkich?) liczących się frameworków. Programiści Zend w swoich frameworku także postawili na czysty PHP, do tego wszystkiego projekt Smarty z subdomeny smarty.php.net został przeniesiony na domenę smarty.net.
Niektórzy nie chcą odejść od Smarty bo po prostu im się na tym lepiej pracuje, ale niestety z uwagi na to, że Smarty jest dalej w PHP4, a prace na PHP5 dopiero wystartowały ambitni programiści nie mają wyboru. Powinni porzucić rozwiązania, które stoją w miejscu bo przez to zostają w tyle. Swego czasu tyle się mówiło o CakePHP czy CodeIgniter, obrały drogę, że pozostaną kompatybilne z PHP4. Aktualnie PHP4 już nie ma więc tym samym te frameworki nie są nowoczesne. Nie korzystają z dobrodziejstw PHP5, a dobre firmy przeszły na zend czy symfony. Mniejsze firmy dalej stoją w miejscu bo szkoda im czasu / pieniędzy na inwestowanie w nowe technologie, ale to się kiedyś obróci przeciwko nim.
Słowa kluczowe: PHP, Szablony, Techblog, cms, framework, szablony, artykuł, blog
Komentarze i opinie
A już myślałem, że o szablonach takich jak w C++ piszesz i przyznam, że mocno się zdziwiłem po przeczytaniu pierwszego akapitu...
Na szczęście z ego co wynika z twojego wpisu to zupełnie inne szablony:)
W końcu blog o PHP to z C++ nie będę wyjeżdżał, zwłaszcza, że nic w tym od lat nie pisałem ;) Hello world może z pamięci bym napisał.
Przez główną Joggera zacząłem czytać i nie wiedziałem o czym jest blog...
po kiego grzyba mi taki np smarty jesli na oddzielenie od siebie warstw pozwoli mi xml/xsl dodatkowo wrzucajac calego xsl'a w cache przegladarki oszczedzajac kilkadziesiat % transferu? ;) nie mowiac juz o przejrzystosci jesli chodzi o dane czy mozliwosci userow (i koderow ;) na ich wykorzystanie (wycinanie kawalkow gotowego xml to przyjemnosc - htmla juz niekoniecznie ;)
serwujesz strony w XMLu, dzięki czemu dopiero na komputerze użytkownika następuje tworzenie wyglądu strony na podstawie `skeszowanego` szablonu XSL. jeden z top10 serwisow w PL (wedlug geniusa) mowi ze oszczedza dzieki temu 400-500Mbit łącza. z podobnego rozwiazania kozysta tez blizzard (a oni na maly ruch na pewno nie narzekaja ;) i wielu wielu innych
@znamPhp: a ja znam tylko 3 strony używające XML+XSLT ;]
btw, jak to współgra z google? chyba i tak trzeba im to do xhtml przerabiać, nie?
@btm
google to kwestia jednego if'a na HTTP_USER_AGENT, kilku linijek kodu i wyslania calosci jako html (blizzard calkiem niezle jest wypozycjonowany w wyszukiwarkach nie? :P)
polecam tez wpisac w google taka fraze:
"filetype:xsl"
Wyniki 1 - 10 spośród około 6,600,000 dla zapytania filetype:xsl. (Znaleziono w 0,18 sek.)
mozna znalezc calkiem ciekawe przyklady ;)
@znamPhp: mi chodziło raczej o to, że *JA* znam tylko 3 (fotka peel ma jakąś sekcję w XLS, blizzarda strony właśnie i nexto bodaj) :>
stormfly, wspomnij o KohanaPHP jako alternatywie dla CodeIgnitera ;]
Szczerze mówiąc po tytule liczyłem na nieco szersze omówienie systemu szablonów, a nie skupienie się tylko na zaletach/wadach smarty. Choć przyznam, że przyjemnie się czytało ;)
Ja już od długiego czasu zastanawiam się na rezygnacją ze smarty, jednak wiązało by się to z przerobieniem wszystkich szablonów w cmsie na którym na co dzień pracuje, a na to nie za bardzo znajduje czas. Tak czy inaczej uważam, wszyscy którzy używają szablonów takich jak smarty czy opt powinni z tego zrezygnować na rzecz czystego php. W końcu przecież mało logiczne wydaje się pisanie kodu szablonu który i tak przerabiany jest na php.
@mati: ja właśnie tak zrobiłem, a nawet więcej ze Smarty przeszedłem na OPT, a potem jeszcze raz na czysty PHP, przy okazji kilka rzeczy sobie poprawiłem w systemie ;)
nie było to aż tak straszne jak mi się wydawało, duże znaczenie miała bardzo podobna budowa modułów, wystarczyło copy / paste i małe modyfikacje za pomocą replace, a przy zmianie Smarty na OPT napisałem sobie skrypt, który robił to z automatu
Co do innych systemów niż Smarty to nie pisałem o nich bo nie widziałem żadnego, który byłby popularny, z dobrym supportem i do tego wspierany przez jakąś firmę z rozsądnym kapitałem.
XML+XSLT na pewno jest ciekawym rozwiązaniem, ale osobiście bardzo słabo znam XSLT i wdrożenie tego byłoby dość kosztowne, jeśli ktoś ma jakiś artykuł, który omawia jakie problemy można napotkać, jakie trudności występują w przypadku wykorzystania tej technologii to chętnie poczytam.
Kiedyś testowałem możliwości tworzenia stron w czystym XML+XSLT do transformacji. Idea jest fajna, lecz na drodze do jej realizacji stoją dwie przeszkody:
1. XSLT jest językiem funkcyjnym - jejku, ile ja się kiedyś namęczyłem, by tam zrobić pętlę iterującą od 1 do 10... dobrze, że chociaż iterowanie po węzłach obrabianego XML-a wygląda normalnie. Ponadto cholera może człowieka trafić, gdy musi od zera uczyć przeglądarkę, jak ma wyświetlać tabelki... :)
2. Ze wsparciem przeglądarek jest nienajlepiej i paradoksalnie tutaj Internet Explorer przynajmniej jeszcze jakiś czas temu przodował. Użytkownicy Opery o transformacjach XSLT mogą tylko pomarzyć.
Natomiast po stronie serwera wypada to gorzej.
A systemów szablonów nie porzucę, choćby z tego powodu, że czysty PHP nigdy nie będzie potrafił tego, co automatycznie robi za mnie OPT (dwójka, dodajmy). Jak będę zmieniać język, pierwsze co zrobię, to przepiszę na niego OPT :).
Obecnie jestem w trakcie przegryzania się (dosłownie) przez xslt i jako że miałem mało do czynienia z samym xmlem jest to trochę jak droga przez mękę :) Co do skomplikowania przekształceń, to porównując to ze smarty muszę przyznać że na początku nie mogłem się za bardzo połapać.
Jeśli chodzi o wsparcie to trafiłem na artykuł opisujący wykorzystanie modułu php_xsl, transformacja jest robiona po stronie serwera i działa to całkiem nieźle.
Na razie traktuje to jako ciekawostkę bo za cienki w uszach jestem żeby oprzeć na tym jakiś większy projekt :)
https://www6.software.ibm.com/developerworks/education/x-sepcontent/
Link do tutoriala. Wymaga niestety rejestracji. Mogę ewentualnie podesłać to w pdfie :)
@revyag: tak, tylko ,że transformowaine zawsze i wszędzie po stronie serwera rozmija się z celem stosowania XML+XSL :)
Sory, zły link powyżej jest :)
http://www.ibm.com/developerworks/edu/x-dw-x-sepcontent.html
@Zyx "Użytkownicy Opery o transformacjach XSLT mogą tylko pomarzyć."
od opery 9.5 xslt jest obslugiwane...
No niestety Smarty troche przysnąl.. aczkolwiek i tak uważam, że korzystajac z ZF mozna z niego calkowicie zrezygnowac (no chyba ze szablony moga byc edytowane przez osoby trzecie).
@Zyx
1) petle w xsl mozna zrobic dzieki rekurencyjnym wywolaniom jakiegos template dosc latwo
2) jesli chodzi o przegladarki to mamy:
http://www.w3schools.com/XSL/xsl_browsers.asp
raz ze malo kto uzywa starych wersji opery i IE5 a dwa: sprawdzamy userowi userAgenta co wczesniej juz pisalem i skladamy mu xsl/xml po stronie serrvera by wyslac mu html
Nowy komentarz