Az ajax file upload és a gonosz flash

Próbálgattam AJAX-os file upload cuccokat JQuery-hez és elsőre majdnem bedőltem az uploadify-nak. Egy kis időt eltöltöttem azzal, hogy a file feltöltés miért nem látja a szerver oldali session-t, teljesen azt hittem egy ideig, hogy a szerver oldalon szúrtam el valamit. Pedig nem: az uploadify flash-t használ feltöltéshez és a flash figyelmen kívül hagyja a cookie-kat. Ezt már hallottam mástól is, csak nem jutott át az ingerküszöbön.

Gyorsan át is gyergeltem erre a másik ajax upload cuccra, ez teljesen jól működik idáig, nincs benne flash, bár a skineléssel akadt problémám de az valószinűleg inkáb abból származik, hogy CSS-ből még mindig kettes alát érdemelnék.

RIA kalandok

Hát igen, jó hosszú történet, ugyanis a kliens oldaltól mindig próbáltam magam távol tartani. Nyilván a CV-ben sem áll jól, ha valaki nem pöpec a teljes alkalmazás stack minden apró elemében, meg elkezdett érdekelni is a téma.

Szóval a hosszú történet...

OpenLackó

Úgy kezdődött, hogy OpenLackó. Az OpenLaszlo volt nálam az első és eleinte marhára bejött, hogy én is tudok olyanokat csinálni benne, mint a UI guruk.

Előnyök:

1. Tényleg marha gyorsan össze lehet dobni a felületet.
2. Alapértelmezésben is szép.

Hátrányok:

1. Szőrös RPC megoldások. Például minden hívást a laszlo szerveren keresztül akar végrehajtani. Minek? "Java RPC" - public static metódusokat lehet vele hívni. Csúnya dolgokat kényszerített ki a szerver oldalon.
   
2. Horrorisztikus fejlesztési menet. Dobáljuk be a lzx fileokat a laszlo szerverbe? Miért nem lehet inkáb beágyazni az egészet?
3. Nem igazán indult be a komponens-piac, talán éppen a fentiek miatt.
   

Flex + BlazeDS vagy amit akarsz

A flex-ben amit elsőre megszerettem, az az hogy végre normálisan néz ki a RPC. Hívhatunk teljesen szabványos SOAP hívásokat, vagy kicsit cifrább mulatságba is belemehetünk BlazeDS-sel. Extra a lackóhoz képest az is, hogy nem kell a runtime környezetbe beletolnunk semmi flex specifikus dolgot. Egyből 40 megával kissebb a war file, hoppá.
Előnyök:

1. Sokféle és használható RPC. Akár szerver data push is.
2. A data binding szerintem király.
   
3. Nem feltétlenül akar valami spécit a szerver oldalra.
4. Kiválló maven plugin :)
5. Sokféle free UI komponens és library a neten.
   

Hátrányok:

1. Pokolian lassú fordító.
2. Hát van a flexbuilder, ami pénzes windowsos, akkor már egy új gépet is kellene vennem... Valamint összedobtam egy gyors plugint régebben, ami semmi mást nem csinál, csak lefordítja minden módosításra a flex kódot. Ezek nélkül azért meg lehet lenni.
   

ZK

Erre egy volt munkatárs hívta fel a figyelmemet és nagyon örültem is neki. A zk király... bizonyos dolgokra.
Előnyök:

1. Nem kell IDE :) Simán eclipse-ből editálva a zul fileokat háttérbe futó jetty-vel ment minden mint karikacsapás. Nagyon gyorsan lehet vele haladni. Módosítás esetén is villám gyorsan újrafordít.
   
2. Tiszta html.
3. Nagyon egyszerű és működő spring integráció.
4. Akadnak hozzá hasznos kis extra komponensek, egész könnyűnek tűnik sajátot írni. Az alap csomag is rengeteget tartalmaz.
   

Hátrányok:

