Hudson

Szóval ez igazán egy pazar cucc. (Egyébként egy Continous integration eszköz) Régebben (egy két éve) még a Continuum-ot nézegettem, akkor az még csak standalone-ként volt hajlandó futni nekem, és rengeteg adatbázis mütyürészést kellett véghez vinni, hogy elinduljon (azóta talán az is fejlődött). Ellenben ez csupán egy war, amit bedeployolok és megy.

Nálunk így megy: 5 percenként svn update-et nyom és ha változik valami fordít újra egy release-build-et és lefuttatja rajta a unit teszteket (Unitils rulez, ha változik a séma definíció a repositoryban, automatikusan felépít egy új adatbázist).

A Hudson-nak valami olyasmi a filozófiája, hogy én elvégzem a piszkos munkát (Ant-tal, Maven-nel, shell scripttel, bármivel), és ő az eredményt szépen megmutatja. Pl. megmondom neki, hogy az ANT task végén hol lesz az artifact, és ő azt szépen archiválja (nálunk a legutóbbi 10-et), ezek közül meg lehet jelölni bármelyiket hogy ne rotálódjon ki (tipikusan nálunk mindig a legutóbbi 10 build van fent, meg megjelölve az a régebbi, ami épp a megrendelőnél van). És persze, ha szar kerül a palacsintába, akkor email-t ír, telefonál, kárt ment, stb.

A fejlesztője nagyon nyomni akarja, ezért nagyon sűrün vannak belőle release-ek, és az egész interface kellemes hangulatot áraszt. Pl. értelmes hibaüzeneteket ír, és elmondja, hogy mikor mi a baj.

Szóval nem próbáltam végig az összes CI toolt, de ez elsőre nagyon használhatónak tűnt.

Generics + reflecion

Tegnap ígértemhez híven: a generic típusok a bytecodeban benne vannak a deklarációs részben, csak a utasításoknál nincsenek. Reflecionnal tehát lekérdezhetőek.(Pontos speckó linket most nincs időm keresni, helyette itt a példakód.)

public class Main {

    public List<Double> list;

    public static void main(String[] args) throws Exception {
        Field field = Main.class.getDeclaredField("list");
        ParameterizedType ptype = (ParameterizedType) field.getGenericType();
        Type[] types = ptype.getActualTypeArguments();
        System.out.println(types[0]);
    }
}

Toplink JPA bug

Mindig öröm, ha egy komoly termékben néhány órás szívással izolálni tudunk egy hibát, és végre kiderül, hogy nem mi voltunk a hibásak. Most az történt, hogy Joined table inheritance strategyt használtunk és left joint és a Toplink Essential a discriminator value-t inner join-nal kezelte. Magyarul nem lehet left joint csinálni, hiába írom be a querybe.. Ki próbáltam Hibernate JPA-val is (ugye milyen jó, hogy hipp-hopp váltogatni lehet a providerek között?), és azzal rendesen ment.

Akkor most bugreport és native queryk használata a bugfixig.

Unitils tapasztalatok

Régóta nem írtam már ide, pedig jócskán felgyűltek a témák. Az egyik ilyen az Unitils bevezetése az egyik projektünkbe. Az Unitilsnek Kocka egyik blogbejegyzése nyomán kezdem utána nézni.

Az Unitils a Junit3,Junit4 és a TestNG keretrendszerek mindegyikével házasítható, ezeknek a teszt környezeteknek funkcióihoz adnak hozzá a moduljai. A Unitils moduláris felépítésű, mi három modulját használjuk:

database
A database modul egy adott környvtárban található sql szkripteket sasolja. Ha valami is vátozik, akkor az adatbázis teljes sémáját bedarálja, és újra futtatja a szkripteket. Nagyon praktikus olyankor, amikor a sémát SVN-be tároljuk, de többen is szerkesztgetjük.

dbunit
Ez igazából a dbunit-ra egy wrapper modul. a @DataSet és @ExpectedDataSet annotációkkal jelölhetjük meg a teszteinket, és ezekkel adhatnk meg egyszerű XML-eket, amikben a teszthez szükséges adatbázis tartalom van. Pl.

