AJAX fejlesztés, JAVA-ban?

Teljes a letargia. Ugyanis, bár végre megtaláltam álmaim AJAX-fejlesztő stackjét:

  • GWT

    • - JAVA, tehát statikus típusosság, kevesebb használatkor előkerülő értelmetlenül bennfelejtett bug.

  • GWT-RPC

    • - továbbra is JAVA, serializálható objektumok átmennek rajta, nem kell saját objektumban definiált hibaüzenetekkel bajlódni, illetve kliens (böngésző) oldalon osztályokat újraimplementálni

  • JPA

    • - 1000 sor fölött már ne kelljen SELECTeket írogatni

  • GWT Persistence

    • - Újracsomagolt javax.persistence osztályok a GWT kliens oldalára, hogy az RPC-hívások entitásosztályokkal történhessenek

  • EXT-GWT

    • - Az EXTJS tudása, és szép UI-ja, JAVA osztályokba csomagolva.

  • Glassfish

    • - Rögtön alkalmazásszerver, hátha az EE architektúra egyéb jóságai is kellenek.

  • NetBeans

    • - IDE, hogy az entitásosztályok, a hozzá tartozó kontrollerek, stb. automatikusan generálódjanak

  • GWT4NB

    • - GWT fejlesztői plugin netbeanshez.

Ha valakinek van kedve, játszon vele, én is megtettem, nagyon jó architektúra

LENNE, DE LASSÚ!

A gwt compiler olyannyira lassú, hogy az már szinte használhatatlan. (google://gwt+slow+compile, lehet szemezgetni).

Nekem mindenféle beállítások mellett lement 30mp körülire egy fordítás, a fenti kiegészítőket mind használva egy egyszerű gomb, és a hozzá tartozó listenerből álló kód viszont majd' egy percig fordul, mi lesz akkor később, több ezer sornál...

Ha valakinek van tapasztalata, ötlete, tippje, egyebe vagy ezekkel a technológiákkal kapcsolatban, vagy már megtalálta álmai vágyát valami más fejleszői stack formájában, ne legyen rest megosztani!

Update:
A gép egy ThinkPad T61, Core2Duo T7300-zal (2GHz), és 2GB memóriával, Ubuntu Karmic 9.10, EXT4 fájlrendszerrel.

( bambano | 2010. 04. 18., v – 11:00 )

elfelejtettél megemlékezni a géped teljesítményéről, úgyhogy az a lassú:P

arról én nem tehetek, hogy szövegértelmezési problémáid vannak.
az összetett mondat első tagmondatában azt firtattam, hogy nem írt semmit arról, hogy milyen gépen futtatja, a második tagmondatban van egy mutatónévmás, az "az", a magyar nyelv szabályai szerint következik, hogy az "az" a pc-jére vonatkozik.
tehát a mondatom a kedvedért átfogalmazva azt jelenti, hogy amíg nem tudjuk, min futtatja, addig a pc-jére is rá lehet kenni.

( sashee | 2010. 04. 18., v – 11:05 )

GWT-t én is használtam, és nagyon bejött. Még anno az 1.x-et, ott is elég hosszú volt a fordítgatás. Azonban úgytudom, hogy a 2.0-ban már böngészőplugin végzi, és a kipróbáláshoz le sem kell fordítani, egyből a java kódot futtatja. Itt látok hozzá leírást:

http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugg…

Én ezt még nem próbáltam, de érdekelnek majd a tapasztalataid vele kapcsolatban.

( uid_952 | 2010. 04. 18., v – 11:13 )

Csak deploy-kor kell fordítani, fejlesztés közben nem. Azért is olyan lassú mert vagy öt különböző böngészőre lefordítja.

( zidane2005 | 2010. 04. 18., v – 11:14 )

Igaz nem ismerem a GWT-t és a hozzá felsorolt cuccokat, csak hallottam már róla. Felsorolt dolgokra nem tudok ugyanilyen alternatívát, de esetleg nézd meg a JSF implementációkat (IceFaces, PrimeFaces stb..). GWT-RPC helyett esetleg JAX-RPC esetleg JAXB-vel Java->JSON. Bár ha jól értem, akkor erre nem lesz szükséged, mert EXT-GWT-hez kellene.

A IceFaces ugyanúgy használ js-t, ami kliens oldali.. Mivel itt a GWT-ről és a GWT RPC-ről, beszélünk, amit szerver oldalon Servlettel lehet legegyszerűbben kezelni, így mindenképpen kell lennie egy web containernek. Ha az van, akkor már mindegy, hogy IceFaces-zel generáljuk a gui-t vagy gwt-vel... Annyi a kettőközt a különbség szvsz, hogy a GWT-t könyebb js-ben mahinálni. Ugyanakkor az IceFaces-t is lehet, csak az nem enterprise ready már annyira;)

