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ę.