Dojo 0.2.0

Sokat hallottam már erről, de nem tudtam micsoda. Ez egy open source javascript könyvtár ami egyszerűbbé teszi a web programozást. Most jött ki 15.-én a 0.2.0-s verziója, de első látásra demókat nem nagyon találok. A Unit teszteket lehet nézegetni. http://dojotoolkit.org/

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.

Spring intro

Elolvastam ezt az elég átfogó cikket a Springről. Mit is tud a Spring tulajdonképpen? Ez egy ilyen zselészerű dolog amibe belenyomogatunk objektumokat és elkezdenek működni -persze most nagyon képletes voltam.

Szóval az a lényeg, hogy POJO-kat (Plain Old Java Object) írogatunk B logika gyanánt és Spring interface-eket implementálgatunk, közben követjük a JavaBeans szabályait (getterek, setterek) és az objektumokat be lehet tenni Spring konténerbe, ami ezután EJB-ként tud például viselkedni.

De van tranzakciókezeléses rész ami teljesen más terület.
Van MVC-s szervletes rész ami a Struct-hoz hasonló (a cikk megemlíti a Struts-ot mint versenytársat).
SQLException-öket is wrappel, ez is külön terület és van O/R réteg ami együttműködik Hibernate-tel meg mindenfélével.
Van valami AOP-os rész, (Aspect Oriented Programming) azt nem nagyon értettem.

Jó dolog ez, csak nem értem miért vettek mindent egy kalap alá. Még majd írogatok róla. Ha jól tévedek hamarosan közelebbről is megismerkedek vele.

Ja igen, még ami feltűnt hogy vannak Spring tréningek. Potom 2000 euróba kerül egy három napos kurzus. Kösz.

Ruby On Rails

Már több helyen is hallottam erről a hype-ról, de azt hiszem a prototype-os ürge honlapján is láttam egy konkrét linket ami miatt kapcsolatba hozható a RoR-ral. (Majd leírom pontosan de most sietek.)

Szóval a Ruby a nyelv amiről itt van egy jó kis leírás, (script jellegű gyengén típusos objektumos nyelv) a Rails pedig a framework ami könnyebbé teszi a fejlesztést. A http://www.rubyonrails.org/ -on látható egy 50 megás videó ahol az idegesítő hangú srác 15 perc alatt összerak egy blogmotort.

Én is gondolkodtam már a 3tier alkalmazásainkat fejlesztve hogy jó lenne kifejleszteni egy automatikus "hidat" ami összeköti az adatbázist, a megjelenítése réteget és a B logikát. A Rails kb ezt csinálja. Ahogy szerkeszti az entitásokat (grafikusan) megjelennek hozzá a webformon a mezők és az adatbázisban az oszlopok. Nem rossz, de az megjegyzendő hogy ehhez nem kell Ruby -legalábbis ahogy most látom.

Prototype

A prototype egy jó kis kliensoldali javascript framework ami segít Ajaxozni és matatni a DOM-ban. Itt van róla egy tutorial, meg itt is a
24ways-on, meg itt is. Ezek az infók pedig az Ajaxian-ról származnak.

Struts Overview

Éppenhogy csak elkezdtem olvasni a Struts User Guide Preface-ét, máris sok dolgot találtam amivel meg kéne majd egyszer ismerkedni:

• JSP Standard Tag Library (JSTL)
• Java Server Faces (JSF)
• Java Authentication and Authorization Service (JAAS)
• ...a többi a preface-ben.

Az hogy a Struts micsoda, egyelőre homályos.

Közben elolvastam a többit is. Nem igazán nyerte el a tetszésemet, de ebben lehet hogy az is közrejátszott, hogy az egész doksiba képtelenek voltak berakni egy árva képet, diagramot vagy mittudomén mit. Értem én hogy szükség van az MVC patternre és az jó is (nem is tudtam hogy a Smalltalk-ból jön) és azt is értem hogy ez a Struct próbál lenni a C (controller) az MVC-ben, csak ezek a hülye konfigolások meg a validálás lehetősége nem tetszik.

