-3 komentáře “Exkurz do templatovacích enginů v Javě

  1. Ja bych jeste doplnil StringTemplate http://www.stringtemplate.org
    Používám StringTemplate na generování konfigurovatelných xml výstupů. Jako hlavní výhodu považuji, že umí opravdu jen to, co je potřeba k vygenerování výstupu a nic víc.

  2. Ad Grails: podle me jsou opravdu nejsilnejsi, kdyz clovek zacina na zelene louce s databazovou aplikaci, ale i tak se mohou hodit, nebot Groovy a GSP stranky jsou docela dobry urychlovac prace s prehlednym zapisem. Do projektu, ktery uz pouziva neco jineho, bych to asi nemichal, ale je mozne, ze ve specialnich pripadech by slo rychle zmigrovat. Jinak uvnitr je opravdu Hibernate (a nad nim GORM – uzivatelsky o neco prijemnejsi), Spring (na DI a transakce), Sitemesh na reuse layoutu a GSP namisto JSP – vytvorit napr. custom tag je mnohem jednodussi. Novou aplikaci v Grails napise clovek obvykle tak, ze vytvori model entit a z nej necha Grails framework vygenerat databazi (tu obvykle neni nutne menit, max. pridat nejaky index na urychleni), view a controller – ty se nasledne upravi tak, aby aplikace delala presne to, co uzivatele potrebuji.

    Ad Eclipse: ano, nastavil bych to web developerovi temer presne tak, jako by to mel na serveru, aby se o to nemusel moc starat. Eclipse nikomu nebrani editovat stranky jakymkoli jinym editorem. Taky by, pravda, slo nahrat mu na lokalni stanici jen Tomcat se SVN klientem (rucni kopirovani dekuji nechci 🙂 a Eclipse uplne vynechat.

  3. Ad Jakub) Vím o tom zatím houbeles, ale myslel jsem, že Grails přinášejí kompletní řešení pro web – tzn. od datové vrstvy po prezentační (vím, že Grailsy jsou založené na Hibernate a Springu). Pokud tomu tak je, tak je to obtížně použitelné v případě, že už máte existující řešení založené na nějakém CMS. Zatím to navíc vypadá, že Eclipse s Tomcatem by byla pro řadu webařů obtížně zkousnutelná – ideální stav je, když mohou mít aplikaci rozběhanou rovnou někde na serveru, editovat soubory přes Sambu a rovnou vidět jak se jejich změny projevují – bez jakékoliv starosti o setup projektu v Apache nebo Tomcat. My je navíc chceme co nejméně zatěžovat s něčím, co není jejich primární starost (a to je HTML výstup), takže v těchto ohledech postupujeme velmi opatrně.

    Ad Tomáš) SiteMesh i Tiles pokud vím jsou layoutovací frameworky, které se starají o poskládání výsledné stránky z jednotlivých součástí. Daly by se přirovnat k SSI include nebo k prostému includu v JSP – samozřejmě jsou v tomto ohledu daleko mocnější, jinak by neměly vůbec šanci vzniknout. Jsou docela šikovné pro rozsáhlejší weby, pro jednodušší si člověk krásně vystačí s JSP tagy (které se navíc od v. 2.0 mohou psát také jako JSPčka – takže to bylo z mého pohledu vždy jednodušší, než integrace dalšího frameworku). Velocity nebo Freemarker oproti tomu jsou knihovny pro kompletní tvorbu textového výstupu – tzn. obsahují základní cykly, podmínky, práce s proměnnými a jejich výpisem do výstupu, makry apod. SiteMesh a Tiles se navíc myslím integrují jako filry web aplikace, takže jsou nepoužitelné, pokud výstupem má být soubor na disku nebo email apod. (za předpokladu, že si to neohnete).

  4. Dobrý den
    Jaký je vztah Freemarket versus SiteMesh? Vím, že někdy se tyto šablonovací frameworky používají i dohromady. Dal by se jednoduše nahradit freemarket za SiteMesh, nebo oba dělají trochu něco jiného? A co Tiles2? Také je to šablonovací systém a viděl jsem ho dohromady s Freemarketem. Koukal jsem do dokumentace, takže vím jak je používat, ale pořád si je nějak vzájemně nedokážu zařadit.

  5. 2 Novoj & Václav: ano, třeba už „jen“ Grails :). K tématu – osobně bych šel cestou nastavit web developerovi projekt s Tomcatem v Eclipse, používat se to za chvilku naučí, změny hned uvidí přímo v reálné aplikaci a může to rovnou commitovat do SVN. Klíčové je, používat takový framework a styl kódu v HTML templates, aby mu to nebránilo v rychlém čtení template a plynulé práci. Podle mě když bude Java programátor dobře spolupracovat, jdou takhle krásně použít i JSP např. se Stripes frameworkem a tags, ale možná že Velocity či Freemarker by pomohly ještě víc. JSP stránky s tunou scriptletů bych tvůrci webu samozřejmě nedával – zabil by mě nebo dal výpověď, případně obojí.

  6. To mě moc těší. 🙂 Groovy má pro nás přichystáno spoustu příjemných překvapení.

  7. Václave, máš dar přesvědčovat lidi 😉
    Posouvám Groovy v seznamu TODO na vyšší příčku (a to už je hodně vysoko po tvojí prezentaci na CZJUGu).

  8. To rozdělení do kategorií code in template a template in code je docela výstižné.
    Pro kategorii code in template může Groovy také nabídnout několik zajímavých možností (čerpám z http://groovy.codehaus.org/Groovy+Templates):
    * SimpleTemplateEngine – for basic templates
    * GStringTemplateEngine – stores the template as writable closures (useful for streaming scenarios)
    * XmlTemplateEngine – works well when the template and output are valid XML
    Zatím s tím nemám hlubší zkušenosti, ale podle dokumentace by to mělo být velmi blízko Velocity či FreeMarkeru. Otázka zní, proč rovnou nepoužít Velocity či FreeMarker, když už je člověk zná, že?

  9. Tady narážíme na dvě pojetí:

    1) code in template
    2) template in code

    JSP, Velocity, Freemarker jdou tou první cestou – ta je z mého pohledu pro lidi zvyklé dělat web přirozenější (i když u JSP už je to na hraně).

    Groovy jak jsem koukl na odkazovaný example jde tou druhou cestou. Možná do této kategorie patří i Ruby ale to bych jen hádal z kontextu. Možná mě Jindra doplní.

    Ačkoliv mě Groovy hodně oslovilo a už pracujeme na jeho integraci, pro webový výstup zatím pro nás není favoritem.

    Ad Daniel) Díky za doplnění.

  10. V společnosti Velocity a FreeMarkeru bych pro doplnění a vybalancování zmínky o Ruby rád uvedl parametrizované stringy v Groovy (GStrings), jako další možnost pro ty, co mohou míchat Javu a Groovy, a jako perličku také na nich postavené groovlety (http://groovy.codehaus.org/Groovlets).

  11. Ad Novoj) Jak se delaji primo v Zope, to nevim. Pouzivam TAL jen v ramci PHP, kdyz v nem delam, v Zope to bude asi stejne. Pouziva se napr. misto ruznych XHTML tagu tag , ktery pak nese dale akcni atributy (tal:repeat, tal:condition etc), ale do vystupu nejde. Tzn. vase sablona je stale 100% XML, ale vystup muze byt plaintext.

    Priznavam, ze v takovem pripade je to trosku „ukecane“ reseni. Nicmene u me je takovych pripadu minimum a ostatni schopnosti TALu (makra, sloty, kombinace s XInclude) to bohate vyvazuji.

  12. Ad Jindra) Ruby flame se vám dostane všude 😀 , ale teď vážně – s Ruby nemám hlubší zkušenost, ale obávám se, že je to tak trochu všechno nebo nic (i když JRuby už by snad mělo být s Javou asi rozumně použitelné).

    Navíc u nás máme vývoj striktně oddělený a web vrstvu dělají striktně webdevelopeři, kteří jsou odborníci na web, ale nejsou to programátoři. Pro ně je IMHO daleko zkousnutelnější jednoduchý template engine jako FreeMarker než komplexní řešení jakým je Ruby.

    Ad Daniel) všechny termíny slyším prvně, takže těžko budu reagovat – letmo jsem kouknul na Zope a docela pěkně je tam řešené to prolnutí HTML šablony a kódu, jak se ale dělají plain text šablony?!

  13. Je skoda, ze obe dve javovske implementace TALu z pythonskeho Zope ( http://christophermrossi.com/jpt/ , http://javazpt.sourceforge.net/) vypadaji, ze jsou u ledu.

    (Treba PHP ma implementaci na velice dobre urovni a za zadny Smarty a podobny bych to nevymenil, pro samotny Python taky zadna standalone implementace neni zrovna dvakrat aktivne vyvijena (AFAIK) — ale tam to jisti Genshi.)

    Takze pro me jsou JSP pres vsechny svoje negativa zatim suverenem.

  14. zkusil jsem vsechny – jsp, velocity i freemakrer. Freemarker ma tu uzasnou vlastnost ze jeho direktivy jsou XML-like, t.j. oproti velocity zvladal freemarker sablonu i obyc. html editor.
    U velocity mi vyhovovalo ze jedna chyba (napr. neplatny nazev promenne) vypsal jen vyjimku do sablony, kdezto freemearker (ve std. nastaveni) zastavi vykonavani cele sablony.
    Nejvic mi ale vyhovoval templatovaci engine v RoR – zadne vymysleni vlastnich direktiv – proste co je v a v (jsp like) je kod v Ruby se vsi svoji eleganci (kam se na to hrabe EL)…. doporucuju vyzkouset a poznate co v javovejch templatovacich frameworcich chybi a kam by mel smerovat vyvoj:-)