Integration av AJAX i JDP : En studie i hur WM-data kan utveckla modelleringsstödet i ett webbramverk

Examensarbete

Integration av AJAX i JDP

En studie i hur WM-data kan utveckla modelleringsstödet i ett

webbramverk

av

Arthur Carlsson

Liu-IDA/Lith-Ex-A 08/005-SE

2008-03-29

Linköpings universitet Institutionen för datavetenskap

Examensarbete

Integration av AJAX i JDP

Arthur Carlsson

Liu-IDA/Lith-Ex-A 08/005-SE

2008-03-29

Handledare: Peter Dalenius, Linköpings universitet, Linköping Pär Hansson, WM-data, Östersund

Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport Språk Language Svenska/Swedish Engelska/English Titel

Title Integration av AJAX i JDP

En studie i hur WM-data kan utveckla modelleringsstödet i ett webbramverk

Författare

Author Arthur Carlsson

Sammanfattning

Abstract

ISBN

ISRN Liu-IDA/Lith-Ex-A 08/005-SE

Serietitel och serienummer ISSN

Title of series, numbering

Nyckelord

Datum

Date

URL för elektronisk version

X

Avdelning, institution

Division, department

Institutionen för datavetenskap Department of Computer and Information Science

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-11646

På WM-data har man utvecklat ett ramverk som heter Java Development Platform med avsikt att modellera större delar av ett system och därmed minska mängden kod som måste skrivas för hand. Ramverket baseras helt på existerande öppna lösningar och används vid utveckling av webbaserade system och skapar en skiktat lösning med en webbapplikation som presentationslager. Problemet är att webbapplikationen har kommit att bli väldigt svår att modellera i enhet med resten av systemet framför allt på grund av den hårda kopplingen till Struts-ramverket. Samtidigt har man börjat få upp ögonen för AJAX och vad det skulle kunna tillföra ramverket.

Examensarbetet fokuserar på att utreda de problem som existerar i ramverket samt undersöka integrationen av AJAX ur en synvinkel som gynnar dagens lösning. Detta görs genom litteraturstudier, laborationer och genom att undersöka existerande ramverk och plattformar som löser liknande problem. Fokus ligger även på hur AJAX kan användas för att lösa problemen i modelleringen.

Resultatet av arbetet mynnar ut i en analys som behandlar de aspekter som krävs för att AJAX ska kunna bli en del av JDP-ramverket. Analysen innefattar också synen på hur AJAX skulle kunna användas för att underlätta

modelleringen av webbapplikationen utan att införa något nytt modelleringsverktyg, det vill säga att UML fortfarande kan användas.

2008-03-29 _{Linköpings universitet}

X X

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga

extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,

skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för

ickekommersiell forskning och för undervisning. Överföring av upphovsrätten

vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,

säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ

art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i

den omfattning som god sed kräver vid användning av dokumentet på ovan

beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan

form eller i sådant sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se

förlagets hemsida

In English

The publishers will keep this document online on the Internet - or its possible

replacement - for a considerable time from the date of publication barring

exceptional circumstances.

The online availability of the document implies a permanent permission for

anyone to read, to download, to print out single copies for your own use and to

use it unchanged for any non-commercial research and educational purpose.

Subsequent transfers of copyright cannot revoke this permission. All other uses

of the document are conditional on the consent of the copyright owner. The

publisher has taken technical and administrative measures to assure authenticity,

security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be protected

against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,

please refer to its WWW home page:

Sammanfattning

På WM-data har man utvecklat ett ramverk som heter Java Development Platform med avsikt att modellera större delar av ett system och därmed minska mängden kod som måste skrivas för hand. Ramverket baseras helt på existerande öppna lösningar och används vid utveckling av webbaserade system och skapar en skiktat lösning med en webbapplikation som presen-tationslager. Problemet är att webbapplikationen har kommit att bli väldigt svår att modellera i enhet med resten av systemet framför allt på grund av den hårda kopplingen till Struts-ramverket. Samtidigt har man börjat få upp ögonen för AJAX och vad det skulle kunna tillföra ramverket.

Examensarbetet fokuserar på att utreda de problem som existerar i ram-verket samt undersöka integrationen av AJAX ur en synvinkel som gynnar dagens lösning. Detta görs genom litteraturstudier, laborationer och genom att undersöka existerande ramverk och plattformar som löser liknande pro-blem. Fokus ligger även på hur AJAX kan användas för att lösa problemen i modelleringen.

Resultatet av arbetet mynnar ut i en analys som behandlar de aspekter som krävs för att AJAX ska kunna bli en del av JDP-ramverket. Analysen in-nefattar också synen på hur AJAX skulle kunna användas för att underlätta modelleringen av webbapplikationen utan att införa något nytt modellerings-verktyg, det vill säga att UML fortfarande kan användas.

Abstract

At the WM-data company a framework called Java Development Platform has been developed with the intention of developing a system by first model-ling and generating a major part of it instead of handwriting everything from scratch. The framework is based solely on existing open source solutions and is used for developing layered web based systems with the web application as the presentation layer. The problem is that the web application has become very difficult to model in the same way as the rest of the system especial-ly due to the tight coupling between the model and the Struts framework. At the same time, AJAX has been getting more and more attention for its application areas as well as how it can be used to solve the problems with modelling the web application.

The thesis intends to focus on researching the existing problems in the framework as well as investigate the integration of AJAX from a standpoint that the framework can benifit from. This is done through literature studies, laborations and by looking at existing frameworks and platforms that aim to solve problems like the ones in JDP. The focus also lies on how AJAX can be used to solve the problems with modelling the web application.

As a result, the thesis ends in an analysis which considers the aspects needed for implementing AJAX into the JDP framework. The analysis also discusses how AJAX can be used to facilitate the modelling of the web appli-cation without having to model it in another way other than through UML diagrams.

Innehåll

1 Inledning 1

1.1 Syfte och frågeställning . . . 2

1.2 Metod och källor . . . 2

1.3 Förutsättningar . . . 3 1.4 Struktur . . . 3 2 JDP 5 2.1 Bakgrund . . . 5 2.2 Ramverkets verktyg . . . 7 2.3 Genereringsflödet . . . 7 2.4 Lager . . . 8 2.4.1 Domän . . . 9 2.4.2 Tjänst . . . 10 2.4.3 Webbapplikation . . . 10 3 Struts 11 3.1 Model-View-Controller . . . 12 3.1.1 Modellen . . . 12 3.1.2 Vyn . . . 13 3.1.3 Kontrollern . . . 13 3.2 Model-View-Controller i Struts . . . 13

3.2.1 Modellen - Javabönor och businesslogik . . . 14

3.2.2 Vyn - JSP och taglibs . . . 15

3.2.3 Kontrollern - Action-klasser och URL-mappning . . . . 16

3.3 Andra lösningar . . . 18

3.3.1 Barracuda . . . 18

3.3.2 Java Server Faces . . . 20

4 JavaScript 25 4.1 ECMAScript . . . 26 4.1.1 Objektorientering i ECMAScript . . . 28 4.1.2 Objekt . . . 30 4.2 DOM . . . 31 4.3 JavaScript i webbläsare . . . 32 4.4 Säkerhet . . . 33 5 AJAX 35 5.1 XMLHttpRequest . . . 36 5.2 Uppkopplingsflöde . . . 36 5.3 Klient-server-kommunikation . . . 38 5.3.1 XML . . . 39 5.3.2 JSON . . . 40 5.4 Kritik . . . 41 5.5 Alternativa lösningar . . . 42 5.5.1 Ramar . . . 43

5.5.2 XUL och XAML . . . 43

6 Analys 45 6.1 Modell av webbapplikationen . . . 45

6.2 Integration av AJAX . . . 47

6.2.1 Kommunikationsprotokoll . . . 47

6.2.2 Klient- och servergränssnitt . . . 48

6.2.3 Felhantering . . . 49

6.2.4 Användarvänlighet . . . 50 7 Slutsatser och framtida arbete 51 Litteraturförteckning 54

A Stereotyper i JDP 55

Figurer

2.1 Lagerstrukturen i JDP. . . 9

3.1 Modulstrukturen enligt Cavaness (2004) . . . 11

3.2 Diagram över komponentberoendet i ett MVC-system . . . 12

3.3 Översikt av Barracuda. . . 23

3.4 Struts modularkitektur. . . 23

4.1 De typer av objekt som existerar i ECMAScript. . . 30

