Wicket vs JSF

Az elmúlt hónapokban volt szerencsém megismerkedni a Wicket-tel és a JSF-fel, ami két java szervlet alapú Webtechnológia azonos elhelyezkedéssel, azonos célkitűzésekkel. A második javafórum-os összeröffenésen -amin sajnos nem tudtam részt venni- is volt egy Wicket előadás.

A JSF a J2EE szabvány része a Wicket pedig egy SourceForge-os projekt, ami éppen nemrég csatlakozott az Apache Foundation-höz. A Wicket magát a konkrét implementációt is jelenti egyben, míg a JSF csak egy specifikáció, amelynek létezik egy referencia implementációja és több valódi implementációja. A valódi implementációk közül a Tomahawk-kal találkoztam, ami szintén az Apache-hoz fűződik.

A Wicket egy HTML markup-ot használ, amibe wicket-es tag-eket kell beleírogatni, amit aztán renderelésnél kicserélget szerveroldalon igazi HTML komponensekre. (Hasonlóan a Dojo-hoz, csak az kliensoldalon cserélget.) A JSF pedig klasszikus taglib működésű.

A JSF-hez a Facelet-eket is használtuk, ami annyit tud, hogy modulonként lehet összeállítani az oldalakat. Emellett még a standard taglib-et használtuk ahol tudtuk.

Ahelyett hogy hosszasan értekeznék róla, inkább kiválasztok néhány kritériumot és azok szerint hasonlítom össze a két versenyzőt:

HTML Elemkészlet: Milyen előregyártott elemek vannak.
Wicket: Elég szegényes, csak az alapvető form komponensek vannak meg. Rendezhető táblázat, fa nincs. Update: viszont sokféle komponens található itt: Wicket extensions
JSF: A referencia implementáció elég szegényes, a Tomahawk-ban már valamivel több lehetőség van, de több implementációból talán össze lehet szedni értelmesebb komponenseket. Ha más nem, fizetős implementációkból. A Tomahawk megvalósításai hagynak kívánnivalót maguk után. Konkrétan a tree2-vel találkoztam, amiben pl. nem létező feature, hogy a megjelenítésnél a fa bizonyos ágai legyenek lenyitva. Programozni kell hozzá. Általában elég sokat kellett programozni használható komponensek kialakításához ami roppant időigényes és bizonyos esetekben -amikor a business logikával kellene igazából foglalkozni- elkeserítő feladat.

DHTML lehetőségek: Ez nagyjából annyiból áll, hogy lehet-e komponensekhez javascript-eket beszúrogatni, lehet-e a komponensekre hivatkozni.
Wicket: Lehet, bár néha kicsit trükkös a Javascriptek oldalba ágyazása.
JSF: Az alap implementációnál problémás, mert maga határozza meg a komponensek id-it. Tomahawk-nál létezik a forceId, amikor mi adhatjuk meg az id-t. Ez nagyjából elégséges a DHTML-ezéshez.

Logika bővíthetőség: Mennyire lehet beavatkozni a keretrendszer működésébe.
Wicket: Elég jól bele lehet, szükség esetén akár a keretrendszerbe is bele lehet matatni.
JSF: Nem nagyon lehet beavatkozni, mivel a JSF motor az alkalmazás hatáskörén kívül esik, ráadásul az oldal életciklusa merev és teljes gáz, bizonyos esetekben nem felel meg az elvárásoknak. Megvan a helye a validációknak, modellbe érték visszaírásoknak, ettől nem lehet eltérni.

AJAX: Mindkettő az Ajax előtti időkből gyökerezik, szóval az ezirányú támogatás elég toldozás-foldozás jellegű, bár állítólag a JSF-nek is van Ajax-os megvalósítása és a Wicket is úgy reklámozza magát, hogy Ajax-os. Who knows...
Wicket Update a kommentek közül tapasztalt Wicket-es embertől: "Szerintem iszonyat jól használható a beépített Ajax támogatás, gyakorlatilag 0 sor javascripttel lehet szép ajaxos működést írni."

