JSF 1.1 Basic

Az alap JSF tudásomat frissítettem fel mostanában kicsit. A témában korlátlan mennyiségű változatos terjedelmű és minőségű anyag lelhető fel a neten. Maga a technológia viszonylag ódivatú a többi egyre jobban vastagkliens-irányba haladó framework-höz képest. Talán azért vettem rá magamat az átnézésére, hogy megadjam neki a végtisztességet.

Egyelőre ennyi link:
GuessNumber tutorial Egynek jó példaprogram, bár kicsit régi.
www.coreservlets.com API-k, mindenféle.

JSF-ről egyébként nem post-ot, hanem könyvet kéne -kellett volna- írni (nem is tudom hogy van-e jó magyar könyv), mindenesetre az alábbiakat véstem fel magamnak ad hoc, abszolút a teljesség igénye nélkül. Update 2008.07.23: A Szoftverfejlesztés J2EE Platformon című könyvnek van egy egész használható, JSF-fel foglalkozó fejezete. Azt hiszem mostanában elég sokat fogom ajánlgatni J2EE fejlesztéshez ezt a könyvet, pedig nem fizetnek érte. Ez egy kicsit szétszórt és dinamikus post lesz, szóval ha van valami amit nagyon megjegyeznivalónak találok, akkor azt beszúrom ide valahova. Meglehet hogy némelyik témát meg sem említem, némelyikbe pedig nagyon belemegyek. Ez van. Ez nem cikk hanem jegyzet.

Webalkalmazás konfiguráció

Sima szervlet technológiára épít, tehát a web.xml-ben kell megadni a Faces servlet-et, a mappingjét és a faces config fájlokat a javax.faces.CONFIG_FILES paraméterben, vesszővel elválasztva. Legjobb megnézni egy példát. Ha van /WEB-INF/faces-config.xml, azt nem kell explicite megadni, az magától betöltődik utoljára. Elvileg ezt nem is _szabadna_ megadni, de ki kell próbálni mi történik.

A JSF paraméterek prefixe javax.faces. Meg lehet még adni a JSF fájlok kiterjesztését (DEFAULT_SUFFIX), valamit az életciklusról (LIFECYCLE_ID) és azt, hogy az állapot a szerveren vagy a kliensen legyen lementve (STATE_SAVING_METHOD). értéke 'server' vagy 'client'.

Ha a STATE_SAVING_METHOD értéke 'client', akkor Base64 enkódolással, a com.sun.faces.VIEW hidden változóban van eltárolva a view a HTML-ben. Ebben az esetben a session timeout nem probléma. Meggátolja a form repost-ot. Ha server, akkor megadható a com.sun.faces.NUMBER_OF_VIEWS_IN_SESSION. A FacesContext-ben tárolódik el a state.

Itt van még némi infó a szabványos JSF konfigurációs paraméterekről.

Alkalmazhatók még saját, nem-standard paraméterek is.

JSF életciklus

Bő lére eresztett leírás a JSF életciklusról itt.
Összefoglalva:

• Restore view postback esetén előkeresi az elmentett view-t, init esetén felépíti a view-t és elmenti
• Apply request values a request paramétereket beteszi a view-be ha meg van adva UI komponensben immediate, itt fog megtörténni a validálás események képződnek
• Process validations validációk lefutnak a beírt értékekre. Ha elbukik error msg-k kirakódnak és render response hívódik.
• Update model values A Managed Bean-ekbe itt történik meg az értékek visszaírása. Ha nem sikerül konvertálni egyből a render response fázisba megy error msg-kkel.
• Invoke application Form submit és egyebek lekezelése.
• Render response HTML Renderelés.

Managed Bean-ek

faces-config fájlokban kell őket összehegeszteni a JSP lapokkal. Alapvetően POJO-k, de tartalmazhatnak akció és eseménykezelő metódusokat is, tehát nem csak egy oldal állapotának hordozására, hanem az eseményeinek lekezelésére is ezek a Managed Bean-ek használhatóak. Managed Bean lehet Map vagy List leszármazott is. Publikus default konstruktor kell. Setterek csak akkor kellenek, ha a faces-configban inicializálni akarjuk.

