Haml - następna generacja szablonów
Posted by Jarosław Zabiełło Sat, 27 Jan 2007 03:33:00 GMT
W związku z przestawieniem się całkowicie na najnowszą wersję Railsów (1.2.1), postanowiłem przy zrobić także upgrade oprogramowania do mego bloga (który w wersji jaką miałem nie współpracował z RoR 1.2.1). Na szczęście, dzięki railsowym migracjom proces aktualizacji skryptów jak i struktury baz przebiegł bez problemów i niedestrukcyjnie dla danych w bazie. Typo”:http://trac.typosphere.org/ zawsze był kodem trochę awangardowym, wprowadzającym zaawansowane mechanizmy Rubiego i najnowsze pomysły Railsów. Przekonałem się o tym podczas próby modyfikacji paru szablonów. Typo zamiast dotychczasowego formatu ERb (*.rhtml) Typo używa już szablony nowej generacji – Haml. Chcąc niechcąc, musiałem przejść szybki kurs posługiwania się nimi aby zmodyfikować szablony w swoim blogu.
Moje pierwsze wrażenia są bardzo pozytywne. Wystarczyło mi parę minut aby ogarnąć składnię. Szablon bazowy (layout) mojego bloga wygląda teraz tak (zrzut ekranu z RadRails/Eclipse, który doczekał się już pluginu):
Może na początku to nie wydaje się czytelne, ale po paru minutach pracy z Haml widać, że kod jest znacznie bardziej przejrzysty i krótszy. Nie trzeba także zamykać tagów. Widać tu inspirację Pythonem, gdyż Haml używa dwóch spacji jako wyznacznika bloku. Ci, co patrzyli z niechęcią na pythonowe używanie wcięć do oznaczania bloków, będą musieli przejrzeć na oczy. :)
Hamlto skrót od “XHTML Abstraction Markup Language”. Został stworzony aby ułatwić tworzenie czystego, dobrze zagnieżdżonego kodu HTML. Haml umożliwia pełny dostęp do Rubiego i helperów Rails. Ale może być teoretycznie zastosowany jako wymiennik składni dla PHP czy JSP. Aktualnie Haml to młody projekt (powstał w maju 2006). Jest aktualnie używany tylko we frameworku Ruby on Rails.
Haml generuje kod XHTML (czyli zgodny z XML). Dba o odpowiednie wcięcia i zagnieżdżenia tagów. Zwykłe, ręczne tworzenie kodu HTML jest nie tylko podatne na błędy. Jest także mało czytelne. Jak do tego dodamy składnię ERb, to się robi jeszcze mniej czytelniej. Haml jest receptą zapewniającą pełny dostęp do wszystkich mechanizmów Rubiego i Railsów ale… bez zagnieżdżania kodu Rubiego w kodzie HTML. Zamiast mozolnie wklepywać tagi, Haml proponuje budowanie ich w znacznie przejrzysty sposób.
Instalacja
Haml jest dostępny w formie pluginu do Railsów.
./script/plugin install svn://hamptoncatlin.com/haml/tags/stableMożna też zainstalować Haml za pomocą gemsów:
gem install hamlMoim zdaniem Haml jest pierwszorzędnym kandydatem na zastąpienie głównych szablonów Railsów – RHTML. Chyba zacznę już przebudowywać wszystkie swoje szablony. :)
Appendix:
Haml są już przygotowane dla Jedita, Eclipse/RadRails, Textmate i (G)vim. Wysłałem informację na listę Komodo aby to też dodali.
Update 2007-01-29:
Przepisałem wszystkie szablony na mojej stronie do Haml. Są po prostu świetne.
Subskrypcja kanału RSS
Kanały IRC![[Dilber w Onecie]](/images/larry.png)
sprawdzałeś może wydajność z i bez Haml’a?
Nie uzywamy juz @content_for_layout, tylko yield :layout :)
obcy: Nie sprawdzałem, ale z tego co piszą wynika że narzut wydajności jest mały, rzędu 5%. Haml są kompilowane raz (podobnie jak pehapowe Smarty) i potem już jest przetwarzany Ruby.
Piotr: Tak, wiem, ale tak jest w oryginale kodu Typo i nie chciałem go zmieniać.
jakoś trudno mi uwierzyć, żeby tylko 5%, ale sprawdzę to kiedyś.
Inną sprawą jest, że żaden designer nie skuma Haml’a. A jeśli nawet to nie będzie chciał z tym pracować.
Moim zdaniem jedynym zastosowaniem Haml’a mogą być małe projekty w których designer i programista to ta sama osoba.
obcy: zalezy jaki designer. Jak jest “css-enabled” to załapie szybko. Jak ja to pokazałem naszym “łebowcom”, to odrazu zauważyli selektory css i szybko to ogarneli. Nie zmienia to faktu ze jeszcze nie użyliśmy tego w żadnym komercyjnym projekcie :)
Problem może być tylko dla designerów uzależnionych od Dreamweavera. Jeśli jednak są to osoby kodujące ręcznie w HTML i CSS to z pewnością docenią piękno i prostotę składni Hamla.
A propos – napisałem interpreter Hamla dla PHP 5 – http://phphaml.sourceforge.net
Szczerze mowiąc, pomysł średnio trafiony. Czytelność formularza zerowa, chyba że ktoś popracuje nad dodatkowymi wcięciami. Po wszystkich latach pracy z różnymi engine szablonów, jak na razie najbardziej spodobał mi się freemarker (dla Javy) i jego składnia. Ten cały Haml wydaje się być na dokładnie przeciwległym biegunie… Poza tym nie ma nic chwalebnego w kodowaniu stron “z palca”, co wydaje ci się najwyraźniej czynnikiem wyznaczającym prawdziwego designera (w odróżnieniu od tego co używa Dreamweavera). Szczerze mówiąc, ja też często najpierw tworzę szablon strony w czym wysiwygowym (ostatnio jest to Microsoft Expression, dostałem licencję za darmo więc nie marudzę, zwłaszcza że kod jest o niebo lepszy niż w używanym powszechnie w firmie FrontPage), po czym “ożywiam” stronę już “z palca” bo edycja wizualna mieszanych szablonów już kilka razy mi się źle skończyła, nawet gdy korzystałem z Dreamweavera. Tego typu potworki uniemożliwiają takie tworzenie, chyba że po napisaniu całej masy karkołomnych regexpów.
Nie zgadzam się. Haml są bardzo czytelne. Czytelniejsze od ERb i krótsze. Oczywiście, że służą do kodowania ręczniego. Rails potrafi współpracować z wieloma systemami szablonów jeśli ktoś ma inne upodobania.
W wypadku korzystania z wizualnych wpomagaczy takich jak Dreamweaver, lepiej użyć szablonów MasterView, które logikę trzymają w atrybutach HTML. Są w ten sposób 100% przezroczyste dla designera operującego Dreamweaverem.
Też uważam Haml za czytelne i proste w implementacji. Trzeba sie poprostu do nich przyzwyczajić ale myslę ,że warto.Właśnie myslę nad implementacją ich na mojej stronie Wyliczanka.pl
Czytelne, ale każdorazowa przeróbka statycznych template’ów w HTML-u do HAML-a jest kłopotliwa. Konserwacja i przeróbki takiego kodu również.
RHTML jako mieszanina HTML-a z Ruby’m jest strawniejsza a i da się w miarę rozsądnie podejrzeć w przeglądarce.
@Jima: Wizualny design ma jedną podstawową wadę – jest oparty na wyglądzie a nie na znaczeniu. A tendencja jest teraz taka (co widać w rozwoju XHTML), że to mają być dane a CSS to opis wyglądu tych danych. Przez co można wstawić przykładowe dane, napisać pliki CSS i mieć gotową stronę(tzn. w teori się do tego dąży, ale nie zawsze jest tak różowo). Zmiana wyglądu strony (nie chodzi o wyświetlane informacje) to tylko podmiana plików CSS.