Jarosław Zabiełło - BLOG: Szablony i wzorzec MVC - cz. III

Szablony i wzorzec MVC - cz. III

Jarosław Zabiełło — Sun, 14 Jan 2007 04:25:00 +0100

W poprzedniej części omówiono szablony dedykowane głównie do współpracy z designerami bojącymi się programować. Były to albo szablony wkładające swoją logikę do znaczników XML/XHTML (ZPT, SimpleTAL, Kid, Genshi, MasterView, PHP TAL), albo szablony posiadające swój własny, specjalizowany język (Smarty, Django, Jinja, Liquid). W założeniu taki język miał być prostym substytutem języka używanego w warstwie kontrolera. Szablony tego typu może są wygodne dla designera, ale na pewno nie dla programisty, który musi je przygotować. Po pierwsze, trzeba się uczyć kolejnego języka… szablonów. Po drugie, wszystkie tego typu języki są ograniczające dla programisty. Mimo że pozornie prostsze, w praktyce są bardziej złożone i to nawet dla designera. Np. szablony Django i Jinja nie posiadają żadnej składni na określenie trywialnego warunku większości, mniejszości:

{{ x }} jest 
{% if x > y %} 
    większe 
{% else %} 
    mniejsze 
{% endif %} 
od {{ y }}

Powoduje to masę kłopotów dla programisty¹. Prymitywna składnia szablonu wymusza więc kupę dodatkowej pracy. O ileż prościej jest użyć po prostu pełnej składni języka tak jak to robią szablony Cheetah:

$x jest 
# if x > y 
    większe 
# else 
    mniejsze 
# endif  
od $y

Dochodzimy tu więc do sytuacji kiedy byśmy chcieli coś bardziej elastycznego – pełnego dostępu do języka programowania. Taka sytuacja jest pożądana wtedy kiedy i tak szablony budują programiści na podstawie dostarczonego czystego kodu HTML od designerów.

PHP

Język PHP jest dosyć specyficzny, bo w istocie jest to język szablonów. Tzn. pierwotnie tak został stworzony, ale z czasem się skomplikował że dostąpił miana języka skryptowego. Ale jego korzenie widać w składni, która z definicji jest zagnieżdżaniem instrukcji PHP wewnątrz kodu HTML. Idąc tym tropem, niektórzy pomyśleli, że nie ma sensu wymyślać dodatkową składnię. Wystarczy użyć PHP w odpowiedni sposób. I tak powstały szablony Savant.

Właściwie to Savant nie powinny nazywać się szablonami, bo to nic innego jak PHP użyty w taki sposób, aby rozdzielić warstwę prezentacji, od wartwy logiki biznesowej. A skoro to PHP, to odpada nauka dodatkowej składni oraz potrzeby kompilacji specjalizowanego języka szablonów do końcowego kodu PHP (jak to ma miejsce w szablonach Smarty).

Czy takie podejście jest lepsze, czy gorsze, to już każdy może sobie ocenić. Moim zdaniem PHP ma na tyle mętną składnię, że warstwa prezentacji używająca Smarty² jest bardziej czytelna niż czysty PHP jaki używają Savant.

Ruby

Kiedy mówimy o Ruby w kontekście stron internetowych to najczęściej mamy na myśli jego najsłynniejszy framework – Rails. Ruby sam w sobie nie jest związany z HTML tak jak PHP. Rails do szablonów używa biblioteki ERb (ang. “embed Ruby”, czyli “zagnieżdżony Ruby”) Składnia jest bardzo podobna do PHP, JSP czy ASP. Ruby jest tu językiem zagnieżdżonym w HTML.

<%= x %> jest 
<% if x > y %> 
    większe 
<% else %>
    mniejsze 
<% end %>
od <%= y %>

Python

Jeśli chodzi o Pythona to istnieje cała masa systemów szablonowych. Ograniczę się do paru, tych bardziej interesujących.

Spyce

Szablony Spyce zostało stworzone jako pythonowa konkurencja dla PHP. Podobnie potrafią przeplatać język (tu: Pythona) z tagami HTML. Najbardziej oczywista przewaga Spyce wynika z faktu używania języka Python, który jest znacznie lepiej zaprojektowany i posiada dużo więcej możliwości niż PHP. Spyce potrafii budować własne znaczniki (custom tags, podobnie jak to potrafią javowe JSP) oraz łatwiej w nich zbudować komponenty, kod do wielokrotnego użytku.

Myghty

Szablony Myghty powstały pierwotnie jako pythonowa implementacja systemu komponentowego Mason dla Perla. Mimo wielu podobieństw, Myghty są znacznie potężniejsze o Masona, np. intensywnie wykorzystują obiektowość Pythona (zobacz różnice). Od początku Myghty powstało z myślą o dużych obciążeniach, ciężkich, profesjonalnych zastosowaniach. Mają doskonały własny cache, są bardzo szybkie, odporne na wątki, świetnie się nadają do tworzenia komponentów.