Validáláshoz vagy kell a business logika vagy nem. Ha nem kell akkor eleve el lehet intézni kliensoldalon ha kell akkor meg úgysem lehet megcsinálni a Modell megkerülése nélkül. Persze ha úgy vesszük hogy nem létezik javascript, vagy nem szabad használni, akkor hasznos ez a funkció.

Konfigolás: nem elég hogy meg kell írni a formot és a Modellt, még egy közvetítő objektum is kell, amit XML-ben kell konfigurálni. Nem lehetne ezt valahogy automatizálni?

Még nem gondoltam át ezt rendesen, úgyhogy lehet hogy még majd változik a véleményem.

Viszont ahogy belenéztem a Struct Shale alprojekt overview-jébe, ott arról írnak, hogy közben már készül a régi framework utódja, a Shale, amit már modernebb szempontok szerint terveznek és épít az újabb technológiákra. Meglátjuk. (Az eredeti Structs-ot 2000-ben kezdték el csinálni, akkortájt amikor a JSP megjelent. Akkor még nagy szám volt és mostanáig elég sok webalkalmazást készítettek a segítségével.)

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.

GPL flame

Jó kis flame alakult ki az Index Programozás fórumában az open source programozásról illetve az ezzel kapcsolatos megélhetési lehetőségekről. Szokás szerint elbeszélnek az emberek egymás feje mellett, de egyébként van benne igazság. (Attól hogy valami "open source" még nem következik belőle hogy GPL.)

A GPL a totál nyílt cucc, amibe bele van építve azért sem lehet pénzt kérni. Ez késdöfés azoknak az oldalába akik olyan szoftvert fejlesztenek amiből van hasonló minőségű GPL-es cucc. Vagyis rákényszeríti őket hogy jobb minőségű szoftvert és/vagy supportot adjanak a termékükre. Abból a szempontból jó ez a világnak, hogy versenyt teremt. Gyér minőségért nem lehet pénzt kérni.

ASP.NET oldal életciklus

Még régebben utánanéztem egy ASPX oldal életciklusának és lefirkantottam. Íme:

"Bejön a HTTP kérés az IIS szerverre. Ez a HTTP pipeline-n (HttpRuntime, IHttpHandler, IHttpHandlerFactory, ProcessRequest()) keresztül eljut az oldalhoz. Minden .aspx URL-hez ugyanolyan nevű aspx tartozik. Amikor az URL első alkalommal meghívódik az aspx forrás lefordítódik és egy assembly készül belőle.

Az oldal ProcessRequest metódusa hívódik meg.

Felépíti az oldalon található kontrollok hierarchiáját.

Init esemény generálódik.

Feltölti a kontrollokat a viewstate-jeikkel.

LoadPostData hívódik meg azoknál a kontrolloknál amik implementálják a IPostBackDataHandler-t. Itt még NEM szabadna eseménykezelőt indítani, mivel a viewstate még nincs feltöltve! Ehelyett, ha a LoadPostData true-t ad vissza később meg fog hívódni a RaisePostdataChangedEvent metódus.

Load esemény generálódik. Ekkor már be vannak állítva a kontrolok a kliensoldali interakcióknak megfelelően.

Ha van ilyen, meghívódik az eseménykezelő ami miatt a postback keletkezett. Ez az a bizonyos RaisePostDataChangedEvent metódus.

PreRender esemény generálódik. Ide még lehet olyan logikákat rakni ami az eventkezelés után és a renderelés előtt szükséges.

Aztán rendering módba kerül, legenerálja a HTML kódot és elküldi a választ.
Unload esemény generálódik.

Ha dupla request keletkezik, pl. egy gomb kétszeri megnyomásával, akkor az szépen beáll a queue-ba és végrehajtódik mindkét kérés."

GUI-t mindenki tud tervezni?

Első munkahelyemen telefonokra fejlesztettünk szoftvereket és jó kis alkalmazástesztelő csapat volt, akik minden fölösleges gombnyomásba vagy kihasználatlanul hagyott területbe belekötöttek -és igazuk is volt. Baromi hosszú könyveket tudnak írni gui fejlesztésről, ami mondjuk kicsit túl van spirázva de azért van benne igazság.

