Als je ooit een webapplicatie in Java hebt geschreven met een Model 2-framework als Struts, Stripes of Spring MVC is de kans groot dat je daarbij JSP’s hebt gebruikt. En als dat zo is durf ik te wedden dat je daar ook helemaal niet over hebt nagedacht. In dit artikel wil ik naar een alternatief, Commons Jelly, kijken. De focus ligt daarbij niet zozeer op hoe je dat voor elkaar krijgt, maar op waarom je dat zou willen.

Jelly in honderd woorden

Jelly is een templatetaal. De templates (meestal scripts genoemd) worden geschreven in XML, waarbij elke tag een actie uitvoert (vergelijkbaar met JSP-tags of Ant-tasks). Het is mogelijk zelf tags toe te voegen; elke collectie van tags (tag libraries) kun je binnen een script een eigen, unieke namespace geven. Tags hebben toegang tot een gedeelde context die onder meer verantwoordelijk is voor het beheren van variabelen. Naast tags kunnen er in scripts expressies voorkomen die bijvoorbeeld de eerder genoemde variabelen gebruiken. De uitvoer van een script is ook XML en kan naar een willekeurige OutputStream geschreven worden (hint: een ServletOutputStream bijvoorbeeld).

Voordelen

Het gebruik van Jelly heeft een aantal voordelen boven het inzetten van JSP’s. Sommige voordelen zijn niet Jelly-specifiek, maar zouden ook gelden bij het kiezen van een andere templatetaal als FreeMarker of Velocity. Feitelijk zijn dat dan dus eerder nadelen van JSP, maar een kniesoor die daar op let. Bovendien ben ik nu eenmaal een fan van Jelly.

Je applicatie moet elders toch al templaten

… voor zover templaten een Nederlands woord is, tenminste. Sjabloneren zou waarschijnlijk het dichtstbij komen, maar je kunt doorslaan. Hoe dan ook: bij een gemiddeld project zit het er dik in dat je vroeg of laat een e-mail moet versturen. Denk bijvoorbeeld aan een welkomstmail na de registratie van een nieuwe gebruiker of een mail rond middernacht naar het gehele ontwikkelteam als er een uitzondering is opgetreden in een weinig gebruikt hoekje van de site (het liefst gevolgd door een sms natuurlijk). En die e-mails zijn natuurlijk niet statisch, maar bevatten dynamische inhoud als de naam van de nieuwe gebruiker respectievelijk de stack trace van de uitzondering.

Het liefst zou je daar dezelfde templatetaal gebruiken als degene die de HTML van je website genereert. Misschien wil je zelfs delen hergebruiken, omdat je HTML-mails verstuurt en de opmaak van de e-mails verdacht veel wegheeft van die van de website. Dit is bij het gebruik van JSP’s niet mogelijk. Ik heb een aantal projecten gezien (inderdaad, ook projecten waar ik aan heb meegewerkt) die voor e-mails dan ook een templatetaal introduceren. Dan rijst toch de vraag: waarom zou je die taal dan ook niet gebruiken om je HTML mee te genereren?

Een ander voorbeeld is het schrijven van HTML vanuit JSP-tags. Vooral in de tags van frameworks zie je vaak nog hele blokken code die HTML-tags naar de JspWriter sturen. Dit gaat ten koste van zowel de leesbaarheid als de onderhoudbaarheid, maar is toch min of meer de beste optie als je JSP’s gebruikt. Bij het gebruik van Jelly is het uitvoeren van een script (met daarin de gewenste HTML) vanuit een tag een fluitje van een cent.

Jelly is gemakkelijk testbaar

Het testen van de viewlaag van de webapplicaties beperkt zich vaak tot de controllers. En als de opgeleverde HTML al wordt getest (bijvoorbeeld met Selenium) is het vaak nodig om de applicatie te deployen. Daardoor zie je niet vaak dat er automatische tests bestaan die controleren of de achtergrondkleur van tekstvelden met een ongeldige waarde wel maroon is. Het voordeel van Jelly is dat het eenvoudig standalone te draaien is (en mochten je scripts uitgaan van een HTTP-omgeving is Spring Mock je vriend). Omdat het Jelly niet uitmaakt waar het naartoe schrijft (een ByteArrayOutputStream ligt bij tests voor de hand) en de uitvoer XML is wordt het testen van de uitvoer van pagina’s opeens veel haalbaarder. Een interessante eigen assert zou bijvoorbeeld hetzelfde kunnen doen als Rails’ assert_select.

Ook de tags zijn overigens goed testbaar: de enige dingen die nodig zijn om ze te testen zijn een context (die je toch al had) en een OutputStream. Als je wel eens geprobeerd hebt een JSP-tag te testen zul je het met me eens zijn dat daar veel meer moeite voor nodig is (als je het halverwege uit frustratie al niet hebt opgegeven natuurlijk).