Programiści Pythona bardzo cenią sobie filozofię tego języka (która podkreśla prostotę, oczywistość i elegancję składni). Problem w tym, że Myghty dla pythonowców jest zbyt podobne do Perla. Są za mało “pythonic” – pythonowe. Dodatkowo, poprzez podkreślanie swojej komponentowości, Myghty niektórym zbyt kojarzy się z filozofią komponentową frameworku ASP.NET (a wzorzec MVC wydaje się być bardziej przejrzysty niż wzorzec sterowanych zdarzeniami komponentów). Myghty, jako system komponentowy, może być używane w stylu MVC, ale nie jest to takie naturalne i oczywiste. (Na szczęście, wszystko zmienił Pylons który zapewnia przejrzystą pracę zgodną z wzorcem MVC i Myghty są tam zredukowane tylko do obsługi szablonów szablonów. Sterowaniem zajmują się kontrolery Pylonsa a nie Myghty).

Cheetah

Szablony Cheetah posiadają jedną z najbardziej czytelnych i eleganckich składni. Autorzy wzorowali się trochę na javowych Velocity i Webmacro. Tym, którzy cenią sobie czystość Pythona z prostotą składni szablonów z pewnością Cheetah mogą przypaść do gustu. Przez dłuższy czas były moimi ulubionymi szablonami i do te pory lubię ich klarowność. Cheetah posiadają elegancką składnię obiektowego budowania szablonów potomnych na bazie już istniejących. Myghty też to potrafi, ale Cheetah to ma bardzo czytelnie zrobione. Cheetah są również bardzo szybkie.

Mako

Mako to najmłodsze dziecko stworzone przez programistów Pylonsów. Powstały na bazie doświadczeń i najlepszych cech szablonów Myghty, Cheetah, Django/Jinja czy Smarty. Największą ich zaletą jest ogromna szybkość i pythonowa filozofia pracy. Programiści Pythona mogą zauważyć, że składnia Mako jest bardzo bliska sposobowi pracy w samym języku Python. Mako posiadają wielką łatwość tworzenia komponentów, ale w sposób bardzo podobny do tego jak Python wykorzystuje swoje moduły. Szablony można także rozszerzać na drodze obiektowego dziedziczenia. Dziedziczenie szablonów może być określane w sposób dynamiczny (tego już nie potrafią np. Cheetah). Dowolny fragment szablonu można również zamienić na komponent z własnym cache. Mako posiadają także składnię modyfikatorów, które spopularyzowane zostały przez Smarty. Działają one jak uniksowe pipes (${zmienna|filter}.

Mako automatycznie kompilują swój kod do modułów Pythona. Można je więc debugować tak jak zwykły kod Pythona (Cheeatah wymaga ręcznej kompilacji). Można je bez problemu używać jako niezależną bibliotekę. Nie są one zależne od jakiegokolwiek frameworku. Można je zintegrować z dowolnym frameworkiem używającym standardu³ WSGI. Użytkownicy frameworka Pylons prawie nic nie muszą robić, bo Mako są już tam przygotowane do pracy.

Ogólnie rzecz biorąc, Mako to – moim zdaniem – najlepszy aktualnie istniejący system szablonów dla Pythona.

Zaś co do frameworków… to coraz bardziej zaczynam nabierać pewności, że przyszłość nie należy ani do Django, ani do Railsów. Nic nie może równać się z możliwościami czystego, 100% frameworka WSGI. Takim jest np. Pylons. Ale o tym, i o “bitwie” Pylons vs. Django i Rails, napiszę już innym razem.

Appendix 2007-01-29: Zobacz też szablony Haml .

¹ Poprawnie rzecz mówiąc, powinien napisać swojego helpera. Jeśli więc chcemy wyświetlić w pętli rekordy z bazy, a widok jest czuły na zawartość tych danych, to powinniśmy cała listę rekordów wrzucić do helplera, przeiterować w pętli, dodać dodatkową zmienną i dopiero tak zmodyfikowaną listę przekazać do szablonu.

² Smarty mimo posiadania własnej składni pozwala na odpalanie pełnego języka PHP: {php}print phpinfo();{/php}. Tak praktyka jest jednak odradzana, bo wprowadza jeszcze większy bałagan niż już jest w PHP.

³ Zobacz artykuł Introducing WSGI: Python’s Secret Web Weapon oraz prezentację koncepcji WSGI na video.

"Szablony i wzorzec MVC - cz. III" by MySZ

Fri, 02 Feb 2007 11:38:54 +0100

Wyjaśniło się – był siakiś bug w mako, w nowej wersji już wsio działa jak należy.

"Szablony i wzorzec MVC - cz. III" by MySZ

Thu, 25 Jan 2007 18:05:57 +0100

Nie lubię IRCa, wysłałem na listę dyskusyjną ;)