Adatmodell-prezentáció híd: A modellt valahogy bele kell pumpálni a html elemekbe.
Wicket: Java-ban történik ami fölöttébb kényelmes, nagyban megkönnyíti pl. a hibakeresést. Sajnos követni kell az oldal hierarchikus felépítését. Pl. ha egy text input egy-két frame-en belül van, azt a modellben úgy kell felépíteni. Általában sok anonymous inner class-t használunk Wicket adatmodell leírásához. Viszonylag egyszerű a különböző validációs logikák beépítése.
JSF: XML-ben van leírva, és emellett java bean-eket kell gyártani hozzá. Az így gyártott modell némileg könnyebben leválasztható, de többet kell írni és ott van az a fránya köztes XML és a JSF életciklus ami néha bekavar... Ha sikerül az XML-t hibamentesen leírni és nincsenek extra igények akkor meglepően hamar és könnyen működnek az összetolt részek. Amint dinamikus működésre van szükség, pl. egy mező validációs szabályai függenek egy másik mező értékétől -csőstől jönnek a gondok.

Hibakeresés:
Wicket: Elég részletes hibaüzeneteket írogat ki és a java használat miatt is egyszerű a hibák megtalálása. Nehezebb hibázni, mert minden java IDE eleve kiszűr sok szintaktikai hibalehetőséget. Sok hiba a komponens hierarchia be nem tartásából adódik. Nem mellékes, hogy a Wicket oldalak alapjában véve egyszerű HTML-ek, amelyek kapásból megjeleníthetőek egy egyszerű HTML böngészőben mindenféle szerver nélkül.
JSF: Általában a hibák indirekciója jelentkezik, ha jelentkezik. Rosszabb esetben csak üresen jelenik meg a kontroll, vagy szétcsúszva jelenik meg az oldal. Lehet találgatni hogy hol volt egy esetleges elírás, hiányzó vessző az XML-ben.

Modularizáció, újrafelhasználhatóság: HTML oldalrészek újrafelhasználhatósága.
Wicket: A beépített fragment mechanizmus használható. Jóval többet várnék.
JSF: A facelet elég telitalálat, nagyon jól használható. Az egyik legjobb dolog a JSF-ben, bár nem a JSF része. Kicsit szószátyár, de megbocsátható.

Grafikus dizájnolhatóság:
Wicket: Mivel sima (X)HTML, céleszközökkel igen jól dizájnolható. CSS, képek használhatóak.
JSF: Nem sima HTML, viszont egyre több JSF céleszköz van amivel WYSWYG módon szerkeszthető. Ezekkel az eszközökkel nekem még csak drótmodellt sikerült eddig összeraknom. CSS, képek viszont szintén használhatóak.

I18n: Természetesen támogatott mindkét frameworknél.

Oldalakon vezérlő logika: Ha ismételgetni vagy opcionálisan akarunk megjeleníteni HTML részeket.
Wicket: Nem támogatja, mert alapelv, hogy az oldalon ne legyen B logika. (De mi újság a prezentációs logikához tartozó vezérlő szerkezetekkel?) Végülis meg lehet szokni nélküle. A fragment mechanizmust kell használni, ezenkívül van még egy egyszerű de elég jól használható iterator szolgáltatás.
JSF: Több szinten is támogatja, már a standard taglibek miatt is, de sajnos nem mindig jól működik együtt a többféle technológia, ami néha nagyon megnöveli a szopásfaktort.

Szerverterhelés: Ezt csak úgy érzésre tudom mondani, hogy kb ugyanott lehetnek ebben a kérdésben. A Wicket-nek inkább több memóriára van szüksége, mert fenn kell tartania a kérések során a memóriában a java komponens hierarchiát, a JSF pedig újraépíti az adatmodellt minden egyes kérésnél, ami fokozott számítási igénnyel jár, viszont elvileg kevesebb memóriát igényel. A wicket-nél ügyelni kell a szerializációra, mert egy rosszul felvett mező könnyen felránthat pár megabájtot a session-be. A Wicket-nél szintén ügyelni kell az inaktívvá vált kliensekre, akiknek a Java komponens hierarchiáját valamikor el kell dobni a memóriából. Mindkettő cluster-ezhető.