Navigáció

Jóanyag.

Összefoglalva: Meg lehet adni, hogy melyik oldalról milyen 'outcome' hatására melyik oldalra menjen. Az 'outcome' String típusú értéket a Managed Bean-ekben lévő action metódusok adják. Pl. ha egy save() sikerült az outcome lehet "success", ha nem akkor "failed".

• Egy from-view -hez meg lehet adni több outcome-t és egy default-ot.
• From-view -t meg lehet adni pattern-nel, ami azt jelenti hogy a végén lehet wildcard (*).
• Az egész form-view lehet egy darab wildcard, sőt a form-view tag ki is hagyható, üresen viszont nem hagyható. Ilyenkor 'global outcome'-okról beszélünk.
• Ha ütközés van mindig az utolsó szabály érvényesül.
• #{beanName.beanActionMethod} : meg lehet adni, hogy csak
• erre az egy action-ra érvényesüljön a navigációs szabály.
• NavigationHandler az invokeApplication fázisban hívódik.
• to-view -be külső url is megadható.

Akciómetódusok

(ActionListener, validator és valueChange metódusokkal nem foglalkozom most.)
Publikus, paraméter nélküli metódusok Object visszatérési értékkel.
Pl. Enum-ot is visszaadhat, amit String-gé alakítva kijön az outcome.
Ha null-t ad vissza marad az aktuális nézeten.

JBB Q#20588: megmondja hogyan lehet oldalak között információt áramoltatni.

Nem lehet paramétert átadni (legfeljebb trükkösen).
Ha van több azonos nevu metódus automatikusan kiválasztja az action metódust, aminek nincs paramétere és Object a visszatérési értéke.

Implicit objektumok

• applicationScope : egész alkalmazásra vonatkozó
• cookie : cookie, requestre
• facesContext : FacesContext példány requestre
• header, headerValues : HTTP header, request
• initParam : az alkalmazásra vonatkozó init paraméterek
• param, paramValues: request paraméterek
• requestScope
• sessionScope
• view : gyökér UIComponent

Ha van egy images könyvtárunk a WEB-INF-en kívül, így tudunk benne hivakozni egy képre JSF-ből:
image="#{facesContext.externalContext.requestContextPath}/images/picture.gif"/>

Value Binding Syntax

#-vel kezdődik nem $-vel mint JSP-ben. Megpróbál nem elszállni NPE-vel, akkor inkább üres értéket ír ki. Input-oknál viszont simán elszáll, ha nem találja a Managed Bean-t vagy a property-t amibe be kéne írni valamit. Általában String-gé konvertálgat kiírásnál.

Egyebek

A h:form-nak van egy 'prependId' atributuma, ami alapállapotban true és ennek hatására a formban lévő input elemek id-it prefixeli a form nevével. Ezt érdemes false-ra állítani, ha a managed bean-eket post paraméterekhez akarjuk bind-olni. Viszont érdemes true-ra állítani ha több -esetleg iterációval előállított- form van az oldalon.

Lehet választani, hogy az f:loadBundle-t írjuk a jsp-be, vagy a message-bundle, resource-bundle -t a faces-config-ba. A standard validátorok üzeneteit a message-bundle alkalmazásával lehet felülírni. Pl. ilyesmi nevű MessageFormat-okat kell definiálni:

javax.faces.validator.LengthValidator.MAXIMUM

A requiredMessage-t pedig egyedileg megadhajtuk EL-lel így: #{msg.myMessage}, de valami bug miatt csak a resource-bundle alkalmazásával fog működni, f:loadBundle-lel nem.

Echo2 ismét

A JUM III.-on követtem el egy előadást az Echo2-ről. A szó elszáll, az írás marad:

Az Echo2 egy java webalkalmazások fejlesztéséhez használható prezentációs rétegbeli keretrendszer, amiről régebben már írtam egy-két keresetlen szót. Érdekessége, hogy Javascript és HTML ismerete nélkül lehet felépíteni igényes Web-es GUI-kat. A komponenseket Java-ban kell összerakni a Swing-hez nagyon hasonlóan. A Nextapp nevű amerikai cég fejlesztette ki LGPL / Mozilla Public License alatt. Az Echo2 továbbviszi az Echo (1) koncepcióit, de a 2-es verzióban bevezetett Ajax-ozás miatt a felhasználói élményben és a sebességben lényeges javulás tapasztalható. Szervlet alapú, bármilyen szervlet motorral használható a megfelelő verziószámot szem előtt tartva.

A kiindulóoldalról lényegében minden elérhető.
Demók: egy email-kliens és egy tarka-barka, minden komponenst bemutató demó tekinthető meg online.
Doksik: Van egy jól felépített -a lényeget leíró- lineáris Tutorial, a technikai részleteket bemutató doksi, Java API doc és egy Wiki, amibe első látásra máris sokmindent belebillentyűztek.
Közösség: Van egy pezsgő fórum pár száz topikkal. Régebben volt egy blog, amibe bekerült egy-két bejegyzés pár hónap alatt egy tűzközeli ember kezéből, de úgy látszik hamvába halt, mert nincs már kinn a link.

Mellesleg találtam a prog.hu-n egy topikkezdeményt a témában: http://www.prog.hu/tudastar/66971/Ajax-Echo2.html
Nem értem miért nem találtak doksit. Vagy lehet hogy magyar nyelvű doksira gondoltak?

Kiegészítések:

Echo2 alkalmazások fejlesztéséhez elég egy Java IDE, de a Nextapp biztosít egy Eclipse-hez kapcsolható grafikus szerkesztőt, ami viszont már pénzes: Egy egyfejlesztős disztribúció 100 ropiba kerül, több fejlesztőre ez az érték közel lineárisan növekszik. Ezért a pénzért support is jár, a szoftver pedig letölthető kipróbálásra 30 napra.

Az Echo1-hez egy független (vagy nem független) fejlesztőcsoport még készített különféle izgalmas kiterjesztéseket Echopoint néven. Echo2-höz is folytatódott ez a jó szokás EchopointNG néven, de nem látom hogy igazán messzire jutottak volna. Régebben már megemlítettem ezt.

Disztribúció letöltés, tartalma

A 2.0-ás stabil verzió már jó régi, még 2005 decemberéből való.
A 2.1.0-ás Release Candidate 2007 márciusi és egyébként ezt ajánlják letöltésre.
A disztribúció 5.2 megás zip, amiben vannak példaalkalmazások forrással együtt (sima war-ok, amik egy webszerverbe bepottyantva elvileg azonnal működőképesek - gyakorlatilag nem minden esetben), a keretrendszer bináris fájljai és forrásai, valamint API dokumentáció. A csili-vili online demó sajnos nincs benne a letölthető disztróban.

Aki a kíváncsiságból vezérelve belenéz valamelyik példaalkalmazás war-jába, tulajdonképpen semmi meghökkentőt nem fog látni:
index.html ami egy más sok helyről ismerős redirect oldal.
A META-INF csak egy szokásos manifest-et tartalmaz.
A WEB-INF tartalma:
web.xml: Egyszerűbb webalkalmazásnál egy egyszerű servlet definíciót tartalmaz.

Bonyolultabb alkalmazásoknál a szervletnek paraméterei is lehetnek, több szervlet illetve biztonsági beállítások is fellelhetőek.
lib könyvtár: 3 darab Echo2 jar-t tartalmaz. Nem túl nagyok, a legnagyobb 198kbyte.
classes: Az alkalmazás osztályait tartalmazza, amik tulajdonképpen maguk az oldalak. Az alkalmazásban normál esetben nincsenek JSP, JSF, HTML, XHTML fájlok. (Természetesen megvan a lehetőség HTML content beágyazására.)
Lehet még egyéb könyvtár ami a publikusan elérhető erőforrásokat tartalmazza, pl. images.

A példaalkalmazások projekt szerkezete