( XMI | 2010. 04. 18., v – 12:03 )

Ha amúgy Eclipse a barátod, akkor érdemes lehet megnézni a RAP-ot.
---
Internet Memetikai Tanszék

Inkabb letezo RCP projektekbol. De ez is attol fugg, hogy a letezo projekt milyen SWT/JFace libeket hasznal...draw2d peldaul nincs. De majd meglatod, a RAP meg kliensoldalon lassu, mivel a generalt esemenyeket szerveroldalon dolgozza fel (minden kattintas=egy uj ajax lekeres, es valasz, stb).

Arra szolgal, hogy a szerverre atvigye azonnal az allapotmodosulasokat, meg esemenyeket (hiszen maguk az esemenykezelok a szerveren futnak le.)
http://rap.eclipsesource.com/rapdemo/rms
Itt nezd meg egy Firebuggal vagy mas eszkozzel, hogy milyen XHR-ek futnak le es mikor. Csodalkozni fogsz.

( persicsb | 2010. 04. 18., v – 15:36 )

AJAX fejlesztes desktop fejleszteshez kepest mindenkeppen hatalmas szivas. A JS nyelv butasagai meg hagyjan, de amikor a CSS es a kulonfele rendererek nem ertik meg egymast (vagy CSS-t KELL hackelgetni), na az mar nem annyira okes. Foleg, hogy sokszor elvarjak az azonos funkcionalitast egy desktop aphoz viszonyitva (slider widget stb.).

Nézd meg hogy hogyan lehet integrálni a zkoss-t és a gwt jsf-el, hibernate-el, jsp-bel.

Hogy lehet MVC-zni a kettőben, eventeket lődözni és figyelni, pre- és post-render szépen, egyszerűen. Pure java a kód, zul a gui és ha akarod css a skin. Szépen szeparálható, valóban kevés kód.

De a legütősebb szerintem, hogy nézd meg mi megy előre a browserben (ég és föld a kettő), nézd meg hogy egy server oldali zul vagy controller átírása után milyen gyorsan lehet autodeploy segítségével jetty vagy tomcat alá belőni a változtatást. Igen kb 5 másodperc a browser refreshel együtt ha nem beanezel hanem csak servletelsz. De lehet még mesélni az okostelefonos változatáról, a debugolhatósága élmény. (zul csak gui, controller pure java) és végre a Threadgroup-os mem leaket is kijavították :D

( kmARC v | 2010. 04. 19., h – 00:50 )

No, most hogy szélesedett a látóköröm, már csak egy kérdés (ha el nem veszik a többi blog között ez):

GWT (EXT-GWT), ZK, Vaadin. Ki mit ajánl, és miért?

A GWT és a ZK felépítésében jelentős különbség ott van, hogy mit csinálnak a szerver és a kliens oldalon.

A GWT több logikát tol a kliens oldalra javascript kód formájában. Ennek vannak előnyei és hátrányai egyaránt. A szerver terhelése kissebb lesz, cserébe a bonyolultabb javascript kódot minden egzotikus böngészőn tudni kell futtatni (ezt a GWT elintézi).

A ZK a javascript oldalra csak egy vékonyabb javascript réteget tesz, ellenben minden, még az egyszerű event handlerek is szerver oldalon, java kódban futnak. Ennek is van előnye-hátránya: a szervert és a hálózatot jobban terheli, ellenben tisztább és egyszerűbb az architektúra és az implementáció.

A ZK-t használtam, azzal kifejezetten élmény dolgozni. Viszont én a helyedben adnék még egy esélyt a wicketnek, az az egyik legtisztább web framework, amit eddig volt szerencsém látni. Noha wickethez nincs annyi szép gyári komponens, de megéri kipróbálni.

A Vaadin-es tapasztalatok engem is érdekelnének, ha valaki játszott már vele.