5.1 Den traditionella modellen för webbapplikationer. . . 37

5.2 Skillnaden mellan en traditionell och AJAX-driven webbap-plikation. . . 38

Listningar

3.1 Exempel på tiles-def.xml. Källa: Cavaness (2004). . . 16

3.2 Metoden execute som ska implementeras . . . 17

3.3 Exempel på ett action-element. Källa: Cavaness (2004). . . 17

3.4 Signaturen för execute() i Struts 2.0 . . . 21

4.1 Exempel på inkludering kontra inbakad JavaScript-kod . . . . 32

4.2 Kod för att kontrollera skapande av fönster . . . 34

5.1 Exempel på hur ett XML-svar kan se ut från servern. . . 39

5.2 Exempel på hur XML-svaret används på klientsidan. . . 39

5.3 Exempel på hur JSON används . . . 41

5.4 Kod som konverterar vanliga länkar till JavaScript-funktioner. 42 5.5 Exempel på anrop till yttre ramen i JavaScript . . . 43

6.1 Exempel på en tjänst i JavaScript . . . 48

Kapitel 1

Inledning

Skillnaderna mellan webb- och skrivbordsapplikationer har alltid varit tyd-liga. En webbapplikation är ett sätt att representera information med hjälp av text och bilder medan en applikation utför sofistikerade beräkningar och komplexa operationer utan väntetider mellan dialogerna. Denna skillnad bör-jar bli allt suddigare då ett nytt sätt att utveckla webbapplikationer har gjort att webbapplikationer mer och mer börjar likna skrivbordsapplikationer. En betydande komponent i utvecklingen är AJAX, Asynchronous JavaScript and XML, som möjliggör dynamiska anrop till andra sidor utan att en ny sida måste visas för användaren, vilket ger en väldigt stakande och statisk känsla. AJAX har kommit att få stort genomslag på webben och har spelar en stor roll i Web 2.0-fenomenet, det vill säga någon form av vidareutveckling av den traditionella mer statiska webben. Tidigare var webbsidor helt oberoende varandra utan möjlighet att ändra innehållet efter de blivit uppritade. De webbapplikationer som idag utvecklas påminner mer och mer om traditionel-la skrivbordsapplikationer snarare än hemsidor vilket påverkar användarens upplevelse av hur hemsidan uppför sig.

På WM-data har ett ramverk kallat JDP, Java Development Platform, används för att utveckla webbapplikationer. Ramverket fungerar genom att först beskriva systemet med hjälp av en modell för att på så sätt få en hel del källkod och applikationskonfiguration, som annars skulle kräva en hel del arbete, genererat. Detta sparar inte bara tid och resurser utan låter även utvecklaren koncentrera sig på den verkliga funktionaliteten istället för att handskriva en hel del konfiguration. Nu har man på WM-data börjat få upp ögonen för vad AJAX skulle kunna tillföra ramverket samtidigt som man vid modellering av webbapplikationen stött på problem; problem som AJAX i teorin ska kunna lösa.

JDP är hårt knutet till ett annat webbramverk som kallas Struts. När sy-stemet modelleras måste Struts beskrivas då webbapplikationen modelleras,

1.1. SYFTE OCH FRÅGESTÄLLNING KAPITEL 1. INLEDNING

vilket inte bara gör modellen komplex utan även svår att förstå för den som inte är insatt i hur Struts fungerar.

1.1

Syfte och frågeställning

Syftet med arbetet är att göra en djupgående utredning av AJAX utifrån en synpunkt som har WM-datas ramverk i åtanke. Utredningen ska alltså göras för att bestämma hur Struts kan dra nytta av AJAX, om AJAX kan ersätta Struts eller om en AJAX-lösning helt ska utebli. Många lösningar existerar redan idag som skulle möjliggöra integration av AJAX men det är viktigt att lösningen är väl fungerande med resten av JDP-ramverket.

Utredningen ska också innefatta hur en AJAX-lösning påverkar proble-men vid modelleringen av webbapplikationen. Idag modelleras webbapplika-tionen med hjälp av rena klassdiagram vilket inte är någon bra lösning. AJAX skulle kunna hjälpa till att förbättra sättet att rita webbapplikationen.

Frågor som detta ger upphov till är:

• Hur ska webbapplikationen kunna modelleras? • På vilket sätt påverkar AJAX modelleringen?

• Hur kan en AJAX-driven lösning se ut som fungerar ihop med det existerande ramverket?

1.2

Metod och källor

För att få en tydligare bild av de tekniker och verktyg som används i ram-verket och den tänkta lösningen görs en litteraturstudie med avseende på just detta. Detta innefattar såväl böcker som examensarbeten och standar-der. Även andra lösningar studeras för att få inspiration och idéer för hur de har löst vissa problem som påminner om de i WM-datas ramverk. Som ett komplement till litteraturstudien görs laborationer på de studerade delarna. Detta för att få en bättre förståelse för de områden som studeras samt för att studera de exempel och lösningar som presenteras i litteraturen. Slutli-gen görs en grov ”proof of concept”, det vill säga en enkel implementation av principerna i utredningen vilket bevisar att exemplen på de lösningar som presenteras och diskuteras i utredningen verkligen fungerar.

Den huvudsakliga källan för information i kapitlet om Struts är hämtad från dess dokumentation där ramverket finns väl beskrivet samt motivation till lösningarna som gjorts. För att sedan få en bild av hur dokumentationen

KAPITEL 1. INLEDNING 1.3. FÖRUTSÄTTNINGAR

kan tolkas har böcker som rör ämnet studerats; dels litteratur som tillämpar ramverket och dels ett konkurerande ramverk som med samma vision men med en annorlunda lösning.

I kapitlet om JDP har mycket intern dokumentation för ramverket an-vänts, men även dokumentation för de enskilda komponenterna som används i ramverket. Från det att dokumentationen skrevs har en del hänt som inte dokumenterats vilket har gjort att information har fått hämtats från medar-betare på WM-data.

Till kapitlen om JavaScript och AJAX har information hämtats främst från litteratur med inriktning mot dessa två tekniker. I kapitlet om JavaScript har en hel del ur standarden för ECMAScript används eftersom det är denna standard som JavaScript bygger på. Eftersom AJAX är ett så pass nytt begrepp har artiklar som kritiserar tekniken samt artikeln som inledde hela hysterin använts som material i AJAX-kapitlet.

1.3

Förutsättningar

Rapporten beskriver och utreder ett problem i en Java Enterprise-miljö som inte beskrivs närmare här. Läsaren förväntas alltså ha kunskaper inom områ-det så till den grad att han eller hon vet hur en J2EE-applikation är uppbyggd med till exempel servlets och konfiguration av en applikation i web.xml. Dess-utom diskuteras Javabönor eftersom WM-datas JDP-ramverk till stor del an-vänder sig av detta. Konceptet med Javabönor förklaras inte utan förväntas vara en förkunskap hos läsaren.

Eftersom den modellering som beskrivs inte är speciellt djupgående läggs ingen vikt på att beskriva modelldriven arkitektur. Dessutom innefattar inte utredningen i första hand problem inom modelldriven utveckling utan snarare ett sätt att grafiskt representera en webbapplikation. Detta medför att även modellering inte förklaras i rapporten utan det är upp till läsaren att ha detta som en förkunskap.

1.4

Struktur

Detta arbete försöker följa uppställningen av en rapport och är samtidigt hårt styrt av de formella krav som ställs på ett examensarbete.

Rapporten inleds med ett kapitel vilket beskriver ramverket som ska utre-das för att få en inledning till de följande tre kapitlen. Dessa kapitel är även de rent teoretiska kapitel som beskriver tekniker som idag redan används (Struts) eller man skulle vilja använda (JavaScript och AJAX).

Avslutnings-1.4. STRUKTUR KAPITEL 1. INLEDNING

vis kommer ett kapitel innehållande en analys av de påstådda problemen samt en enkel implementation av en lösning till dessa.

Kapitel 2

JDP

JDP (Java Development Platform) är ett ramverk som utvecklats av WM-data. Ramverket fungerar som ett klister som binder samman ett antal verk-tyg och är inte en helt fristående produkt. Beskrivningen i den inledande delen av dess populärbeskrivningen säger:

The Java Development Platform (JDP) is a packaging of several open-source software products that are configured to support model driven development. Best-of-breed products and practices increases efficiency and quality, and a non-commitment to any specific architecture, tool or technique prevent lock-in.(Jönsson & Allberg 2004)