1. Nekem úgy tűnik, borzasztó sokat nyúl a szerverhez. Nem tudom róla leszoktatni. Mindenért a szerverhez szalad.
   
2. Szerver oldali session-t nyit, egész nagyot. Skálázhatósággal nem tudom hogy állhat.
   

Szóval bekategorizáltam, hogyha egyszer valami csili-vili intranetes dolgot kell majd csinálni, akkor új lehetőségeket kap.

Google Web Toolkit

Hát ezzel odáig jutottam, hogy végigcsináltam egy tutoriált, és amikor oda jutottam hogy lefordít, akkor olyan botrányosan lassú volt, hogy fejvesztett menekülésbe kezdtem és azóta nem merészkedtem vissza. További információk így nem derültek ki.

HTML + JS + jQuery

Végülis feladtam és elfogadtam, hogy meg kell tanulnom javascriptet használni. Kicsit új eszközöket kellett keresgetnem ehhez, tényleg olyan érzés volt, mint gimi után C-ben kalapálni. A jQuery-t egy munkatársamtól lestem el, ő egekig magasztalta.
Előnyök:

1. Még csak nem is jsp. Statikus html. Akármilyen IDE elegendő támogatást ad hozzá. Jó, mondjuk az eclipse javascript képességei tényleg nem tűnik valami nagy pukknak
2. A SOAP-ot nem próbáltam, de a REST hívások simán mennek. Csak az megy át a dróton, amit az ember programoz. Alacsony szintű ajax megszelídítve.
   

Hátrányok:

1. Még felfedezés alatt áll, de a UI library nem olyan nagyon frankó még.
2. Alacsony szintű összeakadások. Például beleraktam egy google map-et egy dialog-ba, és hát voltak vele bajok, kicsit elcsúszott a google map. Nem tudom miért, kicsit erősítenem kell még javascrptből.
3. Szerintem az olvashatósággal vannak problémák, de lehet hogy csak nekem kell még megtanulnom olvasni.
   

Ez a helyzet idáig. A véleményeteket és útmutatásaitokat természetesen örömmel látom.

Flash kereső ?= RIA kereső

Mostanában nagy hírverést kapott, hogy a Google és a Yahoo az Adobe együtműködésével megtanulja indexelni a flash tartalmakat is. Egyrészt vidámság, mert előrelépés, viszont nem hiszem hogy ez olyan nagy dolog lenne. A "web 1.0" webappokban a tartalom belegenerálódik a kimeneti html-be, a keresőmotorok tulajdonképpen még mindig dokumentumokat indexelnek, még ha azok dinamikusan generált cuccok is. A RIA cuccokban viszont a dokumentum kb üres, a kliensen futó scriptek hozzák le a szerver oldalról. Erről már nem szólt a hírverés, de ezeket gondolom nem fogják belevenni az eredménybe, mert Gipsz Jakab scriptjeit nem akarják futtatni a szerver oldalon, soha nem akarták.
Gyanús, hogy a lényeg így egyelőre kimarad...

Vagy generál valaki tartalmat flash kimenetbe?

Az ördög bal keze

Mostanában kicsit csend volt itt, elég sok meló van mostanában és -mint az közismert- vizsgaidőszak, az meg ultra-aljas egy dolog.

A flexclipse pluginnel kalapáltam kicsit szabadidőmben.
Elmesélem:

1. Ami volt editor benne, azt az eclipse egy varázslója generálta. Első pillanattól biztos volt hogy ki fogom vágni, és ezt meg is tettem. Lecseréltem a WTP XML editorára. Ennek a pluginnak lehet bizonyos konfigurációt is passzolni.
2. Például Hyperlink támogatás, code completion support, quickfix és quick assist.
3. Vannak viszont a téren érdekes dolgok, például nem publikus apiba kell belenyúlni.
4. Egyébként: megcsináltam a libraries támogatást, lehet majd swc library-kat belinkelni.
5. Arra rásejtettem, hogy az eclipse önmagában is hatalmas API halmaz. Legalább olyan komplex mint pl a JEE.
   