Dehát a számítógép nem telefon, mindent lehet. Lepedő méretű üres helyek, 10 klikkelés ha eggyel is meg lehet csinálni valamit. Jobb esetben a fejlesztők legalább agyalnak rajta valamennyit hogy a gui milyen módon működjön logikailag, de a megrendelő kitalál egy neki tetsző esetenként dilettáns megoldást anélkül hogy továbbgondolná. Rosszabb esetben a fejlesztőnek sincs érzéke a témához. Nem is tudom mi kell ehhez, talán empatikus készség és egy kis kreativítás ötvözete.

A címben feltett kérdésre a válasz: nem.

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"...

Active Record antipattern

Update 2009.05.22: Szerencsére ma már vannak jól kialakult perzisztencia framework-ök (a JPA-ról nem is beszélve) és a kultúrált programozók DAO-kkal dolgoznak, de nemrég találkoztam olyan emberrel aki éles projektben komolyan használni akarta ezt a design pattern-t. Ráadásul egy másik postban más okból is linkeltem erre a rövid kis agymenésre, szóval kicsit megcizellálom.

Szóval az Active Record design pattern dióhéjban arra épül, hogy az objektum maga tudja, hogyan kell őt beolvasni vagy legalábbis kimenteni valami adatbázisba. Tehát van save metódusa, ilyesmik.