Dokumentáció:
Wicket: elég jó doksi van hozzá.
JSF: van hozzá mindenféle írás, de pl. a Tomahawk-hoz egy félig írt Wiki, amiben sokszor inkább a problémákat részletezik.

Melyiket használnám a következő projektben?
Nagyon enyhén a JSF felé dől a mérleg, de biztos hogy utánanéznék valami igen jól kidolgozott megvalósításnak. A Wicket sem rossz, úgy érzem kb. egy szinten vannak, de a JSF-ben -akkor is ha talán több vesződéssel jár- több a lehetőség. Viszont ha kevés lenne a dinamikus form-jellegű tartalom az oldalakon akkor Wicket-et használnék, mert az közelebb áll a HTML-hez, könnyebb dizájnolni. Ha sok a logika, egymásba ágyazódás, form elemek újrafelhasználása, akkor pedig a JSF-et választanám. Egyébként pedig messze nincs még ez a meccs lejátszva és ha valóban modern és dinamikus webalkalmazást kellene csinálni, akkor valószínűleg nem ezek közül választanám ki a keretrendszerét.

Update 2007.12.11: Találtam egy ilyet (wicketstuff.org) és egy elég kimerítőnek látszó összehasonlítást különböző webes framework-ökről. Ha majd lesz időm, átnézem ezeket. Addig is, aki beleolvasott, írjon róla.

GWT

Miközben a magyar szcéna web 2.0 moguljai kiosztották egymás között az észt, lement a JavaOne és a 24-órás programozói verseny, a Google publikált egy webfejlesztő eszközt ami java kódból Ajax-os javascriptes alkalmazást csinál.

(A JAvaOne-het visszatérve egy pillanatra: volt egy slot car race nevezetű kis játék, ahol modellautókat kellett programozni valós idejű jávában. Ahogy a 24 órás versenyről elkészült képeket nézem ott is lehetett valami hasonló feladat. Jó poén lehet.)

Szóval, GWT: Letöltöttem, kipróbáltam. Vicces srácok ezek a guglinál, ennek az eszköznek semmihez semmi köze. Saját javadoc formátumuk van, saját futtató eszközük, ant helyett cmd fájlokkal lehet fura formátumú sablon projekteket generálni eclipse alá. Amúgy az alapgondolat nagyon jó és a leírás is ami alapján a kezdő lépéseket meg lehet tenni használható. A Gugli fórumokkal (vagy mi) még nem sikerült megbarátkoznom és érdekes módon nem nagyon van leírva hogy tulajdonképpen ez az ajaxos alkalmazás hogyan kommunikál a szerverrel. Mintha standalone webes alkalmazások írása lenne a cél. Egyébként a Gmail és társai nem ezt az eszközt használják. Ez az eszköz ugyanis csak nemrég, a JavaOne előtt lett kész. Inkább úgy néz ki, mintha valami komolyabb eszköz kis része vagy mellékterméke lenne. Meg kell hallgatni az 56-os javaposse-t amiben Brett Taylor biztos megmondja a frankót ezzel kapcsolatban. (Még nem hallgattam meg.)

zajlik az élet

• Hosszú műtét után újra él a joeblog. Ha magyarul vannak a cikkek nem értem miért vannak angolul a címek.
• Az Ajaxian él és virul. Nem is tudom követni, de amennyi engem érint hogy már a 12. podcast-nál tartanak és kijött a Taconite 1.5 verziója rögtön az 1.0 után.
• Sztahanovnál vannak néha érdekes hírek. Bele is pofáztam vagy kettőbe.
  