Most elhúzok dokihoz, a vicc kedvéért ő fogja megmondani hogy most mi legyen a műsor. Ugyanis tegnap elütött egy barom, elég rondán megzúzta a vállamat. Lehet hogy egy ideig nem dolgozhatok, elég szar így bal kézzel. Viszont egy csomó időm lesz, mivel most sportolni se tudok járni. Olvashatok valamit például...

Flexclipse 0.1.3 - araszolós

Remélem jól tellett a hétvégétek, az enyém egész sűrű volt. Nem volt sokmindenre időm, de azt sikerült beledobni a flexclipse-be hogy egy saját file-ba dobálja be a konfigurációját. Eddig a project metaadatokat használtam erre. A project metaadatokat az eclipse a workspace-ben, de a project directory-n kívül tartja (a .metadata könyvtár, gondolom ismerős :) ) Most ez azért jobb, mert verziókezelőben meg lehet osztani, esetleg lehet generálni mondjuk maven pomból. Fel is tettem egy gyors howto-t az egész cuccról. Simán látszik belőle mennyire kezdetleges az egész :)

Most erről a verziókontrol dologról eszembe jutott hogy holnap reggel megint egy perverz verziókövetőt kell rugdalnom. Minden héten háború.

Update: Közben Happy kijavította egy elvetemült dolgomat a kódban, azaz megvan az első contributor :-) mégfontosabb hogy sok hasznos tanácsot kaptam. Hétközben remélem akadgat majd időm javítani a cucc kinézetét, és akkor lesz update site...

Flexclipse 0.1.2 @ googlecode

A flexclipse kódját átmozgattam az otthoni svn-ből a googlecode-ra, és megvan az első tag (0.1.2) is azóta. Ha akad időm ma este, össze ütök egy kis howto-t hozzá. Azok vannak benne amiket eddig felsoroltam, még estére talán ad valami támogatást a skinezéshez (CSS) is.

Meg keresek még helyet update site-nak...

Flexclipse még mindig...

Tegnap este még maradt időm két dologra a Flexclipse prototype projectben:

1. Belerúgtam egyet a project icon decoratorba. Most a flex projecteken gyönyörű (soha ilyen szépet nem rajzoltam) ikon ragyog.
2. Összekötöttem a flex compiler progressmonitorát az eclipse progressmonitorával. Hát értelmes eredményt nem sikerült ezen a téren látni, még utánna kell nézzek hogy vajon jó hívásokat küldök az eclipse felé.

Ennyi ami késznek mondható most. További félkészületek:

1. Átbogarásztam az ASDT-t és próbáltam kitalálni hogy hogyan tudok belőle kiszedni valami hasznosat.
2. Megcsináltam az Outline adaptert a ASDT-hez, legalábbis a dummy implementációt. Most frankón nem látszik az egészben semmi.
3. Elkezdtam utánnanézni az XML editornak. Alapvetően ez az egész csak XML, az lenne frankó, ha egy XML editor kiterjesztésével tudnám az egészet hajtani.
4. Leszedtem a spring IDE forráskódját, hátha abból megvilágosulok az XML editorokkal kapcsolatban. A spring IDE tényleg frankó módon tudja editálni a context XML-eket. Van benne code completion is, hiba highlight, szóval a lehető legjobb dolog ihlet beszerzésére.

Ennyi. Ezek még lassan befutnak, aztán meglátjuk...

Az eclipse útvesztőiben

Nézzük, mi az ábra a flex3 eclipse tákolással...

• Nagyjából megy a builder, igaz nem inkrementális, de hát ez van egyelőre.
  
• Pár ikon-dekoráció megtalálta a helyét. Én rajzoltam az ikonokat, mind az eggyet. Esztétikára nem adunk.
  
• Van kettő wizard is, ebből csak az egyik működik :-D