Den huvudsakliga tanken med ramverket är att genom modellering av ett system ges en helt annan överblick jämfört med vad enbart kod kan ge. Därför utvecklas ett system med JDP i första hand genom att modellera en större del för att sedan implementera funktionalitet utifrån kod som kan genereras från modellen. Istället för att låta programmeraren skriva tidsödande och vid upprepade tillfällen lösa standardiserade problem så ges ramverket denna uppgift genom att generera denna källkod vilket ger programmeraren tid att lägga på implementation av funktionalitet. Enligt Jönsson & Allberg (2004) sägs ett system vanligtvis bestå av mer än 70% källkod och konfigurationsfiler som skulle kunna genereras.

2.1

Bakgrund

I början av 2000-talet hade WM-data fått sig en bild av hur utvecklingspro-cessen på företaget bedrevs. När ett nytt projekt skulle påbörjas gick mycket tid och kraft åt till att sätta upp standarder och regelverk för projektet. Det var också uppenbart att en stor del av utvecklingsprocessen gick åt till att skriva samma typ av tidsödande och tråkig kod vid upprepade projekt.

2.1. BAKGRUND KAPITEL 2. JDP

I och med introduktionen av Microsoft .NET fick man upp synen för hur detta skulle kunna lösas - ett ramverk som genom objektorienterad model-lering och tjänsteorienterad design ska kunna generera standardiserad och färdigskriven källkod för den tidsödande delen av systemet. Resultatet blev WmBof, WM-data Business Object Framework.

Det objektorienterade synsättet går ut på att i den riktiga världen iden-tifiera objekt och klasser, dess beteenden samt relationer mellan dem. Att arbeta tjänsteorienterat innebär däremot att en applikation tillhandahåller sin funktionalitet genom tillståndslösa komponenter innehållande metoder. Metoderna ska vara så tillståndslösa som möjligt genom att frigöra resur-ser, exempelvis databaskopplingar, så snabbt som möjligt vilket då ger ett väldigt skalbart system. WmBof-ramverket kombinerar det bästa från två världar genom att ta fördelarna från de båda synsätten där den objektorien-terade modelleringen ger ”en bra bild av systemet och vad det skall kunna utföra”(WM-data 2001, s. 5) samtidigt som den tjänstebaserade designen ger ett skalbart system.

WmBof är ett ramverk skrivet för Microsofts .NET-plattform som ger utvecklaren möjligheten att designa systemet genom att göra en modell i modelleringsverktyget som medföljer Microsoft Visual Studio 2005. Genom att märka modellerna med metadata, som exempelvis stereotyper, används sedan WmBofWizard för att generera C#-kod i form av klasser som är upp till utvecklaren att implementera.

Man fann på WM-data att detta sätt att utveckla system gav ett snabbt och välkontrollerat utvecklingsförfarande samt ett system som var överskåd-ligt och lätt att underhålla. Därför gjordes ett beslut att utveckla ett liknande system för webbutveckling i Java. Ett beslut togs att Niklas Allberg på WM-data i Östersund skulle översätta WmBof till Java och efter en viss tids arbete var projektet färdigt.

Med åren har ramverket kommit att förändras en del från det att förs-ta versionen blev färdig. Det störsförs-ta beslutet om ändring som gjorts är att det ursprungliga modelltolken, AndroMDA, som beskrivs i sektion 2.2, har slopats då det visade sig att det tillägg till Rational Rose som exportera-de moexportera-dellen till ett filformat som AndroMDA kunexportera-de tolka inte mötte exportera-de krav som WM-data ställde på det. Dessutom kom AndroMDA att bli väldigt långsamt när modellerna började bli stora vilket hade som resultat att ett projekt kunde ta upp till 20 minuter att bygga. När den ersättande tolken introducerades kunde projektet byggas på så kort tid som fem minuter.

KAPITEL 2. JDP 2.2. RAMVERKETS VERKTYG

2.2

Ramverkets verktyg

Ramverket består i huvudsak av verktyg med öppen källkod. Man har på WM-data varit noga med att välja dem utifrån dess licenser som är skrivna så att verktygen kan användas i kommersiellt syfte. Till exempel distribu-teras Eclipse under EPL (Eclipse Public License) som tillåter kommersiell distribution om distributören tar ansvar för konsekvenser som Eclipse kan medföra: ”While this license is intended to facilitate the commercial use of the Program [Eclipse], the Contributor [WM-data] who includes the Pro-gram in a commercial product offering should do so in a manner which does not create potential liability for other Contributors [tredjeparter].”(Eclipse Foundation 2006)

AndroMDA är licensierat under en BSD-licens och användes tidigare för att generera källkod från modeller. Numera har dock verktyget ersatts av en egenutvecklad tolk för Rational Rose-modeller då det tidigare modellverkty-get inte motsvarade de krav som WM-data ställde.

Eclipse distribueras under EPL version 1.0. Eclipse är en erkänd utveck-lingsmiljö för Java och används för att skriva implementationen till systemet i de genererade abstrakta klasserna genom att JDP sätter upp ett projekt där bland annat tillhörande bibliotek och variabler i Eclipse är förinställda. All utveckling bortsett från modellering sker i Eclipse.

För att ytterligare kunna styra byggförfarandet används Ant som licen-sieras under en Apache 2.0-licens. Ant kan liknas med GNUs make då bygg-förfarandet beskrivs i en fil som Ant sedan läser av och exekverar från början till slut. Här kan bland annat anges om kommandon ska köras, filer ska ko-pieras eller kompileras. Det går även att bygga ut Ant med egna byggdirektiv för att ytterligare anpassa bygget till projektet.

Utifrån modellen genereras klasser och metadata i form av Java-kommentarer som sedan tolkas av XDoclet och som i sin tur genererar konfigurationsfiler åt andra delar av systemet. XDoclet, vars roll beskrivs närmare i kapitel 2.3, är licensierat under en egen licens tillsammans med Jakarta Ant- och Xerces-licenser och har som uppgift att läsa Javadoc-kommentarer. I kommentarerna anges vilken typ av kommentar det rör sig om och utifrån det beräkna vad som ska genereras vilket i JDPs fall är konfigurationsfiler till bland annat Struts.

2.3

Genereringsflödet

En central del i ramverket är att kunna generera källkod från systemets modell. Mycket arbete har lagts ner på att göra denna process så

användar-2.4. LAGER KAPITEL 2. JDP

vänlig som möjligt och resultatet är en utvecklingsmiljö där utvecklaren kan lägga fokus på affärslogik istället för att lägga mycket energi på att skriva konfigurations- och bibliotekspecifik funktionalitet.

Flödet börjar med att utvecklaren får beskriva systemet i modellerings-verktyget med hjälp av klasser i ett klassdiagram. Här märks modellen med stereotyper och tagged values som läses av generatorn. De stereotyper en klass kan märkas med är de som listas i bilaga A. När modellen väl är färdig sparas den i en Rational Rose-modell för att sedan gå igenom en generering till redigerbar källkod.

När modellen behandlas i det första byggsteget tolkas den med hjälp av en tolk man utvecklat på WM-data. Tolken använder sig av den metadata som utvecklaren applicerat på modellen för att beräkna hur källkoden ska genereras och placerar den på den plats som anges i byggfilen. Ett antal filer genereras men framför allt en gränssnittsklass och en tillhörande im-plementerande klass. Därefter får utvecklaren implementera de genererade klasserna.

I det första genereringsmomentet beräknades, utifrån metadata på mo-dellen, även metadata åt de genererade klasserna i form av Javadoc-specifika kommentarer. Denna metadata används i nästa byggmoment då XDoclet genererar information i form av konfigurationsfiler åt andra delar i syste-met, framförallt till Struts och EJB, Enterprise Java Beans. I vanliga fall skriver utvecklaren denna information själv för hand men genom att detta kan automatiseras utifrån modellen där det går att beräkna hur XDoclet-informationen ska se ut krävs inte detta av utvecklaren.

Det slutgiltiga steget är helt enkelt att bygga färdigt systemet genom att kompilera källkoden till binärkod, packa ihop det till en webbapplikation och sätta upp den i applikationsservern.

2.4

Lager