ServiceOneTest.xml
<dataset>
<customer id="1" name="asd">
</dataset>

ServiceOneTest.testOne-result.xml
<dataset>
<customer id="1" name="changed">
</dataset>

Elég kényelmes dolog, de van egy fontos tulajdonsága. Az előző modul a séma létrehozása után alapból az összes constraint-et disabled-re állítja. Ez egyfelől kényelmes, mert az XML-ekben tényleg csak azt az adatot kell beleírni, amit tesztelünk (esetünkben a customer name tulajdonságát), és pl. a company mezőt nem, mégha elvileg foreign key lenne is rá. Persze ez azt is jelenti, hogy a constraint-eket ilyenkor nem teszteljük.
(Megadhatjuk azonban azt is, hogy a constraintek maradjanak).

ejb3
Ez a harmadik modul amit használunk, saját fejlesztés (nagyon egyszerű új modulokkal kiegészíteni a Unitils-t). Ha talál egy @EJB annotacíót a unit tesztünkbe, akkor oda injektálja az EJB-t, és az EJB-be is ellenőrzi az annotációkat és oda is injektál mindent (pl. EntityManager). Nagyon kényelmes, mert gyakorlatilag az egész EJB oldalt standalone unit tesztekkel tudjuk tesztelni. Ha igény van rá, talán majd publikáljuk is.

Ezenkívül van még Spring, Hibernate és EasyMock-ot támogató modulja is, azokat mi nem használtuk. Viszont standalone alkalmazáshoz is viszonylag kis fájdalommal hozzá lehetett gyógyítani (egy migráló szkript használja a Unitils database modulját arra, hogy ő is mindig az aktuális adatbázis sémán dolgozzon). A forrása is szép, mindenütt interface-k vannak, sok helyen lehet változtatni az implementációt.

Nyilván ezzel is előfordulnak szívások, de összességében csak ajánlani tudom. Használata Junit 4.4-től csak annyi, hogy a tesztet meg kell annotálni egy @RunWith(UnitilsJUnit4TestClassRunner.class) annotációval.

Java 7 újdonság szavazás

A Whiteboard játék úgy néz ki, hogy kitesznek a konferencia előterében néhány táblát, amin néhány kedvcsináló kérdés van, és aztán mindenki firkál oda. A TSSJS Europe-on, ahol voltam nyáron, ott három ilyen tábla volt, és a közönség nem is nagyon kapott rá. A JavaPolis-on a fotó alapján más a helyzet. (De majd Kocka remélem beszámol részletesen is).

Az egyik ilyen táblázaton a Java 7 néhány javasolt nyelvi újdonságára lehette szavazni, az eredmények itt. Vicces végignézni, hogy milyen vad dolgokat találnak ki, és néha milyen bután szavaznak az emberek egész értelmes ötletekre. Mintha mindenki rákapott volna, hogy Java7 proposalokat csináljon. Mindegy, felőlem jöhet akármi, de a nulláról Java-t tanulók dolga egyre nehezebb lesz.

JSPWiki

Vegyesek az érzéseim:

Egyrészt iit van a XXI. század hajnalán egy alkalmazás, ami ha nem is csupán JSP-be van írva, de azért úgy tűnik (a kódba nem néztem bele) elmegy minden mellett ami manapság divatos (ORM, Component Based Web Frameworks, stb.), alapból pl. fájlrendszerbe tárolja az adatokat. Tomcat6/Java6-ra telepítés közben elszáll, és mindenféle hekkeléssel lehet csak életet lehelni bele (a legutolsó log4j1.3alpha kell neki, és a properties fájlba a dir-eket be kell állítani.).

