středa 18. června 2008

Je čas na Apache Wicket?

Záznam diskuze:
L: Ahoj Franto, mám menší problém.
F: Jaký Lumíre?
L: Nevím, který webový framework pro javu je nejlepší.
F: No to je jednoduché. Vyzkoušej těch 40 nejznámenjších a pak se rozhodni.
L: Hmm... :(
Konec.

Ať již člověk navštíví jakoukoli homepage webového frameworku, dočte se, že zvolil dobře. Nejlepší možné řešení, vše jednoduché, perfektně rozšířitelné a v porovnání s ostatními je proste "Number ONE".

Sám jsem již dávno rezignoval na hledání zlaté žíly v podobě nejlepšího řešení. Volbu by mělo ovlivňovat to, jakou architekturu dané aplikace plánuji či jakým backendem aplikce disponuji. I když jsou snad všechny možné kombinace možné (Seam + Spring, Seam + EJB, Wicket + Spring, ...., ne vždy je volba zrovna šťasná. Pokud do hry vložím další možnosti jako volání část aplikace jiným způsobem (např. remote EJB), dostávám již užší skupinu možností.

Z této skupiny, která se vyznačuje volnou vazbou na business logiku, snadnou rozšířitelností a možností souběžného běhu s jiným web kontextem mi zatím nejlépe vychází Apache Wicket.

Ano já vím, stále existuje lepší .... nebo ještě lepší .... a vlastně úplně nejlepší ...... Ale já nemám čas ani náladu zkoumat další desítku možností. Stačí mi ta první desítka :)

Proč Apache Wicket?

  • volná vazba na business logiku

  • žádné xml

  • žádné anotace, které z POJOs dělají komponenty použitelné pouze v daném kontextu

  • téměř čisté html

  • vše je psané v jave, takže refactoring je mnohem snažší záležitost

  • dané komponenty si pamatují předchozí stav, takže tlačítko zpět již nemusí být noční můrou

  • menší zátěž pro server oproti JSF či Seamu

  • psaní aplikace je velmi blízké psaní swingových aplikací

  • dostatek komponent + snadné psaní znovupoužitelných komponent

  • při psaní se skutečně využívá objektově orientovaných principů

  • pro běh není třeba žádného speciálního kontextu (běží stejne v Tomcatu jako v AS)

  • daná aplikace je snadno přenositelná na jakýkoli jiný web kontejner


Asi bych mohl pokračovat dalšími body. Nicméně to, co jsem zde vypsal jsou vlastnosti, které mě přesvědčují o správné volbě.

Co se týče záporů, ty si budu muset nechat na pozdější dobu. Zatím jsem jen nezávislým pozorovatelem daného web frameworku. Každopádně jsem pevně rozhodnut toto řešení použít i za cenu složitejší spolupráce s EJB modulem a částí aplikace napsané v Seamu.

Takže mám 2 favority. Seam a Apache Wicket. Každý z nich přistupuje k cíli jiným způsobem a každý z nich se rozhodně hodí pro jiný typ aplikací. Až si Apache Wicket více osahám pokusím se obě řešení více porovnat a přesněji zjistit, pro jaký typ aplikací se dané frameworky hodí.