JDP är uppdelad i tre lager: domän, tjänst och webbapplikation. De två förs-ta är de djupaste lagren och innehåller funktionaliteten för systemet medan webbapplikationslagret kopplas på utanpå de två andra för att represente-ra systemet. Ett lager kan endast kommunicerepresente-ra med lagret närmast innanför sig, exempelvis kan inte webbapplikationen direkt kommunicera med domän-lagret. Det måste göras genom tjäntlagret som då kan behandla frågan vidare till domänlagret, vilket illustreras i figur 2.1.

Att webbapplikationen är skriven separat från de andra två lagren gör att det kan bytas ut väldigt enkelt och en annan typ av applikation kan utnyttja samma underliggande arkitektur som tidigare.

KAPITEL 2. JDP 2.4. LAGER

Figur 2.1: Lagerstrukturen i JDP.

En stor fördel med att systemet är konstruerat i en lagerstruktur är att validering av in- och utparametrar till tjänster ärvs mellan lagren. Detta gör att varje enskilt lager inte behöver förlita sig på egen validering, vilket skulle bli väldigt statiskt och opraktiskt. Exempelvis om systemet skulle uppda-teras, exempelvis så att formatet på ett värde plötsligt blir ogiltigt, gör en oskiktad lösning att valideringskod måste uppdateras i ett flertal delar av systemet. Med lagerstrukturen som JDP har behöver endast valideringen i det innersta lagret uppdateras.

2.4.1

Domän

Längst in i kärnan av ett system ligger, som i många andra fall, information i form av databaser och annan långtidslagrad information. Denna information utgör alltså domänlagret och implementeras i javakoden med hjälp av enti-tetsbönor. Först modelleras bönorna där de tillsammans med dess metoder markeras med EJB-stereotyper samt att vanliga hjälpmetoder modelleras.

Just dessa bönor innehåller inte mer än genererade metoder, med ett in-ternt gränssnitt mot en databas, tillsammans med privata och publika hjälp-metoder. Eftersom man använder sig av EJB erhålls mycket funktionalitet genom generering av EJB-kod.

2.4. LAGER KAPITEL 2. JDP

2.4.2

Tjänst

Det externa gränssnittet, som ger det presenterande lagret tillgång till do-mänlagret, utgörs av tjänstlagret. Det byggs upp med hjälp av tillståndslösa sessionsbönor som innehåller tjänstemetoder. Bönan exponerar sitt gräns-snitt genom XDoclet-kommentarer som är genererade utifrån modellen. XDoclet genererar då information som krävs för EJB vilket gör att utvecklaren inte behöver bry sig om det. Till sist måste implementationen skrivas för hand, inklusive bland annat validering och kommunikation till domänlagret.

2.4.3

Webbapplikation

Det som motsvarar presentationslagret i WmBof är webbapplikationslagret i JDP. Här används en vanlig applikationsserver tillsammans med Struts-ramverket för att implementera kommunikationen mellan användare och tjäns-telagret. Man tvingas därför använda JSP för presentation av informationen som yttersta teknologi i webbapplikationen.

Webbsidorna modelleras i form av ett klassdiagram där allt från formulär och Action-klasser till vidarebefodring måste beskrivas. Genom att namnge associationer och märka dem med en ForwardMapping-stereotyp kan konfi-guration genereras till Struts. På samma sätt märks klasserna så Action- och ActionForm-klasser kan genereras till projektet.

Struts har kommit att få en betydande roll för webbdelen i JDP vilket syns tydligt då Struts-klasser till och med måste modelleras in i modellen. Eftersom det inte går att modellera flöden med tillhörande in- och utgräns-snitt till sidor i UML2 måste flödet beskrivas på något annat sätt. Problemet har lösts genom att en Action-klass representerar en sida samt relationerna mellan klasserna får beskriva flödet mellan sidorna. Associationerna märks med stereotyper som i sin tur genererar Struts-specifik konfiguration. Däref-ter är det upp till utvecklaren att implemenDäref-tera Action-klasserna och där i vidarebefodra användaren till nästa sida.

Kapitel 3

Struts

Struts är ett ramverk för webbutveckling i Java skapat av Apache-stiftelsen som även har utvecklat webbservern med samma namn. Ramverket är öppet vilket innebär att källkoden finns att tillgå för allmänheten och vem som helst kan bidra med förbättringar till projektet. I detta kapitel kommer i huvudsak Struts version 1.2.9 studeras eftersom det är den versionen som WM-Data använder sig av idag, även om det har släppts och är på väg att släppas nya förbättrade versioner. Den nyaste versionen kommer diskuteras i slutet av detta kapitel.

Figur 3.1: Modulstrukturen enligt Cavaness (2004)

Ramverket beror till stor del på den redan existeran-de servletarkitekturen och används genom att endast plugga in biblioteket i en servletcontainer. Detta gör Struts väldigt anpassnings-bart och fungerar med den befintliga miljön och den plattform som, till exempel, ett företag redan använder. Detta till fördel att bland an-nat redan befintlig kodstruk-tur inte behöver röras och debuggning blir väldigt en-kel. Den största nackdelen

jämfört med ett större mer fristående verktyg eller plattform är flexibiliteten som det skulle kunna få. Nu ärver Struts de problem och begränsningar i plattformen som ramverket körs på.

3.1. MODEL-VIEW-CONTROLLER KAPITEL 3. STRUTS

och komponenterna beskrivs aldrig i någon övergripande form annat än den MVC-struktur skaparna vill lyfta fram. Cavaness (2004) har gjort ett försök att dela in ramverket i kategorier på en högre nivå och beräknat beroendet mellan dem. Han fick då fram diagrammet i figur 3.1. Där kan ses ett antal cirkulära beroenden som till exempel mellan config- och actionpaketen vilket enligt honom beror på den snabba utvecklingen som Struts går igenom och inte dåliga designbeslut från utvecklarna.

3.1

Model-View-Controller

Eftersom Struts strävar efter en tydlig MVC-design är det viktigt att få en stadig grund inom området för att förstå hur ramverket fungerar och är tänkt att användas.

Controller

View Model

Figur 3.2: Diagram över komponentberoendet i ett MVC-system Tidigare har Model-View-Controller (MVC) betraktats som ett design-mönster, det vill säga en vägledning i hur kod ska designas. Men med åren har det kommit att bli ett krav och näst intill en standard vid design av ett system. MVC gör det enkelt att separera själva funktionaliteten från den vi-suella representationen vilket gör att flera utvecklare kan jobba med systemet oberoende av varandra och kod kan enkelt återanvändas i nya projekt.

3.1.1

Modellen

Modellen är själva informationen som systemet har hand om. Den ska i så stor utsträckning som möjligt bestå av operationer och tillstånd som rör systemets kärna, till exempel databaser med databasförfrågningar. Modellen ska kunna betraktas som en bit av systemet som ska kunna byta miljö oberoende av hur den representeras.

KAPITEL 3. STRUTS 3.2. MODEL-VIEW-CONTROLLER I STRUTS

Här kan det skilja mellan olika typer av system vad som betraktas som modell. Om ett system har direkt kontakt med en databas i en tvålagerarki-tektur så är databasen modellen. Däremot om ett system i tre lager använder sig av till exempel ett bibliotek som i sin tur anropar en databas så ska bib-lioteket betraktas som modell.

3.1.2

Vyn

Modellen innehåller information som sedan representeras genom vyn. Inom webbutveckling består vyn ofta av HTML-, JSP- och PHP-sidor. Mest intres-sant i detta avseende är de dynamiskt genererade sidorna då HTML-sidor är statiska där innehållet inte kan presentera något från systemet.

Det som gör att man vill separera representationen från datan är att genom detta kan modellen representeras på olika sätt utan att den påverkas. Inom webbutveckling gör det att JSP- och PHP-sidor inte är de enda sätten att visa information ur systemet utan det kan lika gärna göras på andra sätt, till exempel kan rapporter på systemet genereras.

3.1.3

Kontrollern

Detta är den mest diffusa och svårgreppade delen i Model-View-Controllern. Kontrollern är till för medling mellan vyn och modellen och består generellt av den del i systemet som påverkas av interaktion från användaren. När en användare till exempel ändrar en siffra i en kalkyl meddelas kontrollerkom-ponenten om detta, talar om för modellen att den ska uppdateras och ber vyn att åter representera modellen så vyn kan visa modellen med dess nya tillstånd.

Inom webbutveckling i Java består kontrollern av en servlet. När använda-ren anger en adress i webbläsaanvända-ren tar servleten hand om frågan och systemet får en chans att uppdateras. Därefter kan en ny sida genereras som visar resultatet av operationen.