Ami még minimálisan szükséges lenne a használhatósághoz:

• Maven-hez flex3 mojo. Csak flex2-es van jelenleg
• És persze rendesen gatyábarázni
  

Air on linux (Alpha) gyorsteszt

Van Air runtime linuxra is végre, az internet magamfajta, másodosztályú állampolgárainak örömére. Vasárnap fel is húztam az itthoni gépemre hogy megnézzem mit tud.

• A telepítőcsomag mérete tűrhető (16M)
• Alpha létére eddig még nem hasalt el egyszer sem
• Viszont szembetűnően zabálja a processzoridőt. Ezt windowson nem csinálta. Valószinűleg a friss fedorám valami csúnyát csinált a grafikus driverrel, mert más is izzad vele, azt hiszem különösebben ezzel nem lesz gebasz.
• Az határozottan nem tetszik hogy a saját és pedig a air csomagok felinstallálásához is root jelszót kér. Hát ideiglenesen megbíztam ennyire az Adobe-ban, de ebből nem csinálnék rendszert.
  

Lassan, ahogy akad időm kipróbálom hogy mennyire jó dolog rá alkalmazást írni.

Közben lökdöstem tovább a Flex nature implementációmat eclipse-hez, beleakadtam az első eclipse specifikus problémákba is, de azért haladgatok...

Heti helyzet

• Kijött a Sonar 1.2. Mostanában nagyon érdekel ez a szoftver és próbálom nyomni a munkahelyemen is. Sajnos maven-hez passzol igazán, ant-tal falábú, meg hát vannak neki egyéb korlátai is :( Viszont kezd nagyon jó cucc lenni, amikor a korlátok nem zavarnak.
  
• Egy kis Drools prototipus projectett tervezgetek. A melóban a kódunk legnagyobb része az üzleti döntési folyamat lekódolva, mint mindenkinek. Majdnem mindenkinek. Persze így is le lenne kódolva, csak legalább nem a flow logikában :)
• AMF data push-hoz kisérletezek valami általánisított megoldást, hogy körülbelül spring applicationContext-ben lehessen megmondani - interceptorral persze-, hogy melyik metódus hívása milyen csatornára küldjön update-t. Ezzel használhatjuk a primitív DAO osztályainkat tovább, amiket esetleg más projectekből vettünk át. Az adatok real-time replikálódnak DAO-t éppen használó a kliensekhez, annélkül hogy ehhez blazeds-specifikus kódot kellett volna belegyűrni a logikába. Na ennek is meglesznek a maga korlátai :)
  

Gyagyascript korlátok

A kis kutatóprojectemben miután párszáz földrajzi objektumot feltérképeztem (az immár nagyon kezes geo-google segítségével :) ), majd a köztük lévő 4-5000 kapcsolatot is összeszedtem, tegnap este eljött a várva várt pillanat hogy a Google Maps rémegyszerű apiján keresztül megjelenítsem.
Nos, ha a párszáz földrajzi pont nem is lett volna fájó pontja a kérdésnek, akkor a néhányezer kapcsolat köztük biztosan, és itt fényes bizonyítékára akadtam annak, amiről Auth Gábor mesélt a legutóbbi JUM-on: a javascript-re nem lehet ekkora adatokat bízni. A párezer vonal berajzolása a térképre teljesen megfogta a processzoromat pár percre és a firefox felzabált egy tonna memóriát.
Mivel ekkora mennyiséget igazából csak tesztadatnak szántam, most az az ötlet, hogy ajaxosítom a pontok és kapcsolatok felhozatalát és a térképnek csak azokat a pontjait és kapcsolatait szedem fel az adatbázisból, amik a megjelenített részen találhatóak, azt is csak valamekkora limittel, mondjuk a legnagyobb súlyú kapcsolatokból úgy százat. Azt sajnos már most látom hogy ez viszont elég szűk korlátokat ad a használhatóságnak.