A példaalkalmazások forráskódja a SourceCode könyvtárban található. Az alkalmazások Ant-tal buildelhetőek. Minket leginkább a java könyvtárban lévő források érdekelnek. Ami a htdocs könyvtárban van az egy az egyben átkerül a webalkalmazás gyökerébe publikusan látható erőforrásként (index.html , images). A deploy könyvtárban pedig a web.xml kapott helyet, tehát ott kell keresni ha valaki bele akar matatni.

A forráskönyvtár nem követi semmilyen IDE projektszerkezetét és nem tartalmazza a fordításhoz szükséges Echo specifikus jar-okat, de ezeket könnyen el tudjuk érni a BinaryLibraries könyvtárból. Szükség van még egy servlet.jar -ra, ami viszont nincs a disztribúcióban.

Az Ant-tal való buildeléshez az ant.properties-nek megfelelően be kell állítgatni néhány környezeti változót. Én inkább az ant.properties-t írtam át a servlet.lib.jar és az echo2* változókat direkt hivaktozásokra. Nem tudom miféle verzióprobléma miatt, de az ant.properties-ben a dir.src.app, htdocs és deploy sorokat is át kellett írnom a ${ dir.src} hivatkozásról direkt hivatkozásra, különben elbukott a war target. A war könyvtárban keletkezik a becsomagolt alkalmazás.

Az alkalmazás szerkezete

Az ApplicationInstance egy felhasználó session-jét reprezentálja a szerveroldalon. Akkor inaktiválódik amikor a user kilép vagy timeout-ol a session. A felhasználóhoz tartozó tulajdonságokat nyugodtan lehet ebbe az osztályba pakolni.
Az ApplicationInstance init metódusa egy Window objektumot ad vissza. A Window objektumra lehet felpakolni különféle komponenseket (add metódus). Nehézzé teszi a dolgokat, hogy nem minden komponenst lehet hozzáadni bármelyik másik komponenshez és ez sokszor csak futási időben derül ki egy üres képernyő, egy javascript alert és egy loggolt exception formájában.

Az elhelyezkedési struktúrákat a LayoutData beállításával lehet kialakítani. Az Echo 1-es megoldások nekem jobban tetszettek, de ez is megszokható. Valószínűleg erre jobban lehet vizuális szerkesztőt készíteni.

Az eseménykezelés a Swing-hez nagyon hasonló: listenereket lehet hozzápakolgatni a komponensekhez. (Anonymous inner class és társai.) Az események és a válaszok így Ajax segítségével pattognak a kliens és a szerver között anélkül hogy különösebben sportolni kellene a szép működés kiharcolásáért.

A komponensekben megjelenítendő adatok szintén a Swing filozófia szerint Model-ekben kerülnek átadásra.

A komponensek látható tulajdonságait (színek, háttérképek) kódból és XML-ben leírt stylesheet-ekkel is meg lehet határozni.

A lokalizáció ugyanúgy történhet mint egy standalone java alkalmazásnál. A böngésző támogatott locale-ját ki lehet nyerni az alkalmazáson belül. Támogatott a jobbról balra való írásmód is.

Semmiképp sem használj Echo2-t ha:

• Sok felhasználós internet alkalmazást kell csinálnod.
• Profi vagy valami másik webes keretrendszerből.

Jó ötlet lehet az Echo2 használata, ha:

• Nem értesz HTML-Javascript-JSP-JSF -hez és nincs is szándékodban megtanulni.
• Gyorsan össze kell dobálni egy intranetes webes alkalmazást.
• Nagyon dinamikus felületre van szükséged.
• Swing-es vagy SWT-s alkalmazást kell portolnod web-re.

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.

A JSP lenyom

Pár hónapja elhatároztam hogy bepótolom az elmaradásomat és némileg megtanulok normális klasszikus webalkalmazásokat írni. Nem rögtön a legmodernebb eszközökkel akartam kezdeni, hanem folyamatosan feljönni a szervletektől a jsp-n keresztül az Ajax-os eszközökig. Állítólag MVC keretrendszert is érdemes már használni. a Spring MVC-t választottam, mert a múltkor belenéztem a Struts-ba és nem volt szimpi első látásra (fölöslegesnek látszó mappeléseket és öröklődéseket kellett csinálni benne szerintem) és egyébként is a Spring-gel ismerkedtem mostanában.

