Dojo 0.4

Kijött a Dojo 0.4-es verziója, bele is raktam az éppen aktuális projektbe a 0.3 verzió helyett. Ez ugye elvileg úgy megy java webalkalmazás esetén, hogy bele kell tenni a dojo src könyvtárát a webalkalmazás WEB-INF könyvtárába. Verziókövető rendszer szempontjából ez kicsit macerás, mert rengeteg kis fájlról van szó és ha az egészet le kell cserélni az kissé sokáig tart. Nekem például tíz percig tartott mire betettem a VSS-be az Eclipse pluginnel, persze VPN-en keresztül.

Túl sok dolgot nem használok még a Dojo-ból, csak egy dátumválasztó komponenst, ami kicsit változott a két verzió között. Na nem sokat, csak annyit, hogy date helyett most már value -vel kell megmondani az értékét. Remélem jó okuk volt rá hogy átírják. Nem okozott túl nagy törést, megoldottam pár perc alatt, de azért nem jó ha ok nélkül változgatnak elnevezések. Ha valami közös nevezőre akarták hozni valamivel akkor oké. Még a dojo.require("dojo.widget.html.DatePicker"); sort kellett kiszednem a kódból, mert egyrészt enélkül is megy, másrészt az IE javascript warning-ot dobált miatta.

Akartam használni a SortableTable-t is, de több probléma is volt vele. Meg kell adni az oszlopok típusát és erre még nincs felkészítve az alkalmazásunk, ha pedig mindent String-ként kezelek, a számok rosszul lesznek rendezve. Pl. "123"-nál nagyobb lesz a "2". A dátumok is rosszul kezelődnek a dátumformátumtól függően. Ezekre van megoldás a Dojo-ban, viszont a másik gond, hogy elrontja a táblacellák elrendezését. Hiába mondom meg, hogy egy TD align Left és Top legyen, visszateszi az alapértékre. class-ot is hiába mondok meg.

Kicsit gyér a Dojo dokumentációja még, (persze látszik hogy igyekeznek) emiatt próbáltam keresni Dojo fórumokat, de egyelőre nem találtam meggyőzőt. A dojotoolkit.org-on van egy levlista, de arra nem íratkozok fel, mert nem kérek napi 100 levelet, aminek X százaléka szemét. A Nabble-s fórumot gyakorlatilag elsőnek dobta ki a Google. Azzal az idióta rendszerrel megy, hogy 1 kérdés 1 téma és elég ömlesztett, de még majd barátkozom vele. Lehet hogy be fog jönni.

Acegi Security

Végül mégiscsak maradtam a Springnél és a JSP-nél. Ha nem renitens módon próbálja meg használni az ember, hanem úgy ahogy javasolják, akkor viszonylag használható. Ezenkívül az utóbbi időben találkoztam még egy elég egzotikus, webes prezentációs megvalósítással, ami saját taglibekkel és XSL transzformációval operál. Marha bonyolult, táncol a használhatóság szélén. XSL trafót nagyon ésszel kell használni ilyen célokra.

Most az Acegi Security-vel ismerkedem, ahelyett hogy saját authentikációs és authorizációs komponensen kezdenék el agyalni. Nem egyszerű, olvasgatni kell hozzá, de még mindig jobb, mintha házon belül csinálnánk meg és aztán tesztelhetnénk hónapokig. Használható tutorial róla.

Egyébként most jött ki belőle az 1.0.2-es verzió, ami lényegében ugyanaz mint az 1.0.0 vagy 1.0.1, csak belső megvalósítás változott.

GWT

Miközben a magyar szcéna web 2.0 moguljai kiosztották egymás között az észt, lement a JavaOne és a 24-órás programozói verseny, a Google publikált egy webfejlesztő eszközt ami java kódból Ajax-os javascriptes alkalmazást csinál.

(A JAvaOne-het visszatérve egy pillanatra: volt egy slot car race nevezetű kis játék, ahol modellautókat kellett programozni valós idejű jávában. Ahogy a 24 órás versenyről elkészült képeket nézem ott is lehetett valami hasonló feladat. Jó poén lehet.)

Szóval, GWT: Letöltöttem, kipróbáltam. Vicces srácok ezek a guglinál, ennek az eszköznek semmihez semmi köze. Saját javadoc formátumuk van, saját futtató eszközük, ant helyett cmd fájlokkal lehet fura formátumú sablon projekteket generálni eclipse alá. Amúgy az alapgondolat nagyon jó és a leírás is ami alapján a kezdő lépéseket meg lehet tenni használható. A Gugli fórumokkal (vagy mi) még nem sikerült megbarátkoznom és érdekes módon nem nagyon van leírva hogy tulajdonképpen ez az ajaxos alkalmazás hogyan kommunikál a szerverrel. Mintha standalone webes alkalmazások írása lenne a cél. Egyébként a Gmail és társai nem ezt az eszközt használják. Ez az eszköz ugyanis csak nemrég, a JavaOne előtt lett kész. Inkább úgy néz ki, mintha valami komolyabb eszköz kis része vagy mellékterméke lenne. Meg kell hallgatni az 56-os javaposse-t amiben Brett Taylor biztos megmondja a frankót ezzel kapcsolatban. (Még nem hallgattam meg.)

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.