Times like these

Wicketin heikkoudet

Heinäkuu 5th, 2006

Olen jo useamman vuoden liputtanut Wicket-nimistä Java-kehystä nettipohjaisten sovellusten tekoon. Vaikka Wicket on edelleen mielestäni paras olemassa olevista ratkaisuista, on siinäkin muutamia heikkouksia.

Eniten Wicketissä häiritsee tapahtuman kuuntelijoiden toteutus - tai oikeammin niiden käyttökelvottomuus.

Otetaan esimerkiksi vaikka joka paikassa käytetty Form-komponentti. Formin kuunteluun löytyy rajapinta IFormSubmitListener. Mutta voiko sitä käyttää? No eipä tietenkään. Miksei? Siksi, että Form-luokka toteuttaa itse kyseisen kuuntelijan! Ei mitään järkeä… Rajapinnan sijaan kehittäjille tarjotaan ainoastaan onSubmit-adapterimetodi, johon sitten pitää itse kirjoitella oma kuuntelijalogiikka.

Formeihin ei myöskään voi lisätä uusia kuuntelijoita. Sama pätee muihinkin komponentteihin. Wicketin kehittäjät eivät selvästikään ole oikein sisäistäneet Observer-suunnittelumallia. Aivan kuin he olisivat kopioineet ensimmäisen Java-version deprekoidun AWT-tapahtumankäsittelymallin.

Esimerkiksi Wicketin haastaneessa Click-kehyksessä kuuntelijat sidotaan reflectionilla mihin tahansa metodiin:

form.add(new Submit("ok", this, "onOkClicked"));

Itse kyllä pidän perinteisestä rajapintatoteutuksesta enemmän (käännöksen aikainen virheentarkistus, useampia kuuntelijoita, jne), mutta aika näppärä tuokin. Esimerkiksi Echossa homma on kuuntelijoiden osalta tehty tyylipuhtaasti.

(Click on varsin näppärä kehys, mutta itseäni häiritsee sen Velocity-riippuvuus; jos joku on ikinä pahoinpidellyt aivojaan lukemalla Velocityn lähdekoodeja, tietää mistä puhun… Lyhyesti sanottuna: Käyttäkää mieluummin FreeMarkeria!)

Toinen Wicketin häiritsevä ominaisuus on versiointi: Defaulttina kaikki komponenttien tilat kullakin sivun katselukerralla tallennetaan HTTP-sessioon. Henkilökohtaisesti en ole toistaiseksi tätä ominaisuutta missään tarvinnut ja jos kehittäjä ei ole siitä tietoinen, on se mielestäni jopa haitallinen: Back- ja Forward-nappuloita painellessa esimerkiksi ostoskorin tila saattaisi muuttua, jne.

Kaikkein ikävin sivuvaikutus komponenttien tilan versioinnilla kuitenkin on muistinkäyttöön. Jos modelissa nimittäin on vähääkään enempää tavaraa, aiheutuu tuosta nopeasti aika häijy muistivuoto (muisti toki vapautuu session loppuessa, mutta se voi kestää pitkäänkin). Silloin kun kyse on esimerkiksi tietokantahaun tulosjoukosta, kannattaa käyttää LoadableDetachableModel-luokkaa.

Wicketin kolmas heikkous olisi ollut portlet-tuen puute, mutta tajusin juuri, että sellainen löytyykin versionhallinnasta! Koodin on näköjään kirjoittanut Janne Hietamäki Tampereelta. Täytyypä testailla.

Artikkeli on luettu 401 kertaa. Kuuluu luokkiin: Ajatuksia, Ohjelmointi, Java