Szóval: a szervletek és a sima régi JSP-k hamar megvoltak a hagyományos módszerrel. Mondhatni kiráztam a kisujjamból. Még akkor is lelkes voltam amikor az első Spring MVC handlermappingokat és controllereket konfiguráltam az xml-ben. Úgy gondoltam hogy ez tök jó lesz, cserélhető a megjelenítési réteg, moduláris meg minden. Amikor viszont egyre több jsp oldalam lett és közepesen bonyolult funkciókat akartam beépíteni, menthetetlenül kezdett kaotikussá válni az egész. Jávában, HTML-ben otthon kell lenni, ismerni kell a Spring (vagy akármelyik másik) MVC keretrendszer lelkivilágát és még a JSP-hez is érteni kell, beleértve az Expression Language-t -ami egy külön kis világ- és még a JSTL-t sem árt ha keni-vágja az ember. Nem beszéltem még az egyéb tag librarykról és még egy sor javascript-et sem írtam le. Nem mondom hogy MVC framework vagy EL, JSTL nélkül könnyebb programozni, de túl sokat nem segítenek. Fejleszteni egyébként is marha nehéz, mert csomó hiba futási időben derül ki és sokszor nem a hiba íródik ki közvetlenül, hanem valamelyik folyománya. És még hol vagyok az Ajaxtól, jól kinéző alkalmazásoktól? Ez egy sima model 2-es webalkalmazás lenne. Lehet hogy ki kellene próbálni más eszközöket.
Ehhez képest még a .net-es aspx megoldás is elég versenyképes a mögöttes kód rendszerével.

JSTL meccs

Javalistán volt ez a probléma, de nekem is előjött:

"Ha egy JSP oldalba beleteszem a következõ sort:
nyitókacsacsőr%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %zárókacsacsőr

Akkor miért kapom a következõ üzenetet?
org.apache.jasper.JasperException: This absolute uri
(http://java.sun.com/jsp/jstl/core) cannot be resolved in either web.xml
or the jar files deployed with this application
A jstl.jar és a standard.jar fájlok bent vannak a WEB-INF/lib könyvtárban.

5.x-es Tomcat alatt működik, csak 4.x-es alatt nem."

Ezeket a linkeket ajánlották hozzá:
http://archive.midrange.com/web400/200404/msg00031.html
http://wiki.java.net/bin/view/People/DeployingCreatorApps -> Container

Mindenfélét találgattak, volt bennük igazság is, de megoldás végül nem született. Legalábbis nem írta a probléma felvetője hogy megtalálta a megoldást.

Az én próbálkozásaim, 5 hónappal a thread után:

Belenézve a standard.jar c.tld-jébe az uri http://java.sun.com/jstl/core, tehát a jsp-be is ez kell hogy kerüljön. Mellesleg JBoss 3.2.6-om van Apache Tomcat 5.0.28-cal. Így viszont NoSuchMethodError-t vág az arcomba úgyhogy verzióprobléma ez valószínűleg. Ez van még a tld-ben:
tlib version 1.0
jsp version 1.2
És bele van írva hogy JSTL 1.0 core library.

Meg kellene próbálni az 1.1-es JSTL-eket.
Letöltöttem az apache-ról az 1.1-et és átmásoltam a szükséges helyekre, de most is NoSuchMethodError jön. A JSTL-lel szállított standard-examples.war is elhasal ugyanúgy. Biztos 5-ös Tomcat van a JBoss-ban? (Igen.) Még a JBoss Management Console is ilyeneket dobál. Azt hiszem jobb lesz felhúznom egy új JBoss-t. Megtörtént (10 másodperc alatt). A téma most működik, beleértve a JBoss Management Console-t és a JSTL 1.1 példáit is.

Tehát végül nem tudom mi volt a probléma, de az biztos hogy a JBoss amin próbáltam már egy fél éve fenn van a gépemen és alaposan meg volt gyepálva. Ki tudja már milyen jar-okat cserélgettem ki, vagy töröltem benne.

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

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.