Lassan 1 éve foglalkozok GWT-vel. Gondoltam eljött az idő, hogy röviden számotvessek magammal, milyen is volt ez az 1 év…
A maga a koncepció, ahogy a megvalósították, hogy java-ban hozhatunk létre böngészőfüggetlen javascriptet, a szabad forráskódú fejlesztés, hogy a rendszer minden részének működését forráskód szinten látjuk, hogy módosíthatók (vagy utánozhatóak) az alap implementációk, és még sorolhatnám. Ez kétségtelenül megérdemel egy + jelet 🙂
Persze az ismerkedés nem volt egyszerű, néhány fejlesztési alapvetést, és nézetet adaptálni kellett, tehát aki gwt-re adja a fejét (szerintem ez ajax-ra, sőt minden asszinkron működésű programra vonatkozik) kénytelen picit „másképp gondolkodni”.
A tapasztalataim részletekbe menő ismertetését most sajnos nem írom le, de néhány gondolatot azért igen.
Nem, nem bántam meg, hogy gwt-be fejlesztek, és ha újra kellene választanom, én ismét ezt választanám. (bár ilyen téren mindegy miben kell fejleszteni, ha valaki elég eltökélt, bármivel tud nagyszerű dolgokat készíteni, max sok idő, és áldozat árán 😉 )
A GWT alkalmazásokban gondolkozik, és ezért „nagy alkalmazás” fejlesztése során felmerülnek problémák (pl. a memória használat, kódok mérete). Ha viszont egy picit tovább gondoljuk a dolgot, minden nagy alkalmazás nem más mint kis alkalmazások összessége, amik viszont játszi könnyedséggel integrálhatóak egy nagy alkalmazásba (ez a megközelítés egyébként is rengeteg előnnyel jár, mint pl. az egymástól független verziókezelés, stb).
Kliens és szerver oldali kódok az RPC hívások miatti duplikálása (ami sajnos mostanában elég bevett szokás), egy hibás koncepció. Rengeteg fejlesztő duplikálja a DAO kódokat (pl. egy tábla leíró osztály), hogy a gwt számára a böngészőbe át tudja adni a benne lévő adatot. Erre nincs szükség. Amikor a gwt fordít, akkor a gwt fordító fordít, amiből javascript lesz. Amikor a java fordít abból pedig szerver oldali java class fájlok. A két folyamat eltéréséből adódik, hogy megtehető az, hogy a gwt fordítás alatt az ember picit más class-okat használ fel, mint a java fordítás alatt.
Egy életből vett példa, hogy érthető legyen:
Tegyük fel, hibernate-t használunk, és csinálunk egy partner osztályt:
@Entity
@Table(name = "Partner")
public class Partner {
…
@Id
@GeneratedValue
@Column(name = "PARTNER_ID")
public long getId() {
return this.id;
}
…
Ha ezt gwt oldalon el szeretnénk érni két általános dolgot kell tennünk:
– levinni a kódot a kliens oldalra
– implementálni az IsSerializable típust
A második dolog viszonylag egyszerű, ellenben amikor a kliens oldalra mozgatjuk az osztályt, akkor a gwt fordító kedvesen figyelmeztet, hogy kliens oldalon nem lehet szerver oldali komponenseket használni (mint a hibernate notáció).
Persze azért mondja ezt, mert nem tudja, hogy mi ezeket a kódokat kliens oldalon nem is akarjuk használni. A megoldás kézenfekvő, és egyszerű. A hibernate forrásából ki kell szedni azokat a fájlokat amiket kliens oldalon is használunk. A forrásban használt függvényeket meghagyuk, de az implementációs részt töröljük. Fordítunk belőlle egy olyan jar-t amiben benne van a forrás is, és a fordított funkció nélküli class fájlok, megmondjuk a gwt fordítónak, hogy tessék ezt használni.
A kód lefordul, a javascript a hibernate notációval ellátott, de funkcióval nem rendelkező osztályokat használja, ellenben amikor ez az adat felkerül szerver oldalra, ott már a hibernate funkcionalitás is elérhetővé vállik, nincs szükség az osztályok duplikálására.
Ugyanez az elv használható a validációk során is, a jól megírt validációt végző keretrendszer minden esetben használható mind kliens mind szerver oldalon (optimális esetben notációkkal, pl. a hibernate által használt dao osztályban… ).
Részemről a geek hajlamok ezzel letudva a hétvégére 🙂