"Szablony i wzorzec MVC - cz. III" by Jarosław Zabiełło

Thu, 25 Jan 2007 09:24:38 +0100

Spróbuj poruszyć tą kwestię na IRC’u irc.freenode.net #pylons.

"Szablony i wzorzec MVC - cz. III" by MySZ

Thu, 25 Jan 2007 09:14:51 +0100

Tak, to było pierwsze co sprawdzaiłem, zresztą:

Oczywiście nie ma znaczenia, czy daję mu tak obiekt unicode, czy zwykły tekst

"Szablony i wzorzec MVC - cz. III" by Jarosław Zabiełło

Thu, 25 Jan 2007 02:46:34 +0100

A próbowałeś ${u’ążśźęćńłó’ | h} ? Mako woli pracę na obiektach unikodowych.

"Szablony i wzorzec MVC - cz. III" by MySZ

Thu, 25 Jan 2007 02:44:50 +0100

Czy ktoś jeszcze ma problemy z pliterkami w Mako/helperach? :/ Dopóki w szablonie umieszczam zwykły tekst, to jest ok. Ale już: ${“ążśźęćńłó” | h} wywala “exceptions.UnicodeEncodeError”. Oczywiście nie ma znaczenia, czy daję mu tak obiekt unicode, czy zwykły tekst, mam zadeklarowane w każdym szablonie coding: utf-8 etc etc, a on się i tak przy każdym helperze pluje. Macie może jakies pomysły?

"Szablony i wzorzec MVC - cz. III" by Jarosław Zabiełło

Wed, 17 Jan 2007 00:51:23 +0100

Tu jest trochę porównania Pythona z Ruby.

"Szablony i wzorzec MVC - cz. III" by riklaunim

Tue, 16 Jan 2007 20:00:48 +0100

Pylons wymyśla fajne rzeczy i nie zmienia API co wydanie… Django lubi odkrywać koło na nowo. Ciekawe czy po django 1.0 ludzie przestaną masowo używać wersji SVN. Pewnie po miesiącu czy dwóch wersja SVN stanie się “zalecana” ;)

"Szablony i wzorzec MVC - cz. III" by yezooz

Tue, 16 Jan 2007 15:43:01 +0100

ja tez czekam na jakies podsumowanie tej rocznej przygody. z pewnoscia moze to byc dla wielu bardzo pomocne

pozdrawiam

"Szablony i wzorzec MVC - cz. III" by Jarosław Zabiełło

Tue, 16 Jan 2007 09:55:10 +0100

Już to przerabiałem. Okres ekscytowania się XSLT mam za sobą. Tobie też przejdzie.

"Szablony i wzorzec MVC - cz. III" by rsz

Tue, 16 Jan 2007 09:17:08 +0100

Spoko spoko, za rok może się przekonasz do XSLT ;)

"Szablony i wzorzec MVC - cz. III" by Jarosław Zabiełło

Mon, 15 Jan 2007 10:23:07 +0100

Chodzi głównie o wady. Trochę o tym mówiłem na czacie Skype3 (powinna być dostępna historia rozmów). Napiszę więcej później.

"Szablony i wzorzec MVC - cz. III" by eXt

Mon, 15 Jan 2007 10:10:18 +0100

> To co się zmieniło, to ponad rok doświadczeń z RoR, ostatnio wydane Mako oraz to, że doceniłem potencjał drzemiący w WSGI.

Rok doświadczeń z RoR i skłaniasz się w stronę Pylonsów. Czyżby znudzenie RoR-em, zmęczenie jego wadami, czy po prostu nowatorskość/genialność Pylonsa?. Może pokusisz się o napisanie jakiegoś podsumowania tego roku z RoRem?

"Szablony i wzorzec MVC - cz. III" by Jarosław Zabiełło

Sun, 14 Jan 2007 18:35:19 +0100

Ależ ja zawsze doceniałem Pylonsa. Kto Cię swego czasu na niego namawiał, hę? ;) To co się zmieniło, to ponad rok doświadczeń z RoR, ostatnio wydane Mako oraz to, że doceniłem potencjał drzemiący w WSGI.

"Szablony i wzorzec MVC - cz. III" by climbus

Sun, 14 Jan 2007 17:58:46 +0100

Jeszcze trochę a całkiem cię przekonam do Pylonsa. Zapraszam do przeczytania mojego nowego wpisu na blogu: http://blog.netstation.pl/