finc weblog

Apache Wicket zdárně dospěl do verze 1.4, která sebou přináší změny zejména na úrovni podpory generických typů. Tato verze je tedy určena pro javu 1.5 či vyšší.

Po zdravé úvaze jsem se rozhodl přejít na tuto verzi a provést úpravy na stávajícím projektu, který byl psán pro verzi 1.3.x.

Hlavní rozdíly oproti starší verzi

Jak jsem již zmínil, hlavní změnou je podpora generických typů. Bohužel došlo i na změnu v API. Metoda „getModel()“ či „getModelObject()“ byla nahrazena „getDefaultModel…“. Směle jsem se tedy pustil do přeměny pomocí hromadného přepisu (cca 50 výskytů). Naštěstí byla tato změna dostatečná a aplikace je plně kompatibilní s verzí 1.4.

Využitelnost generik

Na jedné straně jsem jásal, že je konečne wicket více typově kontrolovatelný a nemusí docházet k ruzným přetypováním. Na druhou stranu je ovšem dobré poznamenat, že jsou pasáže (viz např. DropDownChoice), které jsou dost neštastně navrženy pro využití generických typů. Problém spočívá zejména v tom, že musím napsat tunu kódu navíc, která nepřináší až tak závratné změny.

Po zhruba měsíční migraci jsem omezil použití generických typů jen na místa, kde to skutečně má smysl (viz např. IModel).

Komponenty třetích stran

To, že je ve Wicketu tvorba znovupoužitelných komponent, hračka, je nepopíratelný fakt. Komponenty třetích stran se tedy spíše soustředí na složitejší věci. Bohužel, v současné době jsem nabyl dojmu, že je vývoj dost chaoticky či vůbec neřízen. Použít některou přídavnou vlastnost z WicketStuff je sázka do loterie. Pokud bych toto porovnal s JSF, je na tom Wicket naprosto žalostně.

Osobně využívám následující přídavné vlastnosti:

• wicket contrib javaee 1.1 – podpora pro injectování EJB komponent
• swarm 1.4, wasp 1.4 – pro podporu security management
• grid – jedná se o „rich“ tabulky; kdysi byl projekt vystaven na inmethod.com, poté byl zrušen; pohužel jsem musel udělat vlastní úpravy, aby daná komponenta byla vůbec funkční

Zbylé „projekty“ jsem po zběžném otestování raději zahodil. Mrzí mě, že například podpora pro jQuery je dost nestabilní a její použití je dost invazivní (viz. nutnost použít pro Application daného předka, což znemožňuje využít zase například Swarm).

Pokud má někdo zkušenosti z dalšími přídavnými vlastnostmi pro Wicket, nechť se o ně podělí v diskuzi.

I přes zmíněné zápory, které jsem zde popsal, je pro mne Wicket tou nejlepší volbou pro tvorbu web aplikací. Je prostě radost s ním pracovat! :)

Při vývoji javovských webových aplikací nad aplikačním serverem (Glassfish) či jen nad samotným webovým kontejnerem (Tomcat), dochází k jedné nepříjmené situaci a tím je nahrání aplikace na server. Pokud se jedná o malý projekt, je čas strávený nad undeploy/deploy mizivý. Jak ale projekt začne růst, roste s ním i čas, který strávite při nahrávání nové verze na server.

Existuje několik možností, jak se vyhnout co nejčastějšímu nahrávání. Jednou z možností je důsledné psaní JUnit testů, které by mě měly upozorňovat na vzniklé problémy již při vývoji. Další možností je spuštění aplikačního serveru v debug módu. Ten částečně umožňuje provést tzv. hot deploy, kde se na server aktualizuje pouze část, kterou jsem právě změnil. Záměrně používám slovo částečně, protože i tento způsob je dost omezen (tvorba nových tříd, nových metod, EJBs, atd).

Projekt postavený nad Apache Wicket je možné spouštět také v debug řežimu. Tento mód umožňuje využít komplexnější analýzu (logování, ajax výstupy, atd) při vývoji. Pokud je tedy tento projekt spuštěn v debug řežimu a celý aplikační server také v debug módu, je možné za běhu měnit implementaci metod. Problém ovšem nastane s html soubory u wicket komponent. Ty se jen těžko budu snažit dostat do hot deploy řežimu.