Másrészt meglepően kényelmesen és gyorsan lehet használni: mi most egy projekt belső dokumentumait írjuk rajta, és nagyon jól megy. Ráadásul jól kiterjeszthető, pluginelhető, elvileg kis munkával nagyon jó projekt kezdőlapot lehetne fabrikálni benne, ahol együtt látszódnak az aznapi SVN commit-ok és a Bugzillába felvitt tételek. Kiterjeszthető a mögötte lévő tárolási eljárás is, pl. SVN-t is tud használni elvileg perzisztens tárolónak. Ha meg nem akarunk semmi extrát, akkor (ha sikerült deployolni) onnantól tényleg zero config.

GWT widget library

A GWT-hez keresek csilli-villi Widget készletet, ami könnyen kezelhető, és főleg nagyon szép, úgy hogy ha a megrendelő megnézi higyje azt, hogy valami nagyon profi oldalt lát.

Első körben a MyGWT-re és a GWT-EXT-re találtam rá. A demója mindkettőnek (mygwt, gwt-ext) nagyon hasonló. Gugli barátunk viszont azt mondta, hogy a gwt-ext csak egy wrapper csomag, ami natív hívásokkal az ext.js nevű függvénykönyvtárat hívogatja, a MyGWT viszont full Java-ban implementált (és GWT-vel js-re fordított) csoda. Ráadásul a MyGWT-ben vannak olyan containerek (pl. WidgetContainer), amik a Swing-ben megszokott Layout-okat is tudják kezelni, és ezek alapvatően sima Widget leszármazotta, úgy hogy elvileg sima GWT kóddal is jól integrálhatóak.

Szóval egyelőre MyGWT-re áll a zászló, megpróbálom integrálni, és megáltom mi lesz belőle.

Java Café I.

Szóval ott voltam ma délelőtt. Tehát---

Előszőr is a disclaimer: rendszeres és lelkes látogatója vagyok a JUM-nak, ami szintén egy hasonló elvek mentén szerveződő, viszont alulról jövő megmozdulás, tehát akaratlanul is hozzá hasonlítom. Például rögtön első látásra is látszott, hogy a rendezés a szokásos Sun Tech Day-es színvolalon zajolott: elegáns terem, büfé, jegyzetfüzet, toll stb. Körülbelül 40-50 résztvető lehetett becsléseim szerint (mivel volt regisztráció a Sun biztos pontosabb számokat is tud). Az elhangzó kérdésekből úgy tűnt, hogy ezek egy része (mondjuk 10-20 fő) tényleg fejlesztő munkás, és nem csak a managerek jöttek el.

Az előadást Molnár István tartotta, egy szabadon elérhető prezentáció mentén. A szünetig viszonylag általános alapvetés volt (mi is az alkalmazás szerver, miért olyan fasza a Glassfish stb), ezen a részen én egy kicsit bóbiskoltam, (vegyük számításba, hogy az alapvetés engem már kevésbé hoz lázba, illetve, hogy 3 órát aludtam éjjel.) A szünet után már kicsit részletesebb infók is voltak, meg egy hosszabb demó, hogy hogyan is működik a clusterezés. Ez már elég jó volt, már régóta ki akartam próbálni, hogy feltelepítek egy clustert, de valahogy sose volt rá idő, és Molnár István tényleg élvezhetően és profin vezette az előadást, és szolíd marketing mellett sok technikai részlet is elhangzott. Teljesen rendben volt.

A bevezetőből megtudtuk, hogy tényleg egy hosszabb rendezvénysorozatra készülnek, és előreláthatóan továbbra is Sun-os OS termékekről lesz szó (JAX-WS, OpenESB, NetBeans).

Szóval volt, aki rögtön a JUM-hoz hasonlította, ahol persze nincs büfé, nincs póló osztás, és talán az előadók se mind olyan profik és rutinosak mint itt, de valahogy én mégsem érzem, hogy ezeknek most egymás ellen kéne versengeniük. Az egyik ugye délelőtt van munkaidőben, ahová a talpasok csak bonyolult elkéredzkedés útján juthatnak el, a másik meg este, bizonyos pozíciótól felfelé valószínűleg már kevésbé áldozzák fel a szabadidejüket rá az emberek. Viszont szakmaiság azért itt is ott is megtalálható, ehhez az egyik helyen egy felülről jövő céges íz, a másik helyen egy alúról jövő néha kissé amatőr/civil felhang jön hozzá.

