Webramverkens dream-team

30 August 2007 // Johan Eltes

Här kommer mina baskrav på webramverk som ska rädda världen från överdrag i webprojekt.

1. Stödja modularisering
2. Flödesstyrning som klarar all slags browser-navigering
3. Flödesstyrning som hanterar underflöden (a’la modala dialoger)

Modularisering

Dialoger ska kunna implementeras och paketeras som löst kopplade moduler (jar-filer). En modul implementerar allt som behövs för en dialog. Det betyder att inga dialog-spcifika resurser ska behöva finnas web-appens WEB-INF-katalog - det ska räcka att alla moduler (i form av jar-filer) finns på web-appens classpath (dvs i WEB-INF/lib eller i i EAR-filen).

Browser-navigering

All sessionshantering som behövs för att vara i synk med användarens aktiviteter ska vara robust implementerade. Det gäller såväl back-knappar som att skapa nya fönster.

Flödestyrning

Dialoger ska enkelt kunna återanvändas som underdialoger. Ramverket ska säkra att request-variabler överförs från underdialog till överordnad dialog vid “uthopp”. Man ska inte behöva skriva en kodrad sessionshantering för att hantera flödet i nedanstående scenario.

Bild saknas

Illlustration

Tillgängliga ramverk för flödesstyrning och browsernavigering

Med risk för att bli tjatig, vill jag hävda att Spring WebFlow är det enda tillgängliga flödesstyrningsramverket som uppfyller kraven på browser-navigering och flödesstyrning. SpringWebFlows konfigurationsfiler läses från klassladdaren, genom att leta efter alla förekomster av ett känt namn. Därmed är vi hemma vad gäller modulariseringen. Varje dialogmodul kan innehålla sin egen flödesdefinition. Som nämnts tidigare, skulle det continuation-baserade ramverket RIFE kunna vara ett alternativ. Det skulle dock innebära att vi får ta “hela paketet”, i form av MVC etc från RIFE, vilket jag tycker är en nackdel. Ett tredje - och betydligt mer lockande alternativ vore Shale (tidigare Struts Shale). Tyvärr utvecklas Shale i ett tempo som hittills inte resulterat i någon release. Men det är klart intressant för framtiden.

Bas-ramverk som stödjer modularisering

Spring WebFlows styrka är dess fokusering - det gör bara en sak och gör det väl. Vi behöver därför komplettera med bas-funktionalitet för webapplikationer - request-hantering, binding och rendrering av html-sidor. Vi har förstås Struts. Men vore det inte naturligt att ta en titt på Java Server Faces - standard-ramverket i Java EE? Spring WebFlow integrerar väl med JSF. Så långt allt väl. Men hur är det med modulariseringen? Kräver JSF att faces-config-filen finns i WEB-INF-katalogen (som är bunden till WAR-arkivet och därför inte kan ägas av respektive modul)? Inte alls! JSF-specen föreskriver att JSF-implementationer ska leta efter faces-config.xml-filer i alla META-INF-kataloger som finns på webappens classpath. Det betyder alltså att varje modul kan bidra med sitt tillskott.

Men hur blir det med html-genereringen? Den enda standard som finns inom Java EE är ju JSP. Och JSP-filer måste ligga i web-appens WEB-INF-katalog. Vi måste alltså se oss om efter alternativ. Facelets känns som en intressant kandidat. Det har färdig integration med JSF och delar många av Tapestry´s förtjänster. Det finns dessutom ett ständigt växande skara av tag-bibliotek för facelets.