Wiw, Webisztán

Még tavasszal fenn volt a Webisztánon (régebben Sztahanov) egy többrészes podcast, amiben a Wiw alapítóival, Cseh Gáborral és Gordon Ákossal beszélgetnek. Nagyon tanulságos, többek között kiderül -bár ezt eddig is tudtam- hogy a kezdeti időkben a wiw-et egyáltalán nem tervezték nagy terhelésre és az egész egy php programból indult. Aztán újragondolták és újraírták abban a szellemben, hogy nagyobb látogatottságot vonzzon, de ennyire nagy ugrásra nem számítottak. Emiatt voltak architektúrális problémáik. Van egy gépházblog a portálon, -ami azóta átköltözött kétszer. Lehet olvasgatni annak, akit érdekelnek a technikai részletek. Látható, hogy nem egyszerű az architektúra és elég sok java komponenst használnak.

http://webisztan.blog.hu/2007/05/13/az_iwiw_sztori_1_resz_2

Elmondja az egyik tag, hogy sokat filóztak különböző dolgokon, például hogy az új ismerős bejelölésekor küldjenek-e emailt vagy mit küldjenek, de végülis az email jó ötletnek és jó behúzóerőnek bizonyult. Az is szándékos, hogy az értesítő emailben nem írják ki a bejelölő ember teljes nevét, hanem csak a keresztnevét. Az eredeti wiw-ben nem lehetett megnézni az ismerősök ismerőseit. Ez is egy nagy behúzóerő, nagy interaktivitást eredményezett, viszont kezdetben sokan ellenezték és valószínűleg néhányakat el is tántorított a site használatától. Az üzenőfal szintén egy ilyen behúzónak lett kitalálva. "Jó érzés ha belépek valahova és ismerős emberek beszólásait látom."

http://webisztan.blog.hu/2007/05/14/az_iwiw_sztori_2_resz

Néhány kulcsmondat a második részből: "Sok jó ötlet van, de figyelembe kell venni az adottságokat is. Nem minden ötletet lehet felhasználni." Sok különböző kapcsolatépítő portált megnéztek és mérlegelték, mit tudnak jól beépíteni a iwiw-be. "Egy kaliforniai cég Törökországban iwiw méretű sikert ért el." "Ausztriában a partyphoto feature megy nagyon, mindent vivő dolog." "Horvátországban blogőrület van." "Húzni kellett egy vonalat, különben sosem lett volna kész a szoftver."

A harmadik részben elmondják, hogy 5-6-an barkácsolták az első időkben.

(Nem írogatom ide a többi linket. A Webisztán élénken foglalkozik a web2 és a kapcsolati hálók kérdésével.)

Negyedik rész: Már nem csinálnák újra akkor sem ha tehetnék, mert 15 versenyző van már, némelyik elég komoly -letisztult funkcionalitással rendelkezik. Mégis csak a myVip futott be rajtuk kívül. Remélik hogy a roma vonalon sikerül megcsinálniuk egy nemzetközi kapcsolati hálót, amit az iwiw-vel eredetileg is akartak.

A HVG-ben is megjelent egy cikk és a Szigeten iwiw világzenei színpad volt a világzenei színpad neve. A HVG-s cikkben inkább üzleti oldalról járják körbe a dolgokat, pl. hogy a vételár lassan megtérül vagy legalábbis biztosan meg fog, és hogy az eladás nem ment teljesen zökkenőmentesen, mert a tagok nem értettek mindig mindenben egyet.
http://hvg.hu/print/200720HVGFriss176.aspx

Megjegyzendő, hogy egy ilyen szociális háló vételi tranzakcióban valószínűleg nem a szoftverarchitektúra kerül sokba, -mert azt egy profi csapat pár hónap alatt sokkal jobban újra tudná írni- hanem a felhalmozott adattömeg és a kialakított napi több(száz)ezer klikkelés, másszóval az ismertség, a név.

Update: Az óriási ismertség ellenére / miatt a site elérhetősége a mai napig hagy kívánnivalót maga után. Szókimondóbban fogalmazva néha kinyílik a bicska a zsebemben böngészés közben.

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.