Frontcontrollers

Tijdens het volgen van een SCWCD (Sun Certified Web Component Developer) training kom je de coolste dingen tegen om een webapplicatie te ontwerpen en implementeren. Er wordt voortdurend op gehamerd dat je elk component in een webapplicatie (POJO, EJB, Servlet, JSP e.d.) moet gebruiken waar het voor dient, en ze niet misbruikt door bijvoorbeeld logica in een JSP te gaan stoppen omdat dat ook wel werkt. Neen! Men doet er verstandig aan de verschillende lagen van een applicatie te scheiden, het voornaamste voorbeeld hiervan is het MVC (Model-View-Controller) model. De details hiervan laat ik even achterwegen (Wikipedia is your friend) maar kort gezegd krijg je door dit model te implementeren een applicatie waarin de bussiness logic, het ophalen van data uit de bussiness logic en het tonen daarvan van elkaar gescheiden zijn.

Bovenstaande kan gerealiseerd worden door in bijvoorbeeld een servlet de bussiness logic (via EJB o.i.d.) aan te spreken en het resultaat te delegeren naar JSP's die gevuld worden met deze data. Echter is dit model op deze manier ook niet perfect. In een website met omvangrijke grootte kan het schrijven van dergelijke code redundant en onoverzichtelijk worden. Je voelt het misschien al aankomen, maar inderdaad, ze hebben ook hier iets op gevonden. Een techniek (eigenlijk een design-pattern) met een vrij algemene naam "frontcontroller". Frontcontrollers zijn kleine frameworkjes die je kunt gebruiken om de code die je in je controllerlaag gebruikt om de bussiness logic aan te spreken evenals de code die je gebruikt om de view-laag aan te spreken in herbruikbare objecten te stoppen. Op die manier hoef je code om requests af te handelen niet steeds opnieuw te schrijven voor elke servlet die je in je applicatie gebruikt. Dit leidt al gauw tot meer overzicht in de code die makkelijker onderhoudbaar is. Een belangrijke kenmerk van een frontcontroller is dat het een centraal punt vormt in een applicatie voor het ontvangen van requests en het delegeren daarvan.

Een keerpunt van een dergelijke techniek is dat je al je logica zult moeten implementeren in de frontcontroller, wat tot heel wat configuratie en omslachtigheid kan leiden. Bijvoorbeeld het delegeren van een bepaald request naar een bepaalde servlet kun je dan niet even snel met een RequestDispatcher doen, maar je zult een object moeten schrijven dat de configuratie en logica voor die delegatie bevat. Op die manier is het gebruik van een frontcontroller aan de ene kant een zegen en aan de andere kant een vloek. Zoals een bekende voetballer ooit zei (ja, Kruijff): elk noadeel heb een foordeel!

Een bekende Java implementatie van een frontcontroller is Jakarta Struts, wat niet bij iedereen geliefd is. Dit geldt echter ook voor Spring, wat minder bekend is maar ook gebruikt wordt in de webwereld om je controller en view netjes neer te zetten. Spring heeft echter ook roots in de modellaag, eigenlijk een frontcontroller++ :P. Beide technieken implementeren het frontcontroller pattern op hun eigen manier, en je wilt ermee werken of niet. Mij persoonlijk lijkt het gebruik van Struts wel interessant, en misschien zelfs wel nuttig. Echter denk ik niet dat je het moet gebruiken in websites van kleine omvang omdat je dan waarschijnlijk niet het potentieel eruit haalt.

Java Swing: past, present and future

Swing is de lightweight GUI toolkit voor Java, gebouwd op de AWT toolkit. Beide waren al beschikbaar in een van de eerste versies van de JDK's die door Sun werden uitgebracht. Tot op heden is de Swing toolkit niet helemaal meegeëvolueerd met de rest van de JDK. Het maakt bijvoorbeeld nog geen gebruik van generics en de Event Dispatch Thread (de core-thread van Swing waar alle GUI acties op uitgevoerd worden) is qua code nog steeds zoals deze destijds is opgezet. Dit betekent dat het geen gebruik maakt van de concurrency componenten die vandaag de dag met de JDK geleverd worden. Ook zijn de standaard componenten die bij Swing geleverd worden, zoals JTable, JCombobox, etc, behoorlijk kaal en moet je zelf vaak heel wat code schrijven om component op te maken qua functionaliteit en stijl.

Toch wordt in de tussentijd de toolkit wel bijgehouden. Er worden nog steeds bugs uit gehaald en de performance kan blijkbaar nog altijd beter. Tevens worden er verschillende libraries met generieke componenten in de JDK opgenomen die het programmeren in Swing vergemakkelijken. Dit zijn vaak hoger level componenten, ontwikkeld door Swing gebruikers, die een bepaalde functionaliteit bieden die je anders zelf zou moeten ontwikkelen of steeds overnieuw zou moeten schrijven. Op die manier is er voor Swing applicaties steeds minder boilerplate code nodig omdat je steeds meer componenten tot je beschikking hebt die je standaard kunt gebruiken. Denk hierbij aan de SwingWorker, het TimingFramework en JOGL. De laatste maakt zelfs 3D rendering in Swing applicaties mogelijk!

Swing is van nature een toolkit die basisfunctionaliteit voor grafische applicaties biedt, maar wat niet veel mensen beseffen is dat dit juiste de kracht van de toolkit is. Dat heeft ook Sun ingezien en daarom willen ze in de volgende versie van de JDK (ja ja, versie 7 alweer!) gewoon verder gaan met het optimaliseren van de Swing engine. Tevens wordt er hard aan gewerkt om Swing in steeds meer frameworks te integreren. JavaFX bijvoorbeeld zal Swing componenten kunnen gebruiken voor bepaalde functionaliteit in dergelijke applicaties. Het verder uitbreiden van toepasbare Swing componenten laat Sun lekker over aan iedereen die hier aan mee wil werken. Ze hebben zelfs een website opengezet (http://openjdk.java.net/) dat als het zenuwstelsel hiervoor moet dienen.

Ik ben benieuwd wat er van Swing in de toekomst gaat komen. De volgende JDK brengt geen wereldschokkende uitbreiding van de toolkit met zich mee, maar ik denk dat het juist aan de Swing communities is om de toepasbaarheid van Swing te vergroten. Nog steeds, na al die jaren dat Swing in ontwikkeling is, denk ik dat het voor veel ontwikkelaars een ondergewaardeerde toolkit is. Het potentieel van een robuuste, goed presterende applicatie met een mondwaterende gebruikersinterface behoort zeker tot de mogelijkheden maar de mogelijkheid hiervan is niet bij iedereen bekend. Natuurlijk is Swing niet de enige speler meer op de markt als het aankomt op een web- of desktopapplicatie met een mooie grafische interface. Toch is deze toolkit veruit de meest generieke, wat ook meteen zijn kracht en tegelijk zijn zwakte vormt.

Binnenkort ondersteuning van Java op iPhone en iPod Touch

Normaal gesproken blijf ik weg van alles wat met Apple of iPod's te maken heeft, maar als Java programmeur kan ik niet anders dan hier een melding over maken. Sun is druk bezig met het maken van een virtual machine voor Apple's iPhone en iPod Touch. De virtual machine moet vergelijkbaar zijn met Java ME, maar Sun sluit niet uit dat laterna meer mogelijkheden worden toegevoegd.

Sun is begonnen aan de virtual machine dankzij het vrijgeven van de SDK van de iPhone en iPod Touch door Apple eerder deze maand.