• Megnéztem egy jávás adatbázisbizgerélő eszközt. Az a neve ogy druid (http://druid.sourceforge.net). GPL-es és eléggé érzésből van megcsinálva. Nulla doksi, szóval érzésből kell használni is. Kicsit alternatív a kezelése. Generál SQL-t, rajzol táblákat, szóval csinálja amit kell a maga érdekes módján.
• Nyomom a SJSE8-at és közepes a véleményem róla. Megy is a Sun Developer Forum-on sok téma hogy kinek mi a baja vele. Nekem például az hogy lassú, de nemcsak nekem. Érzem hogy késve követ, de amikor UML diagram rajzolásra kerül a sor akkor kész, pörög a ventillátor, dolgozik az eszköz izomból másodpercekig ha arrébb rakok egy dobozt. A vonalakat persze össze vissza húzogatja. A szekvencia diagram része kész katasztrófa, gyakorlatilag elsőre kell megrajzolni mindent, mert ha utólag szerkeszteném összebarmolja az összes eddig megrajzolt vonalat. Ezenkívül meglepetésszerűen rakosgat osztályokat a csomaghierarchiába. Ehh, nem folytatom.
  
• Volt mindenféle konferencia ahol bejelentették az inteles Macintosh-t meg mindent.
• Egy Who-s fószer megmondta a frankót hogy ne hallgassátok hangosan az iPod-ot, mert halláskárosodást okoz. Mintha csak iPod lenne a világon bmeg. iSznoboknak iPodot.
  
• A jávalistán írtak egy vicces kódrészletet: String a(){for(;;);} (Fordul.)
  

Web 2.0

Az Indexen megjelent egy cikk a "Web 2.0"-ról. Rögtön szét is néztem mi a nagy magyar helyzet ezzel kapcsolatban. Ez még csak egy fórumcsíra, amit a cikk ihletett, de valószínűleg nagy megmondások színhelye lesz. Sztahanov blogja már most a nagy megmondások színhelye, érdemes figyelni. Szerinte ez a jó írás a Web 2.0-ról a Magyar Narancsban és még megemlíti ses blogját ahol megintcsak érdekes információk szoktak burjánzani.

Amíg pedig az indexen szociális irányból közelítik meg a dolgot, Nextapp-ék kijöttek az Echo2 2.0-val és az EchoStudio2 2.0-val, a Ruby on Rails pedig most jött ki az 1.0-val, hogy valami technikai háttérről is beszéljünk.

Eclipse, Taconite

Hohó, két post egy nap alatt!

Szóval először is felraktam ma az 1.5-ös Firefox-ot aminek a Clear Private Data funkciója nagyon tetszik.

Kipróbáltam a Taconite-ot is ami szintén megfogott, csak kissé kényelmetlen volt highlight support nélkül jsp-ket írni, úgyhogy nekiálltam Eclipse plugin-t keresni. Találtam is, a WTP -t. Namost ha ennek csak a webes részét installálom akkor a jsp-ket nem highlight-olja hanem csak a html-t, css-t, xml-t meg még egy-két dolgot. A másik, hogy nem akarta az igazságot ezért installáltam gyorsan egy 3.1.1.-es Eclipse-t. Itt már működött, viszont kellett még hozzá installálni vagy 3 plugint. (JEM, EMF meg ki tudja mi...)

Most próbálgatom. Tetszik, már össze is haverkodtak a Taconite-tal. Highlight-ol mint a kisangyal, jönnek fel a popupok a lehetséges dolgokról, úgyhogy lehet haladni ezerrel. Egyetlenegy kis bánatom van, hogy nem támogatja a 4.0-ás JBoss-t. Ha J2EE projektet akarok csinálni 3.2.3 a legfrissebb amit ismer, és a projektcsinálás meg is bukik egy ponton amikor nem találja a jboss-boot.jar-t.

Közben volt egy downgrade-elés 3.2.6-os JBoss-ra és ismét megpróbáltam J2EE projektet létrehozni ugyanekkora sikerrel. Ennél régebbi JBoss-t már nem vagyok hajlandó feltenni. Generikus J2EE projektet is megpróbáltam létrehozni, akkor meg az annotation engine-be kötött bele, merthogy XDoclet-et szeretett volna. Azt hiszem az XDoclet már eléggé kifutóban van a JDK5 annotációi miatt úgyhogy ebbe már fölösleges (újra) belekezdeni. Akkor inkább megvárom a következő (rendes) verziót ebből az Eclipse pluginből.

AjaxTags vs Taconite

Belekukkantottam ennek a két frameworknek a kliensoldali javascript forrásába és azt kell hogy mondjam, a Taconite korrektebbnek néz ki. Az AjaxTags-ban külön tag-eket kezdenek el fejleszteni (taglib) -ez eddig rendben is van. Viszont a .js fájlban direktben benne vannak a komponensek kliensoldali kódjai. Mindegyiknek külön paraméterezése van vagy mi, ami abszolút nem tetszik nekem. És ha lesz 600 komponens akkor 1 megás lesz a .js fájl? A Taconite jóval általánosabb és körültekintőbb megoldásnak tűnik így első ránézésre.

Egyébként van még az AjaxAnywhere ami szintén egy open source project, de nem szorosan ide tartozik mert hagyományos webappokat lehet átírni vele ajax-osra. Azért kicsit idetartozik, mert biztos általános megoldásai vannak. Olyasmit láttam, hogy ki kell jelölni a jsp-ben (taglib) hogy melyik rész lecserélhető ajax-szal. Jó gondolat.

Láttam két céget, mégpedig a Backbase-t (Amszterdamban székelnek) és a Laszlo Systems-et akik foglalkoznak kommerciális ajax megoldásokkal. Úgy nevezik hogy rich web applications. A Backbase szimpatikusabb, a Laszloéknak kicsit körmönfontak a demói.

Ajaxos fejtegetés

Kezdetben volt a HTML, ami az SGML egy változata. A céljának -hogy olvasható legyen a gazdag dokumentumok forrása- megfelelt, viszont ahogy rájöttek a programozók a fastruktúra előnyeire kijött az XML -az SGML egy szigorúbb válfaja- és a HTML-nek is változnia kellett. Ebből lett az XHTML. Az XHTML-t könnyű kezelni a sok XML eszköz miatt. Dinamikusan lehet szerveroldalon DOM-ot összerakni, parse-olni is könnyebb, stb stb. Olvashatóbb is egyébként.

Ezzel párhuzamosan fejlődött a kliensoldali scriptelés is. Az XHTML elterjedésével a script-ek is egyre merészebben módosítgatják a DOM-ot és az XmlHttpRequest megjelenésével már a lap újratöltése nélkül is tudnak kliens-szerverinterakciót kezdeményezni ami esetleg a lap (DOM) csak egy részének megváltoztatását eredményezi.

Abszurd az eset, mert az először letöltött dokumentumnak esetenként látszólag egyáltalán nincs köze a browserben ténylegesen megjelenő oldalhoz. Az oldal forrása pedig már nem igazán átlátható. Tehát az (X)HTML szerepe teljesen megváltozott. Az egyszerű szövegszerkesztő már rég nem elég egy oldal szerkesztéséhez és most az XmlHttpRequest -és így a fokozott kliens-szerver kooperáció- megjelenésével a mostani kérés-válasz modellre épülő eszközök (asp.net, jsp, szervletek, php) túl primitívek a feladat megoldásához.

Éppen ezért fogott neki több szervezet is a különféle AJAX frameworkok fejlesztésének. Na majd meglátjuk melyik a "jobbik"...

Echo #2

Az előző posthoz némi konkrétumok:

EchoPointNG (Echo2-höz mindenféle speckó komponensek) early access:
NextApp developer forums > General Topics > Announcements > EchoPoint NG - is now in CVS, Post #1

host: cvs.sourceforge.net
repository: /cvsroot/echopoint
username: anonymous
module: echopointng

Javában tart a tesztelés és a hibavadászat és még nem is biztos hogy a legújabb Echo2-vel kompatibilis ill. fordul, úgyhogy tényleg early access. A lefordíthatóságért is harcolni kell kicsit. Például nem árt ha van kéznél egy saját servlet.jar aminek az elérési útját be lehet applikálni a build.properties-be, de Te ügyes vagy. Menni fog. És egy újszülöttől nem várj kidolgozott cassiopeira-rúgásokat.

Egyébként meg -csak hogy gyakoroljam az angol/magyar fordítást- Tod Liebeck bejelentése alapján:

"Az Echo2 platform legjelentősebb előrelépése az Ajax kliens-szerver szinkronizációs motorral való együttműködésen alapul. Az Echo 1.x-ben egy komponens frissítése a szerveren az egész őt tartalmazó HTML frame frissítését vonta maga után. Az Echo 2.0 ezzel szemben egy finomabb felosztást használ a kliensoldali HTML DOM-ban. Egy kliens-szerver-update során csak az érintett elemek változnak a kliensoldalon. Az eredmény határozottan simább működésű felhasználói felület és alapos teljesítménynövekedés."

"Az Echo 1.x egy rejtett HTML frame segítségével bonyolította a kliens-szerver szinkronizációt. Ezt a módszert használta, hogy bármiféle HTML dokumentum kliensoldali újrarenderelésének igénye nélkül tudjon a szerver számára információt küldeni. Az Echo2 ezen képesség ellátására kihasználja a mára széles körben támogatott XMLHttpRequest feature-t, egyben fölöslegessé téve a rejtett HTML frame-t. Amikor a felhasználó elvégez egy műveletet ami szerver interakciót von maga után a kliens elküld egy XML dokumentumot ami leírja az állapotváltozást. A HTTP kérés teljes egészében Javascript-en keresztül továbbítódik egy XMLHttpRequest segítségével. A szerver parse-olja az XML kérést, értesítve az alkalmazást a felhasználói akcióról. A szerver ezt viszonozza egy XML válasszal, ami utasításokat tartalmaz a kliens számára a megváltozott szerveroldali állapottal való szinkronizációra. [...]"

A továbbiakban az írás megemlít egy nem létező URL-en található demóalkalmazást, ami időközben ide költözött. Éppen nézegetem ahogy futkorásznak az XML üzenetek a kliens és a szerver között, miközben lélekben Tokajban a Tisza parton a Kisgólyában tölgyfaasztalnál ülve fröccsözgetek a haverokkal a Hegyalja fesztiválon. :,(

Echo

Az Echo egy Web GUI framework, amiben kiválóan lehet webes felületeket összerakni objektum orientált módon, a swing-hez hasonlóan (nem kell javascript-tel és html-lel molyolni). Explorer-rel, Firefox-szal működik, Operával szerintem nem.

Ehhez kapcsolódik az EchoStudio ami egy vizuális szerkesztő plugin Eclipse-hez Echo-s lapok összerakásához. Nagyjából használható, de magában hordozza a vizuális szerkesztők hátrányait, nevezetesen hogy buta kódot generál és gyengék az OO képességei. 1 hónapig lehet kipróbálni a szoftvert. Az Echopoint egy sourceforgés projekt ami további komponensekkel bővíti ki az Echo-t. Az oszloponként rendezhető, lapozható táblázatok a kedvenceim -ilyen még swingben sincs.
Eddig is jó tapasztalataink voltak az Echo-val és most Release Candidate-nél tart az Echo 2, amit mindjárt ki is próbálok. Már a CVS-ben van a 2-eshez való "EchopointNG" is.

-------

Éppen az Echo1-ről Echo2-re való átállást ízlelgetem: Egyes esetekben elég egy import csere, de elég sok minden változott. Nem is érdemes részletezni (talán majd egyszer). Az 1-es alkalmazás migrálásánál már éppen könyékig voltam az alkalmazás agyában, mígnem arra jutottam hogy inkább nulláról kezdem el újraírni. Ebben segíteni fog a letöltött csomagban lévő példaalkalmazás.

Update 2007.11.03: Időközben összekalapácsoltam egy részletekbe menőbb leírást is Echo 2 témában.