Első probléma, hogy rögtön kell az objektumba injektálni valami adatbázisközeli logikát, ami másrészről nem jó helyen van ott, hiszen fölösleges függőséget hoz be a domain modell entitásaiba. Ha nem elég flexibilisre van megcsinálva ez a logika akkor a hordozhatóságnak annyi, pl. nem lehet kicserélni alatta a perzisztencia réteget. Van erre két megoldás: egyik hogy örököljük ősosztályból a logikát, nade ekkor is felülről (még rosszabb) betámadnak az implementációs részletek a domain modellbe. Ebben az esetben ráadásul el kell lőni az egyetlen öröklési lehetőséget (Java, C#) az implementációs részletek miatt. Na és mi van ha még a domain modell miatt is kéne örökölni? Pech. Másik megoldás a logika delegálása. Igen, ez működhet csak ügyelni kell rá hogy az objektumokhoz hozzá legyen cuppantva a logika ami kimenti őket.

Második probléma, hogy ha ezeket az objektumokat neadjisten másra is használni kell, felbugyoghatnak a szervíz rétegből a GUI logikába, félreeső modulokba. Például valaki véletlenül mond ott egy delete-et és szevasz aktív rekord - automatikusan mindenki számára publikálja a műveleteket. Egy jól leválasztott szervíz réteg esetén jól meg lehet határozni, hogy melyik modul milyen interfészt kap meg.

Hozhatnék még fel ilyen kérdéseket, hogy vajon minden adatbázis rekordhoz van egy aktív rekordunk a memóriában? Pazarlás. Minek? Stb.

A régi posthoz még annyi bevezető, hogy néha (ez már WTF kategória) a konstruktor meghívásával generálják az adatbázis rekordot, tehát a new Person('pcjuzer') valóban adatbázis műveletet von maga után. Csakhogy...

Innen pedig a régi post:

A konstruktornak van egy olyan tulajdonsága, hogy a lefutása után csakis egy újonnan inicializált objektum referenciáját tudja visszaadni. Tehát sem null-t, sem a hívás előtt létező objektum referenciáját nem tudja visszaadni.

Bevett gyakorlat, hogy egy objektumpéldányhoz egy adatbázis rekord tartozik. (Egyébként nagyon okos neve van a megoldásnak: Active Record. Annyira okos, hogy még céget is elneveztek róla.) Ha ezt az objektumpéldányt a konstruktorral akarjuk kiolvasni az adatbázisból, akkor több konstruktorhívás több példányt fog eredményezni ami ugyanarra a rekordra mutat. Ez egyrészt erőforrászabáló másrészt inkonzisztens állapotot lehet előidézni vele, ha a két példányt megváltoztatjuk és ezután visszaírjuk az adatbázisba.

Ehelyett factory metódust vagy osztályt kell használni, ami egy pool-ból kiveszi a már egyszer feltöltött rekordok objektumait. Legalábbis az a.r. design pattern-en belül.

res.exe

Van nekem egy ősrégi CF kártyás DIVA mp3 játékosom ami sokáig kitűnően működött, mostanában viszont (jó sok minden változott a gépen, szervíznyirbálás is volt meg minden) nem ismerte fel a windows, csomószor fagyizott is. Másik USB-s eszközöket felismert, csak a DIVA-val volt gondja. Más gépen pedig szintén működött a DIVA, úgyhogy egyértelmű hogy az én gépemen volt a szoftveres hiba.

Próbálgattam visszaindítgatni a service-ket, párszor drivert installálni, jó sok idő elment, de az üdvözítő megoldást az adta, hogy a task managerben kilőttem az automatikusan induló res.exe nevű programot, ami akkor telepedett a gépemre amikor installáltam a külső USB-s HDD keretet.

Szemét res.exe.

(2007.05.05) A történet nem ért véget. Azóta jó sok pendrive járt a gépben, biztos jó sok driver installálódott. Mostanában nagy tömegű adatot akartam rámásolni a külső USB-s HDD-re és irtózatosan lassan ment a dolog. Az első néhány perc rendben ment, de aztán a másolás nagyon lelassult (párszáz byte / másodperc), a processzor kihasználtság pedig felugrott 100% közelébe. A task-ot nem is tudtam rendesen kilőni, vagy miután kilőttem, a processzorkihasználtság magas maradt. A megoldást ismét az adta, hogy lelőttem a res.exe programot. Ezután a másolás ismét a megszokott tempóban működik.

Még egy gondolat az USB-s HDD kerettel kapcsolatban: elvileg előnyösebb FireWire-t venni, mert a FW meghajtásához nem kell szoftveres segítség, az USB pedig lefogja némileg a processzort. Eredetileg én is FW-set akartam venni, csak vagy nem volt vagy ilyet sikerült adniuk.

Music XP

Mostanában az XP agyalapi működésének tanulmányozásával ütöm el az időt. Az a helyzet hogy van egy TASCAM US-122 USB-s audio (ASIO, 2 XLR mikibemenet fantomtáppal, direkt out, 24 bit, midi in/out, szóval valamivel több mint egy soundblaster) interfészem amit Cubase mellett hangkártyának használok és az utóbbi időben (mióta az SP2-t felraktam) néha ugrik a visszajátszás ami felvétel közben igencsak használhatatlanná teszi a rendszert, úgyhogy most nézegetem a fórumokat az www.absolute.hu -n és a tippeket a www.musicxp.net -en az XP turbózásával kapcsolatban. Majd meglátjuk mi alakul ki. Ha kiirtom a fél service parkot akkor kezd jobb lenni a dolog és kevesebbszer ugrik, de még ki kell kísérletezni.

Melóban meg aspx-es webkontrolokkal, xsl trafóval, transact-sql tárolt eljárásokkal foglalkozom. Még jó hogy javasemberként regeltem be...

C# dátumkezelés

A dátumokkal mindig van valami zűr, úgyhogy ha valamit megtudok ide beírom, és ha újra kell akkor itt megnézem.

A DateTime először is value típus úgyhogy nem lehet neki null-t beállítani. Ezt legegyszerűbben úgy szokták kiküszöbölni hogy DateTime.MinValue-t állítanak be neki ami 1970.01.01-es dátumnak felel meg. Nem kell mondanom hogy ennek mi a hátránya.

Dátumformázás C#-ban:

string s = "2005-03-28 06:50";
try  {
//see DateTimeFormatInfo for patterns
DateTime d = DateTime.ParseExact(s, "yyyy-MM-dd HH:mm", null);
Console.WriteLine(d.ToString("yyyyMMddHHmm"));
} catch(FormatException ex) {
Console.WriteLine("wrong date format.");
}

A DateTime value típus tárolja ugye a dátumot. A DateTime.Now adja rögtön vissza az aktuális dátumot, a DateTime Ticks propertyje pedig 100 nanosecundom "pontossággal" az óraütések számát. (Értsd.: 1 tick = 100 nanosec.) Ha a ticket megszorzom 10000-rel, akkor jön ki a milliszekundom. Loggolásnál hasznos.

Ha a mai nap kezdetére vagyunk kíváncsiak, akkor hasznos a:
now.Subtract(now.TimeOfDay);

Update 2008.07.23: Cikk a softwareonline-on a témában.

Import static

Azt hiszem néha fogom használni az 5-ös java statikus import funkióját. Meg lehet mondani pl., hogy import static java.lang.Maths.*; vagy statikus metódusnevet. Ésszel hasznos, amikor hatszázszor ki kéne írni egy osztály nevét amiből egyébként csak statikus tagokat használok. CTRL-Shift-O -ra (importok rendezése) az Eclipse a kézzel beírt import static ...*-ot lecseréli a valóban használt tagokra.

Subclipse

Eclipse/külső verziókövető használat mellett megesik a package explorer-be épített "delete" funkció használata, ha egy fájllal kapcsolatos utolsó módosításaimat nem akarom bekommitálni. Namost integrált verziókövetőnél (SVN) ezt jobb ha elfelejtem, mert szépen halkan a repositoryból is töröl (nem fizikailag és véglegesen). Ez bizonyos esetekben persze kényelmes -ha direkt ez a cél. Még szerencse hogy van a "revert" funkció. Egyébként tetszik a subclipse plugin, szépen ki lehet dekorálni hogy mikori verzió, ki a szerző, stb.

Joeblog

Efottozásból kifolyólag nem volt, most pedig munkahegyek miatt nincs post, viszont a joeblog-ot meg kell említeni mert mindenféle újdonságot és hasznosságot belinkel.

Pár naponta jön új cikk, általában ha megjelenik valami jávás cuccból új verzió. Hozzá lehet kommentezni, de nem nagyon szoktak. Érdekes hogy a bejegyzések magyarul vannak, a címek viszont angolul.

Firefox

A Firefox-szal kapcsolatos műveltségem eddig annyiból állt (ne üssetek!), hogy az is egy böngésző és hasonlít az Internet Explorer-re. Most már azt is tudom hogy a Mozilla nevű nonprofit jóemberekből álló alapítvány csinálja, opensource, több platformra megvan, 1.0.5 az aktuális verzió (a napokban jött ki) és itt lakik. Ja és az Explorer-rel ellentétben kiválóan mennek rajta az Echo2 és EchopointNG cuccok (egy füles szerint Firefox-on tesztelik). Amúgy tényleg impozáns. Nem pampog fölöslegesen, csinálja a dolgát.

A Mozilla egyben azt a kódbázist is jelenti amire a Firefox épül, sőt tulajdonképpen egy böngésző is. Van még kérdés? igen / nem.

A 6-os verziónál az éppen mélyrepülést végrehajtó Netscape-ék is úgy döntöttek hogy open source-szá teszik a kódot és összekötik az életüket az akkortájt készülgető a Mozillával. Aztán a 7-es Netscape gyakorlatilag Mozilla motorra épült, csak csomó kommerciális vacak hozzá volt toldva, úgyhogy nem szerettük. Ahogy 8-ast sem.

(2007.05.05-ös update) Most már a 2.0.0.3-nál tart a Firefox és érik a hármas is. Rengeteg hasznos és haszontalan plugint lehet letölteni hozzá és nekem bevált. Nade nem is kell félteni. Egyedül akkor voltam bajban, amikor IE-re készített szoftvert nem teszteltem IE-n csak FF-en és máshogy működött mint kellett volna neki.

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.

Post[0]

Hogy is néz az ki tulajdonképpen, ha én most bepostolok ide valamit?