3.2

Model-View-Controller i Struts

Det Struts erbjuder i MVC-strukturen är framförallt sin egen kontroller. Det är den som är hjärtat i ramverket. I grunden består kontrollern av en servlet som sköter mappningen från URL, Uniform Resource Locator, till klassen som ansvarar för kontrollfunktionaliteten. För att underlätta utvecklingen finns ett antal hjälpklasser och konfigurationsmöjligheter till förfogande.

3.2. MODEL-VIEW-CONTROLLER I STRUTS KAPITEL 3. STRUTS

Resten av komponenterna är inte lika framstående i detta sammanhang då Struts inte ansvarar för modellen samt att vyn till stor del redan existerar i JSP. Trots det erbjuder Struts stöd och verktyg för att underlätta även dessa delar.

3.2.1

Modellen - Javabönor och businesslogik

Även om modellen inte är den komponent som först kommer på tal vid web-bapplikationer sker viktig kommunikation med modellen för att systemet ska vara fungerande. Struts specificerar i sig inte någon modell men innehåller funktionalitet för att påverka hur modellen kan styras.

Något som Apache trycker hårt på är att javabönorna som används i systemet ska vara så återanvändbara som möjligt. Tanken när dom skrivs ska vara att bönorna inte vet om att de utvecklas för webbapplikationer. De ska lika gärna kunna användas i vanliga applikationer som i webbaserade applikationer. I dokumentationen skriver man:

For maximum code re-use, business logic beans should be designed and im-plemented so that they do not know they are being executed in a web ap-plication environment. If you find yourself having to import a javax.servlet.* class in your bean, you are tying this business logic to the web application environment.(McClanahan, Schachter, Husted, Cooper & Steitz 2000-2005b, kap. 2.5)

För att bönor ska kunna refereras i vyn när den ska genereras måste bönorna konfigureras för ett scope. Bönorna lagras då i scopet tillsammans med ett namn för att identifiera bönan i JSP-sidan. De olika scope som finns att välja mellan är:

• page - Bönan är synlig endast i en sida med den nuvarande HTTP-frågan som livslängd.

• request - Livslängden på bönan är även här under frågan men här kan den refereras i godtycklig JSP-sida eller servlet. Detta gäller såväl i inkluderade sidor som vid ompekning av sidan.

• session - Bönan är synlig i alla JSP-sidor och servlets som deltar i en användarsession genom flera HTTP-frågor. Används till exempel för användare som är inloggade i en portal.

• application - Samma som ovan fast här hålls bönan vid liv så länge som webbapplikation är igång.

KAPITEL 3. STRUTS 3.2. MODEL-VIEW-CONTROLLER I STRUTS

3.2.2

Vyn - JSP och taglibs

I grunden använder sig Struts av de JSP- och taglib-teknologier som redan existerar men bygger ut dessa med ytterligare tillägg för integrering med in-ternationalisering (internationalization, eller i18n för de 18 bokstäver mellan i och n, på engelska), validering och navigering.

Att skapa hemsidor för fler än ett språk är väldigt svårt. Struts erbjuder en lösning på detta som går ut på att det i sidan står att det ska stå en text men det står inte hårdkodat vad det ska stå i texten. Det specificeras istället i en så kallad propertiesfil som namnges till exempel MyResources.properties för att ange standardspråket eller MyResources_xx.properties för en översättning till språket xx som är en ISO-standardkod. Filen består i sin tur av nyckel-värde-par där nyckeln är det som anges i sidan och värdet är texten som ska stå i sidan. Till exempel kan det stå i MyResources.properties en rad som säger title.welcome=Goddag och i MyResources_fr.properties står det istället title.welcome=Bonjour som sedan refereras i sidan med hjälp av JSP-taggar till exempel som <bean:message key="title.welcome"/>. Struts känner då av ifall det är en person som använder franska i sin webbläsare och i så fall skriver ut Bonjour, i annat fall skrivs Goddag ut.

En viktig del i ramverket är automatisk formulärsvalidering. För att an-vända detta överlagras och implementeras validate (ActionMapping, HttpServletRequest )-metoden i ActionForm-klassen. Denna metod anropas av kontrollerservle-ten efter det att de refererande bönornas tillstånd blivit satta men innan Action-klassens execute()-metod anropas. validate() returnerar null el-ler en tom instans av ett ActionErrors-objekt om valideringen gick bra. Om valideringen misslyckas så returneras ett ActionErrors-objekt som innehåller en eller flera ActionError-instanser och som i sin tur innehåller nycklar till meddelanden i propertiesfilen om vad som gick fel. Felen visas sedan för an-vändaren genom att klienten skickas åter till formuläret och felen visas på sidan.

Många sidor i en applikation kommer ha samma grunduteseende. Lämp-ligtvis skapas först en mall med grunden färdig så resten av sidorna kan ärva dess layout och sedan bygga ut den. Detta löses oftast genom att en huvudfil innehåller grunden för en sida och sedan inkluderas lämpligt innehåll i den vid behov. Inom JSP finns tre möjligheter.

• Ett <%@ include file=”xxxxx” %>-direktiv inkluderar filer som innehål-ler Java-kod elinnehål-ler JSP-taggar. Koden inkluderas ovillkorligen in i filen vilket gör att den inkluderade sidan kan referera variabler deklarerade i den yttre JSP-sidan.

3.2. MODEL-VIEW-CONTROLLER I STRUTS KAPITEL 3. STRUTS

/> och körs när sidan genereras. Detta innebär att sidor kan inkluderas inom JSP-taggar som till exempel ställer upp villkor innan sidan inklu-deras. Enligt (McClanahan, Schachter, Husted, Cooper & Steitz 2000-2005c) innebär denna typ av inkludering även andra effekter också men det står inte vilka: ”Among other things, that means you can conditio-nally perform the include by nesting it within a tag like equal by using it’s parameter attribute”(McClanahan et al. 2000-2005c)

• Det tredje alternativet är ett bean:include-direktiv som Struts tillhan-dahåller. Direktivet inkluderar sidor på samma sätt som jsp:include med skillnaden att resultatet skrivs till en variabel istället för till HTTP-svarets utström.

Struts tillhandahåller ett bibliotek som kallas tiles vilket ska underlätta utveckling enligt metoden att använda inkluderingsdirektiv. Istället för att inkludera filer i andra filer så byggs vyn upp genom att kombinera olika tiles. Grunden till sidan skrivs i en fil och i den anges positioner där sidan kan utökas med namngivna tiles:insert-taggar. Hur sedan layouterna sätt samman beskrivs i en fil som kallas tiles-def.xml där layouter även kan ärva varandra. Till exempel kan en sådan sida se ut som i listning 3.1.

Listning 3.1: Exempel på tiles-def.xml. Källa: Cavaness (2004). < t i l e s − d e f i n i t i o n s>

< d e f i n i t i o n name=" l a y o u t "

path=" / l a y o u t / l a y o u t . j s p ">

5 <put name=" body " v a l u e=" " /> </ d e f i n i t i o n> < d e f i n i t i o n name=" homepage " e x t e n d s=" l a y o u t "> <put name=" body " 10 v a l u e=" / i n d e x . j s p " /> </ d e f i n i t i o n> </ t i l e s − d e f i n i t i o n s>

I exemplet döps en layout till layout och utgör grunden för en sida och punkten body som är öppen för modifiering är tom. Sedan definieras en layout homepage som ärver layout och sätter body till innehållet i index.jsp. På detta sätt går det att skapa en stor hierarki av sidor som blir överskådlig och enkel att underhålla.

3.2.3

Kontrollern - Action-klasser och URL-mappning

Som tidigare nämnts så har kontrollerkomponenten till uppgift att behandla inkommande fråga från klienten, i de flesta fallen en webbläsare, och förmedla

KAPITEL 3. STRUTS 3.2. MODEL-VIEW-CONTROLLER I STRUTS

informationen till modellen samt meddela vyn om uppdateringen.

Enligt McClanahan, Schachter, Husted, Cooper & Steitz (2000-2005a) utgörs kontrollerkomponenten av ActionServlet-klassen då de säger att ”the ActionServlet represents the C - the controller”. Denna klass har som främsta uppgift att behandla den inkommande frågan från användaren, hämta infor-mation om modellen som ska ges till vyn och slutligen välja den vy som ska presenteras för användaren. Från och med Struts 1.1 har dock en ny klass in-troducerats som tar hand om det mesta av det initiala arbetet och som kallas för RequestProcessor. För varje fråga som kommer till ActionServlet anropas