Een laatste soort test dat eenvoudiger wordt omdat Jelly geen container nodig heeft is een performancetest. Althans, een deel van de performancetests - ik heb het puur over het gemakkelijk kunnen testen dat je pagina binnen 50 milliseconden gerenderd is.

Jelly is flexibel

Jelly is erg pluggable opgezet, waardoor je het grootste deel van het gedrag van Jelly kunt aanpassen wanneer dat je niet aanstaat. Nu zijn er meer frameworks die dat beweren, dus geef ik graag een paar voorbeelden.

Zo wordt standaard JEXL gebruikt als expression language. Nu heeft JEXL een aantal nadelen (zo is er geen ondersteuning voor functies en is de laatste release alweer een aantal jaar geleden), maar gelukkig kun je er binnen tien minuten (en met ongeveer evenveel regels code) voor zorgen dat je Commons EL, MVEL of OGNL kunt gebruiken.

Een ander voorbeeld is hoe Jelly omgaat met witruimte die wordt weggeschreven - het standaardgedrag is teksten en expressies te trimmen, maar hier kan op vrij laag niveau van worden afgeweken. Je hoeft aan de ene kant dus niet bang te zijn dat de voor- of achterkant van je hyperlinks spaties bevatten, maar je hoeft je er ook geen zorgen over te maken of je de spatie tussen je komma en je expressie kwijtraakt; je hebt het zelf in de hand.

Jelly is XML

Ik heb het al even genoemd toen ik de testbaarheid aanstipte, maar in Jelly zijn zowel de scripts als de uitvoer in XML. Aan de templatekant houdt dat in dat je schema’s kunt gebruiken om te bepalen of je script valide is. Wat weer inhoudt dat je een enorme hoeveelheid XML-tools tot je beschikking hebt om scripts in te schrijven. Ik heb nooit kunnen wennen aan IntelliJ, maar Eclipse-gebruikers zullen het met me eens zijn dat het, ongeacht de gekozen XML-editor, nooit minder kan zijn dan de JSP-editor in Eclipse. Aan de uitvoerkant wil het zeggen dat je gemakkelijk kunt meedoen aan de XHTML-hype. Maar ook als je HTML 4 wilt serveren is een filter die de Jelly-uitvoer transformeert niet moeilijk voor te stellen.

Nadelen

Ik wil mijn kop niet in het zand steken: er kleven ook nadelen aan het inzetten van Jelly als viewtechnologie.

De gemiddelde Java-ontwikkelaar heeft meer JSP- dan Jelly-ervaring

Dit typische managersargument bevat een grote kern van waarheid: het is vrij aannemelijk dat de persoon tegenover je veel van JSP’s weet. Misschien is hij zelfs gecertificeerd. De kans dat hij ook Jelly-goeroe is is iets kleiner. Als een van je teamleden de loterij wint is zijn opvolger productiever als je JSP’s gebruikt. Je beheerteam zal je eerder op een biertje trakteren als je projecten gewoon op basis van JSP’s zijn. Allemaal waar.

Al is het wel zo dat je vrij snel handig wordt met Jelly. Je hoeft geen Jelly-certificaat te halen omdat het gewoon niet zo onnodig complex is als JSP’s. Je bent in eerste instantie misschien sneller met JSP’s, maar als je Jelly onder de knie hebt is het andersom.

Jelly kan geen JSP-tags uitvoeren

Hoewel Jelly-tags vergelijkbaar zijn met JSP-tags zijn ze niet uitwisselbaar. En misschien heb je een vrij grote collectie van JSP-tags die je regelmatig gebruikt. Of gebruik je een framework dat alleen JSP-tags meelevert. Dan ligt het inderdaad niet voor de hand om dat allemaal weg te gooien. Hoewel het mogelijk is een omgeving op te zetten waarin JSP-tags kunnen worden uitgevoerd. Het valt buiten de scope van dit artikel om uit te leggen hoe je dit precies zou moeten aanpakken, maar dat het kan bewijst FreeMarker (zij het ietwat rommelig).

Jelly wordt niet actief onderhouden

Waarschijnlijk het grootste nadeel: Jelly heeft (ook na een lange pauze) 1.0 gehaald, maar er zijn niet veel mensen die staan te springen om het framework te verbeteren en uit te breiden. James Strachan (de bedenker) heeft een nieuw speeltje en de meeste gebruikers zijn inderdaad alleen gebruiker: ze consumeren zonder terug te geven. Gelukkig is het project open source.

Conclusie

Hoewel veel templatetalen een verbetering zouden zijn ten opzichte van JSP heeft Jelly een streepje voor: het is snel te leren, bevordert hergebruik van (delen van) templates, is zowel testbaar als flexibel en is verzekerd van tooling door de keuze voor XML. Ondanks de nadelen (en welke keuze heeft nou geen nadelen) hoop ik dat ik je op zijn minst aan het denken heb gezet voor je eerstvolgende project.

Werken bij Finalist als Java/JEE developer?