Masa ludzi zadaje mi ciągle to samo pytanie — skoro PHP został stworzony jako język prezentacyjny, to jaki jest sens implementowania w nim kolejnego języka prezentacyjnego — systemu szablonów?
To prawda, że PHP powstał właśnie jako język do osadzania wewnątrz kodu HTML. Prawdą jest, że do dzisiaj mnóstwo ludzi w ten właśnie sposób go używa. Nic dziwnego, podczas wczorajszej wycieczki do Empiku, natknęliśmy się z Qwiatem na stustronicową książeczkę o wdzięcznym tytule PHP — to proste.
Już nie tylko liczniki
Sam język jednak przeszedł od czasów wersji pierwszej ogromne zmiany, największe z nich miały miejsce pomiędzy trzecim i piątym wcieleniem. Skupiają się one na umożliwieniu łatwego budowania dużych aplikacji. Aplikacji, gdzie mieszanie warstwy widoku i kontrolera jest co najmniej wysoce niewskazane, ze względu na czytelność i łatwość zarządzania kodem.
Minęły czasy, kiedy języków server-side używało się do budowania liczników. Często całość treści jest generowana właśnie przez kod. Tyczy się to tak samo PHP, jak każdego innego języka, który może działać po stronie serwera. Zmieniły się oczekiwania, wzrosła skala projektów, logika wewnątrz strony przestała wystarczać.
Ktoś powie zaraz, że przecież można oddzielić warstwę widoku i nadal korzystać tam z PHP, tak jak robi to CakePHP. Można, czasem jednak nie warto. Cake powstał jako klon uznanego frameworku Ruby on Rails. Oba celują w projekty rozwijane — przynajmniej w pierwszych stadiach życia — metodą programowania ekstremalnego. Koncentrują się na jak łatwiejszym zbudowaniu proof-of-concept i dalszym jego rozwoju, już po odkręceniu dodatkowych kółeczek od roweru.
Serwisy budują projektanci, a nie programiści
Oczywiście, są aplikacje, przy budowie których pracują prawie wyłącznie programiści. Niech będzie to Google Mail, YouTube, czy Wrocek. Prawda jest jednak taka, że większość komercyjnych serwisów internetowych jest budowana dla konkretnego klienta przez agencje interaktywne.
Ich ceny oscylują w przedziale od kilku do kilkunastu/kilkudziestu tysięcy i zyski z tego typu działalności ciężko przeznaczyć na zatrudnienie połowy Microsoftu. Dlatego też do zadań programisty często należy tylko przygotowanie silnika, zaś resztę pracy wykonują projektanci — webmasterzy lub graficy, w których gestii jest przygotowanie odpowiedniego kodu HTML, arkuszy CSS i połączenie tego w całość — produkt, który można oddać klientowi.
Co z tego wynika? Ano wynika tyle, że przy zatrudnianiu ważniejsza jest doskonała znajomość obu wyżej wymienionych technologii, niż zdolności programistyczne. Nie każdy webmaster zna PHP (Javę, Pythona, platformę .NET). Smarty można opanować w ciągu jednej doby, to zdecydowanie za mało na poznanie choćby części filozofii projektowania zorientowanego obiektowo.
This sit3 haxx0rd by scr1pt kiddi3z
Wyżej wspomniałem, że nie każdy jest programistą. Praktyka uczy też, że nie każdy powinien. Miałem w życiu wiele sytuacji, w których zmuszony byłem współpracować z ludźmi, którzy zdawali się całą swoją wiedzę pozyskać ze wspomnianej empikowej książeczki. Dość powiedzieć, że podatność na SQL injection to najlżejsze z popełnianych przewinień.
Popularne grzechy to ślepe include’owanie pliku, którego nazwa trafiła przez wywołania GET lub POST (najczęstsza, poza korzystaniem z register_globals, przyczyna ataków XSS), trzymanie ważnych danych w ciasteczkach przeglądarki, rekordzista umieścił tam nawet całe zapytania SQL. Z pewnością wystarczyłoby na wypełnienie kalendarza Daily WTF na najbliższy rok.
Silniki szablonów mają tę ogromną zaletę, że zapewniają piaskownicę (sandbox
), w której można bezpiecznie wywołać kod nieznanego pochodzenia (czytaj: cudzy kod). Nazwa pochodzi od terminu, jakim saperzy nazywają specjalne pojemniki i pomieszczenia do badania i rozbrajania znalezionych przedmiotów, gdzie ewentualna eksplozja nie naraża niczyjego życia.
W tym przypadku niczyje życie nie jest bezpośrednio zagrożone, ale ciężko wypracować sobie reputację, kiedy co drugie wdrożenie twojego silnika kończy się włamaniem na serwer. Korzystanie w przypadku prezentacji z prostego języka, zbudowanego specjalnie do tego celu, daje pewność, że nawet najmniej kompetentny człowiek nie będzie w stanie nic zepsuć.
W zasadzie tyle chciałem napisać, ale może ktoś ma zupełnie inny pogląd na te sprawy? Z góry zapowiadam, że nie interesują mnie argumenty na poziomie Smarty to nieakceptowalny narzut rzędu dziesiątej części sekundy na każdą wyświetlaną stronę.
by NuLL
17 wrz 2006 at 15:32
SMARTY — powolnosc, krowowatosc i PHP4. Pozatym ta dziwaczna składnia. Kiedyś S wykorzystywalem w kazdym projekcie — teraz dla kazdego projektu szukam alternatywy dla niego. Co do systemow szablonowych — zgadzam sie, ze sa potrzebne na kazdym kroku :-)
by Patrys
17 wrz 2006 at 15:41
NuLL:
Ale Smarty działa bez problemu z aplikacjami PHP5. PHP4 nie używamy i nie chodzi mi tylko o numerek :)
by jpc
17 wrz 2006 at 16:16
Oczywiście, żeby uzywać młotka (PHP) musimy znać metalugię i materiałoznawstwo (techniki obiektowe), więc uzywajmy elektronicznej wbijarki do gwoździ (Smarty).
Z całą resztą się oczywiście zgadzam, ale to już wiesz, bo przecież ja byłem tym ostatnim z wielu ludzi, którzy się Ciebie pytali. ;]
by carstein
17 wrz 2006 at 18:42
Taka mała uwaga — ślepe includowanie pliku, który trafia przez GETa albo POSTa powoduje jednak o wiele bardziej groźne Remote Code Execution (przy włączonym fopen rzecz jasna). W tym wypadku XSS to tylko taka wisienka na torcie.
by stan
17 wrz 2006 at 19:11
nie jestem większym programistą, jednak na podstawach języków programowania się znam.
uważam, że jeżeli jest projekt który wymaga szybkiego wykonania, a magiczny deadline się zbliża. to rzeczywiście szablony są jak najbardziej przydatne. po pierwsze dlatego, że są sprawdzone, a po drugie nie trzeba wynajdywać koła od nowa.
z drugiej jednak strony, myślę, że jeżeli zajmujemy się swoim autorskim projektem, i chcemy aby wszystko grało — należy cały kod znać, i często ważne jest ‚że to nasz kod — więc wiemy co gdzie jest, i ew. co mogliśmy źle zrobić. jednak problemem jest to, że gdy większa ilość osób pracuje przy naszym kodzie(a nie jest robiony obiektowo) to potem szybko można się pogubić.
jak napisałeś — wszystko zależy od klienta i zapotrzebowania.
by Elus
17 wrz 2006 at 21:58
Nie znalazłem w Twojej wypowiedzi ani jednego argumentu dlaczego Smarty (i inne systemy szablonów) lepiej sprawdzają się w warstwie widoku niż czyste php. Jakieś historie o empiku, licznikach i rozdzieleniu pracy pomiędzy programistów i webmasterów-designerów. Ok. Ale tak naprawdę to nie znaduję w tym wszystkim potwierdzenia Twojej tezy.
Argumentem na pewno nie jest to ze da sie Smarty nauczyć w przeciągu doby. Śmiem twierdzić, że żeby nauczyć się podstaw PHP w stopniu wystarczającym do zbudowaniu w oparciu o niego szablon wystarczy jeszcze mniej czasu. Zwłaszcza dla webmastera-designera, który w większości przypadków zna konstrukcję zwykłej pętli np. z JavaScript. Do zbudowania samego szablonu nie trzeba przecież znajomości żadnych złożonych konstrukcji językowych/programistycznych. Mimo wszystko myśle że taki {section} jest o wiele bardziej skomplikowany niż zwykły for.
Chyba że w tym wszystkim chodzi o ograniczone zaufanie do webmastera-designera. Tzn dajemy mu jezyk szablonowy o bardziej ograniczonej (aczkolwiek w zupełności wystarczającej) gramatyce, tak by niczego „nie popsuł”. Z tego jednak co widzę wiekszość systemów szablonowych zostawia w tej kwestii otwartą furtkę (w przypadku szablonu Smarty jest to np. tag {php}).
Nie bardzo rozumiem też akapitu o atakach XSS i tym podobych. Przecież tego typu ataki wynikają ze złej konstrukcji kontrolera (w przeciwnym razie nie można mówić o dobrym rozdzieleniu warstw modelu MVC).
Choć nie uważam się za programistę PHP to ostatnio miałem okazję pracować na takim właśnie stanowisku. Popełniłem też kilka szablonów w oparciu o Smarty. I teraz z perspektywy czasu zastanawiam się, czy faktycznie dało mi to taką wygodę i korzyści o jakich się poprzednio nasłuchałem.
by Patrys
18 wrz 2006 at 11:56
Nigdzie nie napisałem, że każdy ma używać akurat Smartów.
carstein:
Mnie tam uczyli na bezpieczeństwie systemów, że ataki typu RCE zaliczają się do XSS (nie tylko JS/HTML injection).
Elus:
Chodzi głównie o to. Tag {php} w Smarty wyłącza się jedną linijką w konfiguracji tegoż. Właśnie dlatego, żeby nikt tam ani kawałka kodu nie mógł wstawić.
A co powstrzyma pana Stefana przed napisaniem
include($_GET['plik']);?by carstein
18 wrz 2006 at 15:15
Patrys:
Ja mam nieco inną klasyfikację powieszoną na ścianie w takim razie :)
XSS rozróżniam od RCE ponieważ w pierszym przypadku narażone jest wyłącznie (jeśli mówimy o HTML/JS injection) bezpieczeństwo klientów serwisu, natomiast atak RCE ukierunkowany jest bardziej na sam site.