process (HttpServletRequest , HttpServletResponse)-metoden som i sin tur lämnar över ansvaret för frågan till RequestProcessor-klassen. I denna klass görs bland annat validering av frågan och den mappas till rätt Action-klass. Det är sedan upp till utvecklaren att skapa en klass som utökar Action-klassen och implementera funktionalitet till dessexecute()-metod som ska ha signatur enligt listning 3.2.

Listning 3.2: Metoden execute som ska implementeras public A c t i o n F o r w a r d e x e c u t e ( ActionMapping mapping ,

ActionForm form ,

H t t p S e r v l e t R e q u e s t r e q u e s t , H t t p S e r v l e t R e s p o n s e r e s p o n s e )

5 throws E x c e p t i o n ;

Själva magin med att veta vilken Action-klass som ska användas sker genom en analys av HTTP-frågan som matchas mot mappning till klassen. Denna mappning sker, liksom annan strutskonfiguration, i struts-config.xml där ett action-element bland annat innehåller attribut för vilken URL som ska matchas mot en specifik Action-klass. Ett exempel på hur ett sådant element kan se ut syns i listning 3.3.

Listning 3.3: Exempel på ett action-element. Källa: Cavaness (2004). <a c t i o n path=" / l o g i n " t y p e="com . o r e i l l y . s t r u t s . b a n k i n g . a c t i o n . L o g i n A c t i o n " s c o p e=" r e q u e s t " 5 name=" l o g i n F o r m " v a l i d a t e=" t r u e " i n p u t=" / l o g i n . j s p "> <f o r w a r d name=" S u c c e s s " path=" / a c t i o n / g e t a c c o u n t i n f o r m a t i o n " r e d i r e c t=" t r u e " /> <f o r w a r d name=" F a i l u r e " path=" / l o g i n . j s p " r e d i r e c t=" t r u e " /> 10 </ a c t i o n>

3.3. ANDRA LÖSNINGAR KAPITEL 3. STRUTS

Här kan ses att om användaren väljer att peka sin webbläsare till en adress som innehåller /login så ska execute()-metoden i com. oreilly . struts .banking. action .LoginAction-klassen köras. Dessutom innehåller action-elementet även forward-element som används i Action-klassen för att bestämma vyn som ska presenteras efter att frågan har behandlats färdigt. Som syns in 3.2 så ska ett ActionForward-objekt returneras och med hjälp av forward-elementen kan ett sådant objekt enkelt skapas. När execute()-metoden ska avslutas så returneras helt enkelt mapping.findForward("Success") ifall inloggningen gick bra i exemplet ovan.

3.3

Andra lösningar

Givetvis existerar andra lösningar än Struts för webbutveckling med sina egna egenskaper och användningsområden. I detta avsnitt görs en jämförelse mellan ett urval av dessa och även senare versioner av Struts med avseende på arkitektur samt att ställa för- och nackdelar mot varandra.

Syftet med jämförelsen är att ge en överblick i hur andra liknande webb-ramverk löst de problem som Struts påstår sig löst men även hur de löst eventuella problem som finns i Struts.

3.3.1

Barracuda

Barracuda har precis som Struts utvecklats med stor vikt på en MVC-arkitektur men här har man tagit det ett steg längre genom att införa en mer objektorienterad lösning. Istället för att som i Struts låta konfigura-tionsfiler sköta behandlingen av en HTTP-fråga så sköts detta genom att registrera lyssnare enligt klassisk objektorienterad manér.

Flödet från att en fråga skickas från klienten och behandlas genom syste-met till att ett svar skickas tillbaka till klienten visas i figur 3.3. Här följer en förklaring på modulerna i flödet.

1. Client Capabilities. Flödet börjar med att identifiera vilka egenska-per, krav och önskemål klienten har. Det kan röra sig om till exempel webbläsartyp, språk och format på svaret.

2. Event Model. Här sker all vidarebefodring av frågan genom att om-vandla frågan till Java-objekt och genom händelser skicka objekten till lyssnare som är intresserade av frågan.

3. Form Mapping & Validation. Nu valideras de inkomna paramet-rarna från frågan vilket kan göras på ett flertal sätt men framförallt

KAPITEL 3. STRUTS 3.3. ANDRA LÖSNINGAR

genom att elementen i ett formulär registreras med namn och data-typ i en tabell. Det går också att lägga till ytterligare validering vid registrering av parametrarna, till exempel att parametern måste vara ifylld.

4. XMLC. Efter att något användbart har gjorts med datan från frågan så den inte längre representeras av ren text görs en uppdatering av modellen på serversidan genom till exempel databasuppdateringar och därefter ska en sida visas. Istället för att använda JSP som Struts an-vänder så anan-vänder Barracuda XMLC. XMLC omvandlar en HTML-fil till ett träd med HTML-taggarna som noder, det vill säga ett DOM-träd, och som genom Java-operationer på trädet byter ut angivna delar i texten mot ett nytt innehåll.

5. Localization. När det nya innehållet är genererat så har Barracuda ett steg för att omvandla texten till olika språk vid behov. Detta påmin-ner en aning om Struts metod om lokalisering men här utgör texten i sig punkten som ska översättas. Denna text mappas sedan mot en identifierare som i sin tur används för att lokalisera den text som ska översättas till.

6. Component Model. Eftersom DOM-strukturen är väldigt generell och operationerna väldigt primitiva tillhandahåller Barracuda klasser som binder noder i dokumentet till rena Java-objekt som kan utföra med avancerade operationer till specifika ändamål. Det kan till exem-pel röra sig om formulärknappar, listor, textfält och tabeller. Det går även att ärva basklassen BComponent för att skapa egna konkreta kom-ponentklasser.

Barracuda har ett intressant koncept och ramverket är välskrivet med hjälp av interface istället för konkreta klasser. Men vad skiljer detta ram-verk mot Struts och är skillnaderna till det bättre eller inte? På ramram-verkets hemsida har man sammanställt en ganska partisk men ändå välskriven sam-manställning av just skillnaderna mellan de två ramverken.

Den övergripande synen på webbutveckling är i stort sett den samma: det ska vara en tydlig skillnad mellan funktionalitet och representationen av densamma. Hur Barracuda och Struts åstadkommer detta skiljer sig ändå markant vilket syns på figurerna 3.3 och 3.4, även om dessa figurer ska tas med en nypa salt eftersom de är tagna från en sida som försöker förhålla sig som det bästa ramverket i de flesta avseenden. Till exempel går det att ifrågasätta om Action-klasserna ska höra till businesslogikdelen i figur 3.4

3.3. ANDRA LÖSNINGAR KAPITEL 3. STRUTS

när den allmänna synen på dessa klasser säger att den ska räknas till kon-trollerdelen. Dessutom ges en väldigt negativ bild av JSP med de främsta argumenten att ”by embedding custom tags we create something that is not valid HTML, XML, etc”(BarracudaMVC 2006, kap. 3.1) och ”Struts (and similar ”Pull-MVC” template approaches) achieve separation by expressing ”Controller” code in Java (usually Servlets), and ”View” code as *ML (usually in JSPs).”(BarracudaMVC 2006, kap. 3.1) Faktum är ändå att JSP använts inom många områden vilket gör att det finns mycket support samt att tek-niken existerar och har används under en lång tid vilket gör att Struts vydel inte behöver vara lika omfattande som Barracudas då det krävs att XMLC måste byggas in i ramverket.

För att XMLC ska kunna behandla sidorna krävs först att en kompilering av en sida till en javaklass görs för att sedan kunna behandlas i koden. Detta har som fördel att behandlingen på klassen, och därmed sidan, blir väldigt snabb och effektiv då sidan inte behöver kompileras för varje sidvisning. Nackdelen är att om en utvecklare förändrar källkoden för en sida måste den kompileras om vilket betyder att i princip ett nytt bygge måste göras även för mindre ändringar.

3.3.2

Java Server Faces

