Times like these

OpenAjax, Sing# ja varsin kompleksi MVC-kehys

Huhtikuu 12th, 2007

Lueskelin artikkeleita eri JavaScript-kirjastoista ja törmäsin erittäin mielenkiintoiseen keskusteluun OpenAjax Alliancesta:

John Resig - Thoughts on OpenAjax

Uskoin Mootoolsin olevan tämän hetken kehittynein JavaScript-kehys, mutta alan nyt vahvasti kallistumaan JQueryn suuntaan. Eikä tämä ole ainoa syy. Myös Liferay siirtyi JQueryyn.

Toinen erittäin mielenkiintoinen projekti (hieman eri kaliiberia) on Microsoft Researchin Singularity. Kyseessä on mikrokernel-käyttöjärjestelmäprototyyppi, jossa käytetään hyväksi ns. hallittua koodia jo kernelitasolta lähtien.

Projektin sivutuotteena on syntynyt uusi ohjelmointikieli, joka pohjautuu aiempaan Spec#-kieleen. Kielen nimi on Sing# ja siinä on aiempaan Spec# “design by contract“-malliin lisätty Erlang-tyylinen viestinvälitys prosessien kesken. Nyt vain odotellaan kattavampaa dokumentaatiota.

Ja lopuksi sitten otsikossa mainittuun MVC-kehykseen: En tiedä olenko ainoa, mutta mielestäni muuten niin mainiossa Springissä on toistaiseksi sekavin MVC-kehys, johon olen törmännyt. Jo pelkällä controller-hierarkian UML-mallilla tapetoisi pienen yksiön (fieldit jätetty pois):

Kehyksen perusfilosofia tuntuu olevan: “Ylikirjoita ne metodit mitä haluat”. En oikein pidä tästä lähestymistavasta. Ensinnäkin jo sen selvittäminen, että mitä metodeita missäkin prosessoinnin vaiheissa kutsutaan, on vähintäänkin sekavaa. Lisäksi kun saman ylikirjoituksen voi tehdä useammasta metodista, sekavoituu asia entisestään. Esimerkiksi formin submitin voi napata kiinni SimpleFormControllerissa ainakin kahdeksasta eri kohtaa.

Sitten on kaikenlaisia formBackingObject-, initBinder-, referenceData-, onBind- ja handleInvalidSubmit-metodeja ihan yleisimpiä luetellakseni. Ovathan ne tietyllä tapaa loogisia sitten kun luutuvat päähän, mutta esimerkiksi kaksoispostauksen estämisen selvittämiseen meni kyllä hetki (synchronizeSession true, sessionForm true ja handleInvalidSubmitissa showForm BindExceptionilla).

Jos muihin Model 2-kehyksiin verrataan, niin vaikka esimerkiksi Strutsissa on omat ongelmansa, niin ihan rehellisesti sanottuna sen käyttäminen oli erittäin paljon tuottavampaa; ainakaan ei tarvinnut arpoa, että mitä tapahtuikaan missäkin vaiheessa.

Loppukevennyksenä täytyy vielä mainostaa todella karseaa virheenkäsittelykoodia Apache Velocityssä. Montako virhettä löydätte seuraavista luokista?

org.apache.velocity.Template
org.apache.velocity.app.Velocity

Oma suosikkini:

try
{
    return evaluate(  context,  writer,
        logTag, construct.toString() );
}
catch(ParseErrorException pee)
{
    throw pee;
}
catch(MethodInvocationException mie)
{
    throw mie;
}
catch(ResourceNotFoundException rnfe)
{
    throw rnfe;
}
catch(IOException ioe)
{
    getLog().error("Velocity.invokeVelocimacro() failed", ioe);
}
/**
 * pass through application level runtime exceptions
 */
catch(RuntimeException re)
{
    throw re;
}

Ja tietysti kaikki init-metodit heittävät tyylikkäästi Exceptioneita. Eli suosittelen tosiaan edelleen FreeMarkeria.

Artikkeli on luettu 595 kertaa. Kuuluu luokkiin: Ajatuksia, Ohjelmointi, Funtionaalinen ohjelmointi, Microsoft