Po menším pátrání jsem ovšem objevil možnost jak provést „autodeploy“ těchto html souborů. Celý trik spočívá v tom, že si definuji vlastní tzv. „resource folder“, který nastavím do místa, kde se vyskytuje můj projekt. Tato funkcionalita se zapisuje do init metody uvnitř vlastní Application Class, která je definována v web.xml jako „applicationClas­sName“.

1. funkcionalita se spustí jen v případě, že je celý projekt spuštěn v debug modu.
2. pokud ve svém projektu měním html soubor, je tato změna promítnuta v běžícím projektu ihned (1 vteřina)
3. nastavím celou cestu k mému projektu a k jeho balíčkům

Tento „resource folder“ umožňuje změnu jak html souborů, tak i dalších vlastností jako je např. lokalizace v properties souborech, css, atd. Tedy vše kromě javovských tříd.

Co se týče samotného hot deploy, doufám, že se situace o dost zlepší s příchodem Glassfish V3, který by měl obsahovat OSGI kontejner.

Malé rýpnutí: Nedávno jsem poslouchal poslední podcast 29 z java.cz, kde Roman Štrobl mluvil o nové funkcionalitě „Compile on Save“ v NetBeans. Přiznám se, že se mi zatím nepodařilo tuto funkcionalitu využít při vývoji J2EE aplikace. Mám pocit, že je hot deploy na glassfishi omezen tak, že je to téměř nepoužitelné. Pokud se nemýlím, tak samotná EJB3 komponenta moc dobře takto „aktualizovat“ nej­de.

Tvorba vlastních komponent je u komponentově orientovaného web frameworku, důležitá vlastnost. Jen težko bych hledal projekt, který by si vystačil s existujícími vlastnostmi a komponenty daného rámce a nesnažil se o vlastní tvorbu.

Pokud bych Wicket srovnával s JSF na této úrovni, musel bych více podrobněji znát tvorbu komponent v JSF. Ať jsem se snažil sebevíc, nikdy jsem úplně neodhalil výhody vlastních komponent v JSF. Ten postup mi přišel natolik složitý a nesmyslný, že v tomto případě jsem vždy sáhnul po něčem existujícím (RichFaces, Tomahawk, atd.). V JSF mám v tomto ohledu jen teoretickou znalost, která mi ovšem stačí k tomu, abych se do nečeho takového, jako je tvorba vlastních komponent, vůbec nepouštěl.

Ve Wicketu je situace naprosto rozdílná. Samotný framework mě v podstatě nutí rozsekávat danou prezentaci do několika menších celků, které se později dají znovu použít. Navíc je situace o to snažší, že není potřeba se učit či používat nové věci. Bohatě stačí znalost základních komponent a jejich využití. Vše ostatní vyplyne samo.

Pro tvorbu nové komponenty je nejčastěji používán „org.apache.wic­ket.markup.html­.panel.Panel“, od kterého má vlastní komponenta dědí. Díky tomu získám základní vlastnosti, které bych musel jinak znovu tvořit. Podobnost lze najít u Swingu, kde vlastní komponenty nejčastěji dědí od JPanelu.

Na malém příkladu ukážu, jak vytvořit komponenu, která bude obsahovat základní informace o zaměstnanci. Tuto komponentu poté budu moci využít např. při kliknutí na detail zaměstnance, při výpisu zaměstnanců, apod. Všude, kde budu chtít znát základní informace o daném zaměstnanci.

Nejprve doménový model: Nyní vytvořím wicket komponentu: A k danému HTML i Java kod: Tím mám vlastní komponentu hotovou.Nyní ji stačí využít. Například při zobrazení detailu zaměstnance: K danému HTML i Java kod: I když je daný příklad triviální, jasně znázorňuje to, že tvorba vlastních komponent je v Apache Wicket velice jednoduchá a hlavně dobře použitelná. Způsob jak navrhovat takové komponenty je stejný jako v případě tvorby objektově orientovaného kódu. Třídy jsou malé a obsahují jen jednu jasně specifikovanou funkcionalitu. Stejné je to i zde. Myslím, že tohle je ta nejzásadnější věc, která dělá z Apache Wicketu dobrý framework, ve kterém je radost něco psát. Vytvořit komponenty a pak je skládat jako lego :)