Ett ramverk som påminner mer om Struts än vad Barracuda gör är Java Server Faces, JSF, som är utvecklat av Sun och följer med Java EE SDK. Man strävar även här efter att skilja funktionalitet från representation och gör detta genom att använda JSP-sidor som är utökade med tagbibliotek. Till modellen används en av två typer av bönor som Sun har introducerat i JSF - en backing bean. Den andra typen av böna kallas managed bean och specificeras i JSF konfigurationsfilen, faces-config.xml, där det anges vilken klass som utgör bönan, namnet på bönan och vilket scope den ska ha. Kopp-lingen mellan en backing och en managed bean är att en backing bean är själva bönklassen medan managed bean binder backing bean till ett namn som kan refereras från JSP-sidan. En backing bean ersätter då i stort sett Action- och ActionForm-klasserna då de innehåller mycket funktionalitet, på gott och ont. Mycket från vyn får styra tillståndet i bönorna men de blir frikopplade från funktionalitet som är knutet till själva ramverket då JSF letar efter metoder i bönan som börjar på get och set.

En stor fördel JSF har jämfört med både Struts och Barracuda är suppor-ten som finns för ramverket. Ett stort företag står bakom det med välskriven dokumentation och dessutom mycket bra verktygsstöd. Bland annat har Sun sin egna utvecklingsmiljö Java Studio Creator med integrerat stöd för JSF. Dessutom finns en hel del resurser i form av exempel och sidor som inriktar

KAPITEL 3. STRUTS 3.3. ANDRA LÖSNINGAR

sig på utveckling med JSF.

I det stora hela erbjuder JSF mycket av det Struts också erbjuder fast i en annan förpackning. Till exempel erbjuds validering även i JSF fast den hakas på elementen i JSP-sidan till skillnad från Struts som gör det i Action-klasserna. Men den största skillnaden mellan ramverken är att JSF erbjuder ett standardiserat API för det grafiska gränssnittet och till det ett antal komponenter som är specifika för JSF, exempelvis en kalenderkontroll som inte finns i HTML. Navigationen i JSF blir väldigt överskådlig och flexibel då den antingen kan vara statisk eller bero på en händelse till exempel då en knapp trycks ned. I Struts bestäms navigationen i Action-klasserna även om endast en vidarebefodring ska göras.

3.3.3

Struts 2.0

Mycket har hänt sedan Struts 1.2.9 och den senaste versionen, 2.0-serien, skil-jer sig en hel del vad gäller hur ramverket ska användas. De byggstenar som kännetecknar Struts, till exempel validering och internationalisering, finns kvar och tyngden ligger fortfarande på en MVC-arkitektur. En av de stör-re skillnaderna är att Action- och ActionForm-klasserna har slopats. Istället har man integrerat ett bibliotek som kallas XWork från OpenSymphony som tillhandahåller bland annat ett valideringsverktyg. För att skapa vad som motsvarar en Action-klass behöver endast klassen com.opensymphony.xwork2. ActionSupport utökas samt en enkel execute()-metod implemeteras. Metoden har signatur enligt listning 3.4 att jämföra med 3.2 som är stor och komplex. Felen som kan uppstå vid validering i metoden registreras med hjälp av en

addActionError()-metod jämfört med att skapa ett ActionErrors-objekt som fylls med ActionError-instanser. En hel del av den manuella valideringen och konverteringen går dock att göra innan actionklassen får ta del av informa-tionen. Per automatik känner Struts av vilken datatyp ett fält i actionklassen har och meddelar användaren ifall ett ogiltigt värde har angivits i ett fält. Det går även att specificera mer begränsande parameterar på valideringen, till exempel ett område för ett heltal eller ett angivet datumformat, antingen i en XML-fil eller som annotationer som hakas på klasserna och dess metoder.

Listning 3.4: Signaturen för execute() i Struts 2.0 S t r i n g e x e c u t e ( ) throws E x c e p t i o n ;

Stödet för JSP har också utökats för att stödja den nya arkitekturen. För att exempelvis skapa ett formulär i HTML används Struts egna taggar

3.3. ANDRA LÖSNINGAR KAPITEL 3. STRUTS

som genererar input-taggar och samtidigt binder dess värde till egenskaper i Action-klassen. Som ett komplement till JSP används ett bibliotek som heter FreeMarker för att kunna skapa mallar och teman. FreeMarker erbjuder inte något utöver det JSP tillhandahåller bortsett från enklare syntax som är mer riktad mot rendering av sidor. Det finns till och med syntax för att komma åt JSP-taggar från FreeMarker. De stora fördelarna ligger i att biblioteket ger en mer bekvämare syntax för den som designar hemsidan. Dessutom är det inte bundet till just en servletarkitektur utan är ett fristående bibliotek som kan pluggas in i flera olika typer av applikationer som kräver mallar.

KAPITEL 3. STRUTS 3.3. ANDRA LÖSNINGAR

Figur 3.3: Översikt av Barracuda. Källa: http://www.barracudamvc.org/ Barracuda/docs/images/arch_overview.gif

Figur 3.4: Struts modularkitektur enligt BarracudaMVC (2006). Källa: http: //www.barracudamvc.org/Barracuda/docs/images/mvc2_struts.gif

Kapitel 4

JavaScript

Vid Internets begynnelse utfördes all kommunikation ovillkorligen, inklusive validering av formulär, med webbservern. Då den huvudsakliga uppkoppling-en hos användare uppkoppling-enligt Zakas (2005) var väldigt långsamma innebar det väl-digt långa responstider för en HTTP-fråga. Att då fylla i ett formulär, skicka det och få som svar att ett fält inte är ifyllt är både irriterande och utnyttjar resurser helt i onödan. Detta insåg Netscape vara ett problem och 1995 in-troducerades den första versionen av JavaScript (namnet JavaScript valdes helt enkelt för att stjäla lite av den uppmärksamhet som Java hade börjat få) utvecklat av Brendan Eich på Netscape Communications Corporation i Netscape Navigator 2.0. Nu kunde grundläggande validering, exempelvis om ett textfält är tomt, göras innan frågan skickades till servern.

Eftersom idén med JavaScript och validering på klientsidan kom att bli så pass populär släpptes året därpå version 1.1 av JavaScript i Netscape Navigator 3.0. Där hade språket utökats med ny funktionalitet, till exempel en typeof-operator för att bestämma typen på ett objekt och ett HTML-element med tillhörande FileUpload-objekt för att kunna ladda upp en fil till servern. Nu insåg även Microsoft fördelen med vad JavaScript kunde erbjuda och beslöt sig för att i Internet Explorer 3.0 implementera JScript (namnet JScript för att undvika licenstvister med Netscape) med sin egen implementation och tolkning av JavaScript.

Nu konkurrerade Netscape Navigator och Internet Explorer om ande-lar på Internet och även om JavaScript som språk. Detta skapade problem då det inte existerar någon standard för språket och de två konkurrenterna implementerade sin egen nisch av det. Av denna anledning skickades 1997 JavaScript 1.1 till European Computer Manufacturers Association (ECMA) för att ”standardize the syntax and semantics of a general purpose, cross-platform, vendor-neutral scripting language”(Zakas 2005, s. 2). När överlägg-ningen var färdig hade man en standard som definierar ett nytt skriptspråk:

4.1. ECMASCRIPT KAPITEL 4. JAVASCRIPT

ECMAScript.

Året efter skickades ECMAScript-standarden även till den internationel-la organisationen för standardisering och den internationelinternationel-la elektrotekniska kommisionen ISO/IEC för att bli internationellt standardiserat där stan-darden kom att kallas ISO/IEC 16262:1998. Sedan dess försöker webbläsare använda ECMAScript som bas för implementation av dess JavaScript-motor med varierande resultat (Zakas 2005, s. 2).

4.1

ECMAScript

Den standard som utgör grunden för JavaScript är som sagt ECMAScript el-ler ECMA-262 som den även kallas. Standarden innefattar framför allt språ-kets syntax inklusive operatorer, kommentarer, funktionsanrop och satser men även primitiva typer (som heltal och boolska typer) och mer komplexa objekt för till exempel datum och reguljära uttryck. I skrivandets stund är standardens tredje upplaga aktuell som släpptes 1999 och innehåller främst följande egenskaper i jämförelse med den tidigare upplagan:

• Kraftfulla reguljära uttryck.

• Undantagshantering (exception handling). • En strängare definition av fel.

• Nummerformatering.

Dessutom består den tredje upplagan av ”minor changes in anticipation of forthcoming internationalisation facilities and future language growth.”(ECMA International 1999, Brief History)