Szóval én örülök, hogy újabb alkalom van, ahol Java-ról esik szó, a szakmai színvonalra nem lehet panasz, és látszik, hogy a Sun is tényleg komolyan gondolja. Várom a következő részeket.

Highlight autoboxing

Annó még egy régi interjún nyomták kezemben ezt a kérdést: Milyen i és j értéket tudnál beállítani, hogy végtelen ciklust csinálj:

while (i <= j && j <= i && i!= j) { ... }

A kérdés persze annyira nem bonyolult annak, aki hallott már az autoboxingról, és talán az interjúztató még hintelt is, hogy 1.5-ös Java-ról van szó. Most is csak azért jutott eszembe, mert a NetBeans hírlevél kiemelte ezt a NetBeans plugint, és én meg elgondolkoztam, hogy talán tényleg nem teljesen haszontalan valami szolid highlight-tal jelölni az Unboxing/Boxing eseteket. Különben is egyre szinesebb az IDE-m, szinte öröm leülni elé, akkor már had legyen benne ez is.

ps: a rejtvény egyébként a 2006-is JavaOne TODAY című újságjában jelent meg Neal Gafter and Joshua Bloch cikkében, akik a Java Puzzlers-nek is az írói. A cikk részleteiben és megoldás magyarázattal itt.

ProGuard

Úgy esett, hogy hirtelen java obfuscator kellett volna, és a gugli a ProGuard-ot ajánlott. Teljesen korrekt ajánlat volt.

Az alap obfusator opciók mellett kódot is optimalizál és tömörít is. Hívható ANT taskból, van egy kedves gui felület-e is, ahol az opciókat bizergálhatjuk, majd a beállításokat egy config filbe menthetjük. Tartalmaz egy csomó példát, pl. hogy hogyan lehet egyszerűen megoldani, hogy az obfuscálásból kimaradó osztályokat (pl. public api) annotációkkal adjuk meg, vagy hogy hogyan vegyük a változók neveit a Shakespear összesből. A GUI továbbá tartalmaz egy kedves eszközt, amivel config alapján a stacktrace-t visszaalakítja emberileg olvashatóvá.

Szóval mégcsak egy órája játszok vele, de minden szempontból úri cuccnak tűnik. (Most éppen azt játszom, hogy az Android decompilolásnál is bevált JAD decompilerrel fordítgatom vissza az obfuscált kódot.)

Android a házban

Talán már több mint egy hete jelentte be a Google az Android-ot, ami egy ingyenes mobil platform lesz. (Előtte már régóta találgattak GPhone-ról, de kiderült, hogy hardvert ők nem, csak OP-t csinálnak).

Viszont mától le is tölthető az SDK innen.

Ami miatt lázba jöttem tőle, hogy az SDK full Java alakúnak tűnik. Még nem nagyon szórakoztam vele, de vagy Eclipse pluginnel vagy ant-tal lehet buildelni, van hozzá egy emulator, elég korrekt rendszernek tűnik. Szép Java API. Majd jönnek részletek.

Elhavazva (TopLink kapcsolók)

(Lassan már álmomban is implementálok, de van remény, nem sokára enyhűlni fog a helyzet. És akkor majd...)

Itt viszont egy remek összefoglaló a Toplink JPA suttyom kapcsolóiról. Persze egy része Oracle specifikus, olyan annotációkat meg mégsem akarhatunk látni tiszta JPA forrásban, de egy másik rész pedig szép kiterjesztés, ami kifejezetten belefér a JPA-ba. Pl. vannak plusz propertyk a persistence.xml-be, amik kiloggolják az SQL lekéréseket, vagy hogy induláskor nem az adatbázisba rakja újra a táblákat, hanem elmenti a CREATE SQL parancsokat egy DLL szkriptbe bárhová.

