Już jakiś czas chodziło za mną przestawienie się całkowite z programowania webowego w PHP i Zend Framework na coś przynoszącego powiew świeżości i nowoczesności, a także większego porządku składniowego i dyscypliny.
Moje zauroczenie Pythonem trwa od przynajmniej dwóch lat, ale przekonać się do jego zastosowania w webie ciągle nie mogłem. Udało się wreszcie znaleźć do tego sposobność - projekt i w pracy i jeszcze zaległy zaliczeniowy, by móc złożyć pracę mgr z zaliczonym ostatnim semestrem. ;)
Django wygląda dojrzale i atrakcyjnie, sprawia wrażenie dobrze przemyślanego, a także porządnie wygrzanego w prawdziwych projektach, nie skupionego tylko na szybkim napisaniu aplikacji z tutoriala, by później się okazało że coś bardziej skomplikowanego, to wchodzenie pod stromy pagórek.
Co jednak mi pozostało w sposobie myślenia z twórczości phpowej, to poprzedni engine webowy do niedawna napędzający PDAclub.pl. Nieco się on zestarzał, a nie miałem czasu zająć się czymś nowszym, więc nowy główny programista przerobił mocno na użytek portalu Joomlę 1.5. Mniejsza o to.
Jednym z ciekawszych elementów, które tam opracowałem, to engine layoutów. Działało to w następujący sposób:
- każda strona prezentująca jakieś treści była przedstawiona w postaci pliku html ze wstawionymi tagami komponentów (w tamtej nomenklaturze - "modułów"), jakie tam miały się pojawić; komponentem takim był np. fragment HTML (np. dla nagłówka, stopki), pobierający tytuł portalu i inne parametry z konfiguracji; inny to komponent wyświetlający parametryzowalną listę newsów, jeszcze inny postów na forum, inny wyświetlający pełną treść wybranego artykułu, kolejny listę nowych hotspotów, menu główne, reklamy, województwa, pliki w dziale download, kategorie itd. Strona główna przykładowo składała się z: nagłówka html, menu głównego, menu nawigacyjnego bocznego, listy najpopularniejszych artykułów, listy poprzednich 15 newsów, głównej części z listą aktualności, listy trzech komunikatów/ogłoszeń (spotkania klubów użytkowników), listy najnowszych wątków z forum, 5 ostatnich komentarzy w newsach, reklamy helionu, shoutboksa dla redakcji (tylko dla niej widocznego), stopki (copyright). Każdy element mogłem dowolnie ustawić, by wyświetlał dokładnie co chcę i jak to ma wyglądać, nigdy nie był uruchamiany niepotrzebny kod. Jeśli chciałem dodać listę trzech najnowszych recenzji sprzętu, wystarczyło wstawić odpowiedni tag do pliku layoutu i ewentualnie zdefiniować template dla takiego elementu - ani linijki kodu PHP do napisania!
- parametry tych komponentów były podane w linijce z ich wywołaniem, przykładowo {mcm style="module: stories; template: stories_main; limit: 3d10; page: @p"}, oznaczało wstawienie listy newsów z trzech ostatnich dni, a minimalnie 10 najnowszych (jeśli przez ostatnie dni niewiele się działo - pomysł Alberta z czasów, gdy współpracowaliśmy nad pocketpage/palmpage ;) ), których kod html tworzony jest na podstawie templejtu templates/stories_main.tpl , @p-ta strona wyników, a wyrenderowana lista trafiała do pliku na dysku, by setki odsłon na minutę nie wywoływały ciągle tego samego kodu.
- wartość @p brana była akurat z parametrów żądania HTTP, oczywiście w module stories zamieniana na int
- Takie komponenty mogły być użyte wielokrotnie, nawet na tej samej stronie - często umieszczanych było kilka wariantów, np. inny z limit: 10; order: views; template: stories_popular, pokazywał najczęściej czytane artykuły za pomocą templejtu stories_popular.tpl
- Był zatem główny skrypt, który pobierał plik layoutu. Kod html zostawiał nietkniętym, a tagi zamieniał na stosowną treść, uruchamiając dla każdego odpowiednie moduły z "module", przekazując im parametry z tagu, z urla (jeśli potrzebne), ewentualnie ze współdzielonej przez komponenty tablicy zmiennych.
- Każde takie uruchomienie to był include_once skryptu "modules/{module}.inc.php" (odpowiednio zabezpieczone, by nie wywoływać nieistniejącego lub nie dopuścić do kombinacji ze ścieżkami), wywołanie funkcji a'la render i zwrócenie zamiennika dla taga
Dawało mi to sporą elastyczność, gdyż na różnych stronach mogły być te komponenty przedstawione w odmiennych wariantach, do dowolnych zastosowań. Założeniem było że są od siebie niezależne, ale nie przechowują żadnego stanu w sesji czy gdziekolwiek indziej - mają swoją pracę wykonać tylko na podstawie podanych parametrów i ewentualnie danych w bazie, jeśli z takiej korzystały (większość tak).
Było to bardzo mocno zoptymalizowane wydajnościowo rozwiązanie - jedyny narzut dawało samo parsowanie pliku layoutu, choć był na tyle pomijalny, że próby automatycznej "kompilacji" go do postaci kodu PHP (jak w enginie samych templejtów) skończyły się na eksperymentach.
Parę lat później stworzyłem nieco ulepszoną wersję także tego elementu. Można było robić include innego pliku layoutu, by najczęściej powtarzające się elementy dziedziczyć z innych stron, "moduły" były zrobione obiektowo, ale ogólna zasada działania pozostała.
Potem pojawił się Zend Framework. Zachwyciłem się nim, choć ze stratą tak dla mnie wygodnego rozwiązania jak owe "komponenty" się nie pogodziłem. Napisałem odpowiednie rozszerzenia frameworka, które realizowały ten sam pomysł na nowo. Tym razem opis layoutu to plik xml (kompilowany przez cache do kodu php), nie zawierający żadnego html, ani php, moduły robione w duchu ZF (wykorzystujące standardowe templejty ZF, tj. pliczki ze wstawkami kodu PHP). Ich obsługą w kontrolerach zajmował się helper uruchamiany w init() i postDispatch(). Bardzo proste i efektywne rozwiązanie - gdy wszelkie oprzyrządowanie było ustawione (przez mechanizmy ZF), tworzenie konkretnych stron z komponentami to była kwestia tworzenia pliku layoutu, napisania ewentualnie komponentu oraz templejta jakim prezentuje wynik swojej pracy. Skrypty kontrolerów poza tymi przyjmującymi dane z formularzy, to tylko proste klasy dziedziczące po bazowej, zawierające puste metody odpowiadające poszczególnym akcjom. To powstało przy okazji realizacji zamówienia kolegi na kilka mniejszych stronek i świetnie się sprawdziło. Ninjutsu, interaktywna część strony konkursowej ucha van gogha i kilka eksperymentów działa na nim w pełni sprawnie.
Teraz siedzę, rozpływam się w zachwytach wobec Django, ale brakuje mi tego rozwiązania. Nie chcę zawartości poszczególnych podstron definiować w kodzie pythonowym. Chciałbym móc layouty generować też dynamicznie z jakiegoś prostego designera, a to moja idea komponentów umożliwiłaby jak najbardziej. No cóż. zuber z blipa mi dał znać, iż tego typu mechanizmy nie sprawdziły się we frameworkach ery "Web 2.0", ale ja jestem chyba starej daty. W końcu jeśli to jest dla mnie ekstremalnie wydajne w tworzeniu, bardziej elastyczne i atrakcyjne od dziedziczenia szablonów Django, nie będę trzymał się sztywno MVC, MTV czy innych trzyliterowców nowego stulecia. ;)
A może jednak czegoś do końca nie zrozumiałem? Może w podobnie elastyczny sposób można to zrobić w domyślnej implementacji Django? Jak Ty to robisz, drogi Czytelniku? :)
Tak naprawdę ku zabawie z Django skłoniła mnie premiera Google App Engine parę miesięcy temu. Dotąd nie byłem przekonany zbytnio do programowania aplikacji webowych w Pythonie, ponieważ PHP z Zend Frameworkiem jest całkiem niezłym kawałkiem biblioteki, a przełączenie się na coś zupełnie innego wymaga nieco wysiłku z początku. Ale załączenie Django w GAE SDK było wystarczającą rekomendacją tego projektu, jako rozwiązania dojrzałego i przyjaznego programiście. Google ma zwyczaj akurat o tę grupę dbać całkiem nieźle.
