• No results found

3.3 Andra lösningar

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 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 internationella 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 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 klass 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 prototypbaserat 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.

KAPITEL 4. JAVASCRIPT 4.2. DOM

Global-objektet är ett speciellt objekt vars livstid är under skriptets exe- kveringstid. Det är detta objekt vars egenskaper används då inget annat ob- jekt är explicit angett. Detta innebär att när en funktion anropas utan något angivet objekt, exempelvis parseInt (), väljer ECMAScript-implementationen en eventuell funktion i Global-objektet.

På samma sätt behöver inte Math-objektet instansieras men måste till skillnad från Global-objektet explicit anges vid användning, till exempelMath .min(1,2).

Host-objekt

I standarden definieras ett host-objekt som ”any object supplied by the host environment to complete the execution environment of ECMAScript. Any object that is not native is a host object.”(ECMA International 1999, s. 4) Det är helt enkelt alla övriga objekt som inte passar in under definitionen av de två andra typerna av objekt. Inom JavaScript rör det sig framför allt om DOM- och BOM-objekten som beskrivs i avsnitten nedan.

4.2

DOM

Ursprungligen när XML hade tagit form krävdes ett sätt att enkelt kunna läsa och manipulera XML-dokumentet i applikationer - ett API. Det första bibliotek som utvecklades var SAX (Simple API for XML) till Java som tolkar dokumentet från början till slut och använder händelser när den stöter på ett specifikt XML-element. Det är då upp till programmet att avgöra vad som ska göras med elementet. Denna metod är både resurssnål och snabb men den stora nackdelen är att det inte går att navigera i dokumentets struktur, dokumentet tolkas ovillkorligen från början till slut.(Zakas 2005, s. 162)

DOM (Document Object Model) är ett API som bygger upp dokumentet i en trädstruktur genom att varje XML-tagg blir en nod. En tolk, till exempel SAX, tolkar dokumentet och bygger upp trädet varefter XML-dokumentet inte behövs och förkastas. Trots att denna metod att representera dokumentet både är långsam och resurskrävande så är det den metod som föredras i JavaScript tack vare sin användarvänlighet.

Hur DOM ska tillämpas på HTML är standardiserat av standardiserings- organet World Wide Web Consortium (W3C) och är så i tre olika nivåer - från nivå ett till tre. Första nivån består av två grundläggande byggstenar för DOM: Core och HTML. Core specificerar de grundläggande elementen i DOM, som till exempel Document-, Element- och Text-noder, samt koncep- tet med att manipulera documentet genom att exempelvis lägga till och ta

4.3. JAVASCRIPT I WEBBLÄSARE KAPITEL 4. JAVASCRIPT

bort noder. HTML-delen består av tillämpningar på Core-delen genom spe- cifika HTML-element däribland HTMLDocument, HTMLFormElement och HTMLHtmlElement. Den andra och tredje nivån är påbyggnader på den läg- re nivån. Nivå två innehåller bland annat namnrymder och händelser. Den tredje nivån består av bland annat XPath och validering.

4.3

JavaScript i webbläsare

Sedan JavaScript introducerades för nio år sedan har mycket hänt. Idag är det inte bara HTML-sidor som drar nytta av tekniken; även andra områden använder JavaScript för att dynamiskt manipulera information.

För att använda JavaScript i en HTML-sida används<script>-taggen som oftast återfinns i<head>-taggen. I taggen kan även anges ett src-attribut om skriptet ska inkluderas från en extern fil och anges då som en URL. Att attributet anges som en URL har Yahoo! dragit nytta av då de erbjuder sitt bibliotek Yahoo! UI Library (YUI) från sin hemsida och man som utvecklare inte behöver tanka hem och installera det lokalt på sin dator. Utöver src- attributet anges också vilket språk som taggen behandlar. Tidigare gjordes det genom ett language-attribut men numera ett type-attribut som oftast sätts till text/javascript men kan även sättas exempelvis till text/vbscript för att indikera Microsofts VBScript.

Listning 4.1: Exempel på inkludering kontra inbakad JavaScript-kod < s c r i p t t y p e=" t e x t / j a v a s c r i p t ">

v a r i = 0 ; </ s c r i p t>

< s c r i p t t y p e=" t e x t / j a v a s c r i p t " s r c=" m i t t s k r i p t . j s "></ s c r i p t>

Som sagt kan src-attributet användas för att inkludera ett skript till sidan istället för att det ska bakas in i sidan. Listning 4.1 visar ett exempel på detta där mittskript.js är en fil som innehåller JavaScript-kod. Att referera en extern JavaScript-fil menar Flanagan (2006) har följande fördelar:

• Det förenklar HTML-sidan genom att flytta ut stora delar kod från den. Detta separerar också funktionalitet och presentation.

• Om flera sidor delar funktionalitet kan detta centraliseras i en JavaScript- fil som sedan inkluderas i sidorna som kräver funktionaliteten vilket också underlättar underhåll av koden.

KAPITEL 4. JAVASCRIPT 4.4. SÄKERHET

• Eftersom webbläsare kan spara sidor i en cache gör det att JavaScript- kod som ligger i en separat fil inte behöver hämtas igen om den hämtats en gång. När flera sidor delar dessa filer blir tiden som det tar att hämta dem från cachen kortare än att på nytt hämta filerna från servern. • Då src-attributet anges som en URL kan en JavaScript-fil från en extern

webbservern enkelt inkluderas vilket minskar beroendet av den enskilda servern.

4.4

Säkerhet

Ett hett ämne vad gäller JavaScript är säkerhet. Skulle inte denna aspekt tas på allvar skulle användare vara ett hett mål för attacker.

En central policy som tillämpas är samma-ursprungs-policyn (the same origin policy) vilket går ut på att ett JavaScript-skript endast får arbeta mot objekt som tillhör samma ursprung. Exempelvis kan ett skript som exekveras på Googles webbsida inte manipulera en sida på Mozillas webbsida. Två skript anses tillhöra samma ursprung om följande villkor är uppfyllda:

• De två skripten använder samma protokoll, exempelvis http:// eller file://.

• De använder samma port, till exempel port 80. • De ligger under samma domännamn.

Om något av dessa villkor inte uppfylls har inte de två skripten tillåtelse att interagera. Om till exempel ett skript körs på www.google.com har det inte tillgång till en sida på code.google.com eftersom de anses ligga på olika domäner. Samma skript har inte tillgång till en sida som måste hämtas från www.google.com:8080 då de ligger på olika portar eller en sida som finns på https://www.google.com eftersom sidan måste hämtas genom ett annat protokoll.

Ett undantag på denna policy existerar dock. Eftersom www.google.com och code.google.com är samma domän (men olika subdomän) har utvecklare enats om att skipt som ligger på olika subdomän ska kunna ha tillgång till varandra. Genom att sätta document.domain till google.com kan detta upp- nås. Men egenskapen måste tilldelas en domän som redan existerar i URL- adressen, det vill sägadocument.domainfår inte tilldelas exempelvis yahoo.com om skriptet exekveras på google.com.

Ytterligare en säkerhetsåtgärd man vidtagit är hur fönster kan skapas. När ett fönster skapas måste det placeras inom skärmens ramar samt ha en

4.4. SÄKERHET KAPITEL 4. JAVASCRIPT

storlek åtminstone 100 pixlar bred och hög. Om något av dessa villkor inte

Related documents