Ha minden jól megy, most úgy is alkalmam lesz mélyebben megismerni a TopLink lelkivilágát.

NetBeans Feature Request

Szóval elmondom mi az az egyetlen dolog, ami hiányzik nekem a NetBeans-ben:

Van ugye a Library Manager. Itt létrehozhatok egy új nevet, és adhatok hozzá 3 dolgot: classpath-t, javadoc helyet, és source-ot. Aztán ha ezt a nevet hozzáadom a project-hez a libraryk közé, akkor a fordítás szépen használja a classpath-t, és az IDE meg használja a javadoc és source helyekről beindexelt információt.

Csakhogy, ha átmegyek egy másik helyre, a másik NetBeans-en ugyanígy létre kell hozni ugyanazzal a névvel a library-t, hogy működjön. Elvileg lehetne azt, hogy csak a JAR-filet adom hozzá (akár property fájlból, akár IDE-ből), de akkor a library meg is lesz a másik helyen (mellé rakom), de a javadoc és a source nem.

A NetBeans-ben pont azt szeretem, hogy ANT alapú és bármit meg lehet benne csinálni. De egy jó hordozható projecthez még ez az egy hiányzik, hogy project property fájlba tudjam definiálni a code-comlpete-hez használandó source és javadoc helyeket.

Glassfish + PHP

Egyik előző bejegyzésemben azt állítottam, hogy hej-de-egyszerű lesz Glassfish-t ellátani globális php értelmezési lehetőséggel. Azt akarom ugyanis, hogy az összes virtual host-on, ha valaki a documentroot-ba másol egy php alkalmazást, az minden további nélkül működjön. Csakhogy a dolog mégse olyan egyszerű

A Resin-ből vidáman kinyerhető a Quercus, a Scripting api-ra is illeszkedő Javaban írt PHP motor, de ezt alapértelmezetten szeretném bekapcsolni. Ezt meg is csináltam: a default-web.xml definiáltam egy servlet-et (com.caucho.quercus.servlet.QuercusServlet) és meppeltem a *.php-re. A sima php ment is, de sajnos a mysq_connect-et már nem sikerült megugrani. A Quercus ugyanis valami megmagyarázhatatlan oknál fogva nem hajlandó sima adatbázis kapcsolatot kezdeményezni, hanem a servlet init paraméterei között meg kell adni egy jdni nevet, és onnantól kezdve a mysql_connect-nek bármilyen paramétert adhatunk meg, úgyis azok helyett inkább a jndi-t használja. Ez egyrészt kedves dolog, mert lehetne PHP-s alkalmazást futtatni connection pool helyett, másrészt elég szar, mert kötelező és egy globális php servlet lehetőségét teljesen ellehetetleníti. Nem lehet/és nem is akarnék az összes hostolt php alkalmazáshoz külön mysql DataSource regisztrációt.

Deployment Toolkit

A Java SE 6 Update N Early Access már elérhető, aminek a része a Deplyoment Toolkit nevű kis játékszer is. Igazából egy .js fájl az egész, ami ad néhány függvényt arra, hogy ellenőrizzük a felinstallált JRE verziót és ez alapján kirajuk az appletet/web start linket, vagy elküldjök a usert java-t letölteni.

Nem néztem át persze a forrást, de az egész csak egy javascriptnek tűnik, amihez nem is kell az Early Access, elég ha befűzzük a html-be ezt a http://java.com/js/deployJava.js -et, és már mehet is.

Itt pl. megmondom neked a JRE verziódat.

<script type="text/javascript" src="http://java.com/js/deployJava.js">
<script>
function detectJRE() {
    var list = deployJava.getJREs();

    if (list.length == 0)
    {
        alert ('No Detectable JREs are Installed');
    }
    else
    {        
        alert (list[0]);        
    }
}
</script>
<a href="javascript:detectJRE()">Itt </a> pl. megmondom neked a JRE verziódat.

A példát innen másoltam ki, ahol további részletek is találhatóak.

Verzió kontroll

