De Browser-Back knop op internetschermen is een zege voor de eindgebruiker en een nachtmerrie voor de webapplicatie-bouwer. De eindgebruiker is er blij mee, omdat hij altijd naar een vorige situatie terug kan. De bouwer is er niet blij mee, want met deze knop verliest hij de controle op de volgorde van te bezoeken webpagina’s.
Bovendien heeft de Browser-Back button een zusje: de Browser-Forward button. En richten verschillende browsers het gedrag van de Browser-Back knop verschillend in.
Hieronder beschrijven we welke concepten we hebben gebruikt om de Browser-Back button op te vangen in een webapplicatie met een flexibele workflow. Onze oplossing is gebouwd in Java, maar de concepten zullen ook in andere programmeeromgevingen bruikbaar zijn. Wij hebben onze oplossing toegepast in een adresboek ontwikkeld voor een Onderzoeksbureau van de Rijksoverheid. Voor het toevoegen van een nieuwe medewerker moeten de volgende stappen doorlopen worden.
- Voer naw gegevens van de medewerker in
- Voeg de medewerker toe aan 1 of meer categorien
- Controleer de gegevens van de nieuwe medewerker
- Voeg de gegevens toe aan de database
- Meld dat de actie is uitgevoerd
De invoer van de gegevens gebeurt met jsp’s. Een jsp wordt voorafgegaan door een Access-servlet, waarin autorisaties worden geverifieerd en helpers worden gevuld. Deze helpers worden gebruikt om de informatie in de jsps te tonen, en te zorgen dat de jsps niet te complex worden. De oplossing om de Browser-Back button op te vangen maakt gebruik van:
- Cookies om de ingang van de jsp via de Access files te garanderen
- een server-worker pattern voor hergebruik van de code
- Een stack met variabelen voor het bewaren van scherminvoer
Cookies
Wanneer de eindgebruiker op de Browser-Back toets klikt, dan gaat de browser terug naar de vorige pagina. Deze vorige pagina kan de jsp zijn, of de Access voorafgaand aan de jsp. Dit is afhankelijk van de instellingen van de browser, i.e. dit wordt buiten de applicatie-code geregeld. Om te garanderen dat jsps altijd via de bijbehorende Access file benaderd worden, zetten we de cookie “entrypage” in de Access file. De eerste actie bij binnenkomst van de jsp is het verwijderen van de cookie. Als de jsp vervolgens benaderd wordt zonder de Access uit te voeren, dan wordt eerste de Access-page uitgevoerd, en daarna de jsp.
Deze techniek is ontwikkeld op basis van diverse engels-talige bijdragen en voorbeelden die over dit onderwerp op internet te vinden zijn.
Cookies moeten op de goede plek in de hierarchie ingezet worden. Met de Webdeveloper plugin van de firefox browser kun je eenvoudig controleren of de cookies juist in de hierarchie worden geplaatst.
Service-to-Worker pattern
Het Service-to-Worker pattern is een elegante manier om workflows te bouwen en tegelijk het aantal servlets en access-classes te beperken. Bij het Service-to-Worker pattern worden de functionaliteit en de volgorde van de stappen van elkaar gescheiden. Je krijgt dus een bestand met stap-volgordes, in ons geval een xml bestand. Een regel in het xml-bestand bestaat uit een start-status, een doel-status en een actie. Wanneer de applicatie in start-status is, dan gaat hij naar doel-status na het succesvol uitvoeren van de actie. Wij hebben deze techniek gehaald uit:
J2EE Design Patterns, William Crawford and Jonathan Kaplan, O’Reilly, 2003
Doordat de functionele classes en jsps geen workflow informatie bevatten kun je ze op verschillende plekken in verschillende workflows hergebruiken. Hergebruik komt de kwaliteit en de onderhoudbaarheid van de software ten goede.
Maar omdat de functionaliteit en de workflow van elkaar gescheiden zijn, staat in de jsps niet meer aangegeven wat de volgende stap is. Dat is geen probleem wanneer de jsps in volgorde achter elkaar worden uitgevoerd, dan is immers het xml-bestand met de stap-volgordes leidend. Maar dat is wel een probleem wanneer een eindgebruiker op de Browser-Back of de Browser-Forward klikt. Dan wijzigt de eindgebruiker de volgorde van stappen buiten het xml-bestand om.
Onze oplossing is een link te bouwen tussen de jsps en het xml-bestand met stapvolgordes. Deze link is de naam van de jsp, die een jsp altijd zelf kan bepalen., en die overeenkomt met een start-status in het xml-bestand. Zo kan de web-applicatie altijd dynamisch bepalen wat de volgende stap is en welke stap dan uitgevoerd moet worden.
De search-stack
Door ervoor te zorgen dat een jsp altijd voorafgegaan wordt door een Access pagina, kan informatie die de eindgebruiker handmatig op een scherm invoert verloren gaan. Om de eindgebruiker beter van dienst te zijn bewaren we in een stack de laatste keuzes van de eindgebruiker.
Essentieel in de stack is het veld entrypage. In dit veld staat de naam van de Accessfile waarmee de jsp benaderd wordt. Bij binnenkomst zoekt de Accessfile het stackitem met de juiste naam en haalt de meest recente gegevens uit dit stackitem.
In de stack wordt en teruggezocht en vooruitgezocht. In die zin is het niet een echte stack. Bij het uitvoeren van een actie vanaf een pagina midden in de stack worden de items boven deze plek uit de stack gehaald.
Samenvatting
Omdat de Browser-Back knop zoveel waarde heeft voor de eindgebruiker moet deze button in een webapplicatie beschikbaar blijven. Wij gebruiken in onze applicaties een combinatie van:
- Cookies, om af te dingen dat jsps altijd benaderd worden vanuit de Access file
- Een Service-to-Worker pattern met als status de jsps om hergebruik van code te bevorderen
- Een stack om de laatste invoer van de eindgebruiker te bewaren
Let op: wellicht zijn cookies niet nodig, en kun je de binnenkomst van een jsp via de Access file afdwingen met zgn filters. Als jij daar ervaring mee hebt, of als je andere verbeteringen in deze aanpak ziet, dan stel ik een reactie op prijs.
Sophie Fischer
Sponiza !T
www.sponiza.nl
www.etikettenprinten.nl