I översikten till standarden beskrivs ECMAScript som ”an object-oriented programming language for performing computations and manipulating com-putational objects within a host environment. ECMAScript as defined here is not intended to be computationally self-sufficient”(ECMA International 1999, s. 1). Språket är alltså framtaget speciellt för att vara beroende av ett befint-ligt system och inte ett eget programmeringsspråk. Vidare definierar man ett skriptspråk som ”a programming language that is used to manipula-te, customise, and automate the facilities of an existing system.”(ECMA International 1999, s. 1) Syftet med att utveckla ett skriptspråk och göra det beroende av ett befintligt system är således att det ska kunna manipule-ra sin omgivning under tiden som systemet är i drift.

ECMAScript är i första hand framtagen som webbskriptspråk för att kunna utföra operationer på exempelvis fönster, bilder, textrutor och länkar.

KAPITEL 4. JAVASCRIPT 4.1. ECMASCRIPT

Standarden begränsas dock inte av detta utan kan tillämpas på en godtycklig plattform.(ECMA International 1999, s. 2)

Språkets syntax är medvetet mycket likt språk som Java, C och Perl. Detta gör processen att sätta sig in i språket väldigt lätt för programmerare som redan har kommit i kontakt med dessa brett förekommande program-meringsspråk. Grundläggande koncept för språket är enligt Zakas (2005, s. 11-12) följande:

• Språket gör skillnad på små och stora bokstäver. Precis som i Java och C skiljer språket på stora och små bokstäver vare sig det är funktionsnamn, variabelnamn eller operatorer. Det betyder attFoooch

foo är olika identifierare.

• Variabler är löst typade. Däremot till skillnad mot Java och C har variabler inte någon specificerad typ. Variabler deklareras genom nyc-kelordet var. Exempelvis:

var t i t l e = ’ En t i t e l som ä r en s t r ä n g ’ ; var v i s i b l e = true ;

var wi dt h = 3 5 0 ;

• Ett semikolon i slutet av en sats är inte obligatoriskt. I Java och C krävs att varje sats avslutas med ett semikolon. ECMAScript tillåter dock att en sats inte avslutas med semikolon utan kan istället avlutas med en radbrytning. Ska två satser stå på samma rad krävs alltså ett semikolon mellan dem. Exempelvis:

var name = ’ k a l l e ’ ; var a g e = 55

var s h o e s i z e = 42

• Kommentarer skrivs på samma sätt som i Java och C++. Pre-cis som i C++ och Java existerar två typer av kommentarer: enrads-och flerradskommentarer. Det vill säga // används för att kommente-ra till kommente-radslut och /∗ utgör en kommentar fram till motsvarande ∗/. Exempelvis:

// Kommenterar en r a d /∗ Kommenterar

f l e r a r a d e r ∗/

• Klammerparenteser utgör ett block. Satser, som exempelvis loo-par eller villkorssatser, kräver ett block som ska exekveras om dess villkor uppfylls. Blocket kan antingen bestå av en ensam sats eller en sekvens av satser vilket, precis som i Java, C och C++, representeras med klammerparenteser. Exempelvis:

4.1. ECMASCRIPT KAPITEL 4. JAVASCRIPT

i f ( name == ’ K a l l e ’ ) { s h o e s i z e = 42

a l e r t ( ’ D i t t namn ä r K a l l e ’ ) ; }

Eftersom vissa ord måste användas för att indikera speciella satser el-ler uttryck har de reserverats som nyckelord i ECMAScript. Dessa får inte användas som namn på variabler vilket då skulle ge tvetydigheter i gramma-tiken för språket. Används de som variabler fås ett felmeddelande i stil med ”Identifier expected”. ECMAScript har reserverat följande nyckelord:

break else new var case finally return void catch for switch while continue function this with default if throw

delete in try do instanceof typeof

Förutom nyckelorden har ytterligare ord reserverats för framtida utveck-ling av ECMAScript. Dessa ord kan men bör inte användas då de kan komma att markeras som nyckelord i framtida versioner av standarden. Dessa ord är:

abstract enum int short boolean export interface static byte extends long super

char final native synchronized class float package throws const goto private transient debugger implements protected volatile double import public

4.1.1

Objektorientering i ECMAScript

Första delen av förklaringen i ECMAScript-standarden påstår att språket är objektorienterat vilket enligt Nationalencyklopedin definieras som följer:

objektorientering, objektorienterad programmering (OOP), metodik för datorprogrammering och systemutveckling, där ett program eller system be-traktas som en modell av en verklig eller imaginär fysisk värld av objekt. Programtekniskt behandlas objekt med samma uppsättning data (attribut ) och handlingsmönster (metoder ) som instanser av en gemensam klass. Klas-serna kan bilda en hierarki, där objekt ur en subklass ärver attribut och metoder från superklassen. En metod i en klass och dess subklasser kan ha

KAPITEL 4. JAVASCRIPT 4.1. ECMASCRIPT

samma namn och därvid användas i programsatser där man refererar till ett objekt ur någon av dessa klasser utan att man anger vilken (polymorfi ), vilket ger programmeringstekniska fördelar.

Till skillnad från traditionella objektorienterade programmeringsspråk, som bland andra Java och C++, är ECMAScript och JavaScript ett pro-totypbaserat programmeringsspråk. Vad detta innebär är att istället för att skilja mellan klasser och instanser, som är av en speciell klass, finns enbart instanser. Enligt definitionen krävs att metoder och attribut ska kunna kaps-las in i en gemensam kkaps-lass vilket ett ECMAScript kan göra även om det sker på instansnivå istället för på klassnivå. Man definierar ett objekt som ”a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method.”(ECMA International 1999, s. 4) Vidare i definitionen står att metoder i en klasshierarki ska kunna vara polymorfiska vilket stöds i ECMAScript då en funktion som existerar i en instans kan skrivas över i kopian.

Zakas (2005) ställer följande krav på att ett språk ska kunna klassas som objektorienterat, vilket också ECMAScript uppfyller enligt honom:

1. Inkapsling - Att kunna samla och kapsla in data tillsammans med metoder i ett objekt.

2. Aggregering - Att kunna förvara ett objekt innuti ett annat objekt. 3. Arv - Att kunna skapa klasser som beror på en eller flera andra klasser

med avseende på dess metoder och egenskaper.

4. Polymorfism - Att kunna referera till en funtion som kan uppföra sig på flera olika sätt.

För att i till exempel Java skapa en ny klass med ytterligare funktionalitet skapas en klass som får ärva en godtycklig basklass och därefter utöka den nya klassen med ytterligare funktionalitet. För att utöka objekt i ett proto-typbaserat språk används protoproto-typbaserat arv. Det går ut på att en befintlig instans klonas och kopian får utökas med ytterligare funktionalitet. Varje instans i ECMAScript har en prototype-egenskap där funktionalitet som ska delas mellan klonerna implementeras. Det vill säga att när ett objekt ärvs så kopieras innehållet i prototype-egenskapen till den nya instansen och kopian får utöka egenskapen med ytterligare funktionalitet åt nästa objekt som vill ärva instansen.

4.1. ECMASCRIPT KAPITEL 4. JAVASCRIPT

4.1.2

Objekt

Standarden specificerar tre olika typer av objekt: native-, built-in- samt host-objekt.

Figur 4.1: De typer av objekt som existerar i ECMAScript.

Figur 4.1 illustrerar hur de olika typerna av objekt hänger ihop vilket beskrivs i avsnitten nedan.

Native-objekt

Enligt definitionen är native-objekt ”any object supplied by an ECMAScript implementation independent of the host environment. — Some native objects are built-in; others may be constructed during the course of execution of an ECMAScript program.”(ECMA International 1999) Dessa objekt måste alltså ECMAScript-motorn tillhandahålla för att följa standarden och består av följande objekt:

Object Function Array String Boolean Number Date RegExp Error NativeError EvalError RangeError ReferenceError SyntaxError TypeError URIError

Built-in-objekt

Built-in-objekt definieras som följer enligt standarden:

A built-in object is any object supplied by an ECMAScript implementation, independent of the host environment, which is present at the start of the execution of an ECMAScript program. Standard built-in objects are defined in this specification, and an ECMAScript implementation may specify and define others. Every built-in object is a native object.(ECMA International 1999, s. 4)

Dessa objekt är speciella på så sätt att de redan är instansierade när skriptet börjar köras och kan inte instansieras på något annat sätt. Standar-den beskriver endast två sådana objekt: Global och Math. De är fortfarande native-objekt enligt definitionen vilket också illustreras i figur 4.1.