Erik Burke írt néhány dolgot, arról, amikor használunk ugyan verzió kontroll rendszert, de valami azért mégse 100-as vele. A gyanús jelek szerinte:

1. Ha a helyett, hogy törölnénk a kódból inkább kommentezünk, hátha még kelleni fog a jövőben. Hülyeség: a verzió kezelő pont arra való, hogy megnézd az előző verziót. (Nálunk ez rendesen be van tartatva, code reviewn nem megy át, ha kikommentezett sorok vannak.)

2. Hetente egy nagy kommit, sok kis helyett. (Nálunk sajnos a rendszer miatt ez van. A clearquest-re ráépített rendszerben egy task = egy kommit, ami akár 40 órás task is lehet. Ha közben másnak is kénének újonnan létrejött fájlok, akkor nincs más mint local copy.)

3. Fizikai backup biztos ami biztos (ami ugye felesleges, mert a verzió kezelő sokkal jobb backupot ad). (Szerintem ez azért annyira nem probléma. Legalábbis nálunk nem fordul elő.)

4. History log: ahelyett, hogy a verziókezelőbe írnánk commitkor mi változott, a fájlok elején txt-be írunk valami log félét. (Abszolút igaza van, nálunk pont ez van, és idegesít is.)

Szóval nálunk a kincstári projektek 4/2 arány érnek el. Lenne még hová...

SJSWS => Glassfish 2

Le kéne cserélni a Sun Java System Web Server-t Glassfishre. Nem csak azért, mert a config deploy a SJSWS-nél bűn lassú (percekig tart), ezt talán be lehetne jól konfigurálni, és nem is csak azért, hogy hódoljak a Glassfish hype-nak, és trendi legyek, de jól jönne egy futó JBI konténer is, és a Web Service támogatása is jobb. A baj csak az, hogy bár a Glassfish végre nagyjából kezeli a virtual hostokat, egy csomó kényelmi szolgáltatás ami webhostingolásnál hasznos nincs benne. Pl. nem lehet jól beállítani, hogy egyes könyvtárakhoz csak jelszóval lehessen hozzáférni.

Az ideális az lenne, hogy ha lenne egy Servlet/Filterem-em, ami értelmezné a .htaccess fájlokat, (legalább mondjuk a jelszós részeket, vagy ne adj isten a ModeRewrite-ot is), és azt be tudnám deployolni default webappnak, ahová kéne. Nem is lenne nagy dolog megírni, csak épp most úgy tűnik semmi időm nem lesz ilyenre. Ha valaki tud ilyenről készen, az ne habozzon szólni (pl. Jettyben láttam hasonlót, csak az nem csak egy servlet, hanem + kismillió függőség, nem nagyon lehet kibányászni).

Ja meg PHP támoatás is kéne, de ez Scripting API-val + Quercus-szal simán szerintem simán menni fog.

Deployer role

A hagyományos JSR speckók mindig ugykezdődnek, hogy szerepköröket definiálnak (Deployer, Application Assembler, Bean Provider) persze sokszor egy ember több szerepkört is megvalósít, ahogy én is a hétvégén amikor néhány percem volt, probáltam egy JCR-es alkalmazást deployolni Sun Web Server és Glassdish alá. Egyik se sikerült tökéletesen (Tomcat 6 alatt remekül fut), úgy hogy debug gyanánt az egyre kiválóbb jcr-explorer-t próbáltam feltenni. Persze azt is sikertelenül.

És itt enyyi, ez egy olyan bejegyzés, aminek nem lesz csattanója. Ha csak nem az, hogy bug reporttoltam (hátha), és a fejlesztő már replayolt is, kössz, hogy szólok, ő JBoss-t használ, és hogy milyen sok szívás van a sok JSF implementáció között.

Így megy ez.

Wicket nyűgök

Na ez tipikusab olyan bejegyzés lesz, ami csak annak érdekes, aki szintén benne van a Wicketben. Két probléma:

1. Ha a WicketFilter-t nem /app/*-ra, hanem /*-ra meppelem, akkor a HomePage-ben a css hivatkozásot (default.css) helyelenul kicseréli egy ../default.cs-re. Ugyanezt az egyenkint felmountolt aloldalakon helyesen oldja meg. Próbáltam bug reportolni, de egyelőre még nem találtam meg, hol a hiba. Workaround: a fő oldalt is fel kell monutolni az Application osztályba valamilyen Bookmarkable címre.

2. Ha Rss-t csinálok ezzel a módszerrel (Gyakorlatilag egyetlen bridge osztály a Rome használatához), akkor nem csak, hogy nem működik, hanem az rss feed helyett kiírja $TOMCAT_HOME/bin tartalmát. Na már most ezt se tudom kinek a hibája (Tomcat/Wicket/Wicket-rome/saját magan), de ez így nagyon durva. Workaround még nincs. Mindjárt megpróbálom Glassfish alatt. (BTW. tudtátok, hogy Glassfish 2 elvileg képes értelmezni deploykor a tomcat-es context.xml-eket?)

Szép URL-ek

Szeretik a keresők, szeretik az emberek, esztétikus jó ilatú, stb. Ilyet szeretnék mindenhová. A vonzódásom története valami ilyesmi:

Hajdan, még Post-Nukés gyerekkoromban volt az index.php?mod=foo&bar=func¶m=1&.... A Front Controller megkereste a foo modult, annak a saját kis frontcontrollere megvalósította a func funkciót, a paramétereket meg beparzolta a funkció.

Aztán jöttek az ügyes apache rewriteok: index.php/foo/bar?par=... csak kicsit szebb, de nem az igazi.

Aztán megismertem, hogy hogyan csinálja ezt a Drupal. A Drupal-ba alapból csak szép URL-ek vannak. Van egy nagy fa szerkezet, és abba egy path egy modul funkció. Ezt pedig szép szorgalmasan fel kel meppelgetni.

Pl. (hasból) a admin/user/rights => admin_user_rights()-hoz lehet rendelni.

A nagy bravúr benne, hogy ha nem talál a megadott path-hoz hozzárendelve függvényt, akkor elkezdi leszedegetni a részeket / jelenként jobbról balra. Pl. a node/edit/22-höz ha nincs rendelve semmi függvény, akkor a node/edit-hez keres (amihez valószínű lesz), és a 22-t átadja paraméternek.

Ebből következik, hogy a paraméterek a drupálban sokszor nem kulcs érték párok, hanem pozíciók. Az ismert meppelés után első, második, harmadik... stb. Szerintem ez mondjuk sokkal szebb és logikusabb mint az előbbi.

Wicket-ben ez úgy néz ki, hogy alapból az oldalak amiket létrehozunk nem kapnak szép URL-t (sőt rosszabb esetben a csúnya url-n se lehet kívülről elérni őket). Hasonlóan a Drupalhoz kézzel a mappinget beállítani (WebApplication.mountShortBookmarkablePage()). A baj csak azzal van, hogy nem a Drupal féle pozíció=> paraméter leképezést használja, hanem a kulcs érték párosat, ami nekem kevésbé tetszik. Igaz ezt hajlandó akár az oldal/param1/value1/param2/value2 alakban is használni (oldal/value1/value2 helyett, amit én szeretnék).

Megoldás: lesszármaztatni a BookmarkablePageRequestTargetUrlCodingStrategy-t és újra implementálni a decodeParameters-t és a appendParameters-t (ezt a szűlőben látott mint alapján nem nagy flikk-flakk). Ezután a mappelést a WebApplication osztályból a

mount(new AnzixBookmarkablePageRequestTargetUrlCodingStrategy(path, bookmarkablePageClass, null));

paranccsal tehetjük meg. Persze még lehet csinosíthatni, hogy a pozícióhoz rendelt paraméterek lekéréséhez frankó gettereket írunk valami leszármaztotott helyre, de ez innentől újgyakorlat.

Marad viszonta kérdés: Hogyan csináljam meg ugyanezt JSF-ben?