Ajax-työkalupakit. Eero Anttila. Helsinki 23.5.2007. Pro gradu -tutkielma HELSINGIN YLIOPISTO. Tietojenkäsittelytieteen laitos

Ajax-työkalupakit Eero Anttila Helsinki 23.5.2007 Pro gradu -tutkielma HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET Tiedekunta/Osasto Fakultet/Sektion Laitos Institution Matemaattis-luonnontieteellinen tdk Tietojenkäsittelytieteen laitos Tekijä Författare Eero Anttila Työn nimi Arbetets titel Ajax-työkalupakit Oppiaine Läroämne Tietojenkäsittelytiede Työn laji Arbetets art Pro gradu -tutkielma Tiivistelmä Referat Aika Datum 23.5.2007 Sivumäärä Sidoantal 63 + 24 liitesivua Viime vuosina on ruvettu hyödyntämään JavaScriptiä entistä enemmän WWW-selaimissa sovellusten käytettävyyden parantamiseen. Valitettavasti selaimet käyttäytyvät eri tavoin ja sisältävä usein myös virheitä. Ongelman ratkaisemiseksi voidaan käyttää Ajax-työkalupakkia, joka abstrahoi selaimen tarjoaman rajapinnan samalla tavalla kuin C-kielessä kirjastot abstrahoivat käyttöjärjestelmän. Ajax-kirjasto tarjoaa käyttöliittymäkomponentteja, efektejä sekä työkalut tapahtumien käsittelyyn ja asynkronisten pyyntöjen lähettämiseen. Koska työkalupakkeja on yli 40, voi sopivan löytäminen omiin tarpeisiin olla vaikeaa. Tässä tutkielmassa vertailun kohteena oli kolme Ajax-työkalupakkia: Dojo Toolkit, Yahoo UI ja Google Web Toolkit. Jokaisella työkalupakilla tehtiin kolme eri harjoitusta: automaattinen hakukentän täydennys, päivämääränvalitsin ja automaattinen lomakkeen tarkistus. Harjoituksista kirjattiin koodirivien ja tiedostojen määrä, suorituskykytiedot sekä ajankäyttö eri asioihin. Tulosten perusteella tultiin siihen tulokseen, että Google Web Toolkit soveltuu parhaiten raskaiden Ajax-sovellusten toteuttamiseen, Yahoo UI keveiden ja Dojo Toolkit näiden kahden välimaastoon. ACM Computing Classification System (CCS): C.2.6 [Internetworking] D.2.8 [Metrics] D.3.2 [Language Classifications] H.5.2 [User Interfaces] Avainsanat Nyckelord Ajax, JavaScript, Dynamic Web Säilytyspaikka Förvaringställe Kumpulan tiedekirjasto, sarjanumero C- Muita tietoja

i Sisällys 1 Johdanto...1 2 Ajax ja dynaamisten web-sivujen toteutus...5 2.1 Staattiset web-sivut ja tyyliohjeet...5 2.2 Dynaamisten web-sivujen toteutustekniikoita...7 2.3 Asynkroniset palvelupyynnöt...9 2.4 Ajax-tekniikka...11 2.5 Ajaxille vaihtoehtoiset tekniikat...14 3 Ajax-työkalupakit...16 3.1 Ajax-arkkitehtuurien yleiskuvaus...18 3.2 Nimiavaruudet ja pakkaukset...21 3.3 Dokumentointi...22 3.4 Kehitysympäristö...23 3.5 Käyttöliittymäkomponentit...24 3.6 Tapahtumien hallinta...28 3.7 Ajax I/O...29 3.8 Vertailun ulkopuolelle jääneet työkalupakit...32 4 Arviointi ja vertailumenetelmät...33 4.1 Ohjelmistoprosessin vaiheet ja niihin liittyvät mitat...33 4.2 Harjoitukset...35 4.3 Tuotetun koodin mittaus...36 4.4 Tuotettujen sovellusten vertailu käyttäjän näkökulmasta...37 5 Vertailun tulokset...39 5.1 Sovellusrungon kuvaus...39 5.2 Käyttöliittymäkomponenttien toimivuus...41 5.3 Sovellusten vertailu...44 5.4 Prosessien vertailu...46

ii 5.5 Johtopäätökset työkalupakkien soveltuvuuskohteista...50 6 Yhteenveto...54 Lähteet...57 Liitteet 1 Muistiinpanot Dojo Toolkitin harjoituksista 2 Muistiinpanot Yahoo UI:n harjoituksista 3 Muistiinpanot Google Web Toolkitin harjoituksista 4 Palvelinpään koodi automaattiselle lomakkeen tarkistukselle 5 Dojo Toolkit -harjoituksen koodi 6 Yahoo UI -harjoituksen koodi 7 Google Web Toolkit -harjoituksen koodi

1 1 Johdanto Vuonna 1989 Tim Berners-Lee esitteli HTML (Hypertext Markup Language) -kielen Internetin julkaisukieleksi. Kieltä käytettiin fysiikan tieteellisten kirjoitusten esittämiseen CERN:ssä (Organisation Européen pour la Recherche Nucléaire). Kieli tarjosi tekstin peruselementit, kuten otsikot ja kappaleet, sekä mahdollisuuden viitata käytettyyn lähteeseen hyperlinkillä [RLA98]. Mahdollisuus tehdä linkkejä toisella palvelimella sijaitsevaan dokumenttiin oli vallankumouksellista. Tästä alkoi HTML:n kehitys. Tähän päivään asti Internetin käyttäjien määrä on kasvanut räjähdysmäisesti. Sekä selainten että standardien kehitys on ollut jatkuvaa. Alun perin HTML-kielellä esitettiin lähinnä artikkeleita ja muita tekstejä, joita päivitettiin käsin. Kielen lähtökohtana oli, että dokumentti sisältää ainoastaan loogisen rakenteen, kuten otsikot, kappaleet ja listat. Näin kukin selain esittää sisällön omalla tyylillään tai käyttäjä voi määritellä itselleen mieluisan tyylin. Dokumenteissa saattoi esiintyä kuvia, jotka liittyivät lähinnä tekstiin, mutta niitä ei käytetty ulkoasuun. Ajan myötä myös yritykset innostuivat tekemään sivuja Internetiin. Pian koettiin tarvetta määritellä ulkoasu siten, että sivu näyttäisi samalta kaikille käyttäjille. Sivulla haluttiin esimerkiksi käyttää yrityksen omia värejä selaimen oletusvärien sijaan. Tämä johti HTML:n laajentumiseen. Kieleen tuotiin mukaan muotoilua kuvaavia elementtejä, kuten fontin ominaisuudet, värit ja tasaus. Tämä tosin rikkoi alkuperäisen HTML:n ideologian toimia ainoastaan sisällön kuvaajana. Tämän seurauksena otettiin myöhemmin käyttöön tyyliohjeet, joilla sisältö ja muotoilu saatiin pidettyä toisistaan erillään. Pian myöskään staattiset, käsin päivitettävät sivut eivät enää riittäneet. Yritykset halusivat esimerkiksi julkaista verkossa päivittäisiä uutisia. Tätä varten tarvittiin kieli palvelinpäähän [Atk99, FKB01]. Sen avulla sivun latauksen yhteydessä voitiin sisältö generoida automaattisesti esimerkiksi tietokannan sisällöstä [Fra99]. Sivuille tuotiin myös lisää vuorovaikutteisuutta tarjoamalla lomakkeita. Niillä käyttäjä pystyi esimerkiksi hakemaan tietoa avainsanoilla ja syöttämään yritykselle henkilötietoja. Alkuaikoina sivut olivat lähinnä kirjan tyyppisiä: sivuilla tarjottiin sisällysluettelo, josta päästiin lukuihin ja selain tarjosi mahdollisuuden palata navigointihistoriassa taaksepäin ja tallentaa kirjanmerkkejä. Nykyään monet sivut muistuttavat enemmän sovelluksia kuin dokumentteja: on karttasovelluksia, lipunvarausjärjestelmiä, arkistointisovelluksia ja keskustelusivuja. Paluunappi ja kirjanmerkki ovat tällaisille sovelluksille vieraita käsitteitä, jotka selain kuitenkin edelleen tarjoaa. Tämä

2 aiheuttaakin paljon ongelmia nykyaikaisissa verkkosovelluksissa. HTML-kieltä ei alun perin ollut tarkoitettu siihen mihin sitä nykyään käytetään. Tätä ongelmaa on pyritty helpottamaan erilaisilla palvelinpään sovelluskehyksillä, jotka tarjoavat helpomman tavan tehdä dynaamisia WWW-sovelluksia. Myöhemmin mukaan tulivat selainpään kielet, kuten Java-sovelmat sekä Flash- ja ActiveX-sivut [All02, Rob07]. Näillä saatiin sivuille lisää dynaamisuutta ja näyttävyyttä animaatioilla ja erilaisilla käyttöliittymäkomponenteilla. Näin sivuista saatiin työpöytäsovellusten kaltaisia. Sivuilla on kuitenkin tyypillisesti ollut ongelmina työpöytäsovelluksiin verrattuna hitaus ja rajoitettu käytettävyys. Nyt sovelluskehittäjät ovat luopuneet näistä kielistä ja palanneet tekemään WWWsovelluksia jo 1990-luvulla kehitetyllä JavaScript-kielellä [ECM99], koska sillä tehdyt sivut ovat paljon kevyempiä. JavaScript tarjoaa mahdollisuuden muokata WWW-sivun sisältöä dynaamisesti lataamatta sivua uudestaan palvelimelta. (Tosin) alkuvaiheessa kieltä käytettiin tosin lähinnä lomakkeiden kenttien kohdistamiseen, ponnahdusikkunoiden avaamiseen ja huomautusruutujen näyttämiseen, vaikka se on todellisuudessa kunnollinen ohjelmointikieli. Periaatteena on ollut pitkään, että sivun pitää toimia myös ilman JavaScriptiä, koska kaikki selaimet eivät välttämättä tue sitä tai se on kytketty selaimesta pois päältä tietoturvasyistä. Nykyään selainten tietoturva on parantunut, samoin kuin niiden yhteensopivuus, ja lähes kaikki selaimet tukevat JavaScriptiä. Vasta viime aikoina on kiinnostuttu dynaamisten sivujen tarjoamista eduista, vaikka JavaScript on ollut käytössä jo yli kymmenen vuotta. Tästä hyvänä esimerkkinä ovat Googlen tuotteet, joista tunnetuimmat lienevät Gmail [Gma06] ja Google Maps [Goo06]. Gmail-postiohjelmassa esimerkiksi vastaanottajan osoitekenttään kirjoitettaessa näytetään ne syötetyllä merkkijonolla alkavat yhteystiedot, jotka löytyvät osoitekirjasta. Näistä voidaan valita haluttu hiirellä tai näppäimistöllä. Tämä toiminto on toteutettu hakemalla osoitekirjan tiedot valmiiksi piiloon selaimelle. Näin käyttöliittymää pystytään päivittämään käymättä turhaan palvelimella. Google Maps -karttaohjelmassa taas karttaa on mahdollista siirtää hiirellä, jolloin puuttuvat karttapalaset noudetaan palvelimelta sitä mukaa, kun niitä tarvitaan. Koko sivua ei siis koskaan tarvitse ladata uudestaan. Edellä mainitut esimerkit mahdollistaa niin sanottu Ajax (Asynchronous JavaScript and XML) -tekniikka [Gar05]. Tekniikka tarjoaa mahdollisuuden tehdä palvelinkutsuja JavaScript-koodista käsin, jolloin selaimen näkymää pystytään päivittämään palvelimelta lataamatta uudestaan koko sivua. Tekniikalla voidaan myös toteuttaa

3 monipuolisia käyttöliittymäkomponentteja, animaatioita ja vaikkapa raahaustoiminto (drag and drop). Lyhyessä ajassa on markkinoille kehitetty useita erilaisia Ajax-työkalupakkeja (Ajax Toolkit). Niiden tarkoituksena on tarjota ohjelman kirjoittajalle mahdollisuus toteuttaa dynaamisia sivuja korkealla, selainriippumattomalla tasolla. Työkalupakkeja on jo yli 40 [Aja06]. Osa niistä on JavaScript-kirjastoja, osa sovelluskehyksiä Javalle tai muille kielille ja osa kokonaan omia kieliä. Monet yritykset ovat kiinnostuneet Ajaxia hyödyntävistä sovelluksista sen takia, että ne eivät vaadi asennusta asiakkaan koneille, koska ne toimivat selaimessa, joka löytyy jokaisen koneelta. Päivityksiä tarvitsee tehdä vain palvelimelle, jolla sovellusta ajetaan, ja ohjelmaa voidaan käyttää miltä koneelta hyvänsä. Google on esimerkiksi julkaissut selaimessa toimivan toimistosovelluspaketin, joka sisältää taulukkolaskennan, kirjoitusohjelman, sähköpostin ja kalenterin. Jopa dokumentitkin tallentuvat verkkoon, mikä vähentää entisestään CD-levyjen ja muistikorttien käyttöä. Yleisesti Ajaxia hyödyntävien projektien haasteena on kuitenkin uuden tekniikan ja kielen omaksuminen sekä sopivan Ajax-työkalupakin löytäminen suuresta valikoimasta. Lisäksi Ajax-työkalupakeista ei toistaiseksi ole vielä tehty tutkimuksia. Tämän pro gradu -tutkielman tavoitteena on vertailla eri Ajax-työkalupakkeja ja arvioida niiden soveltuvuutta ohjelmistoyritys Solitalle (www.solita.fi). Sovelluskehyksistä keskitytään Yahoo UI (YUI) [Yah06], Dojo Toolkit [Doj06] sekä Google Web Toolkit (GWT) [GWT06] -työkalupakkien esittelyyn ja vertailuun. Nämä ovat valittu niiden suosion ja ominaisuuksien perusteella sekä siksi, että ne soveltuvat myös yhteen Spring-sovelluskehyksen kanssa [ArA05], joka on laajasti käytössä Solitassa. Esimerkkisovelluksen käyttö on vertailussa välttämätöntä, sillä työkalupakki ei yksin tee mitään, vaan se tarvitsee ympärilleen jonkin toteutuksen. Vertailun pohjana käytetään jo toteutettua Työntekijä-Osasto-sovellusta. Tätä sovellusta on tarkoitus laajentaa tarpeellisilla Ajax-ominaisuuksilla kullakin työkalupakilla. Ominaisuudet tulevat olemaan dynaaminen lomakevalidointi, hakufiltteri sekä päivämääränvalitsin. Tavoitteena on myös antaa yritykselle tietoa siitä, millä työkalupakilla kannattaa tulevaisuutta ajatellen tehdä web-sovelluksia ja mihin käyttökohteisiin eri työkalupakit soveltuvat parhaiten. Tyypiltään tämä pro gradu -tutkielma on puoliksi kirjallisuuskatsaus ja puoliksi ohjelmointia sekä mittausta. Luvussa 2 käsitellään staattisten ja dynaamisten WWW-sivujen perusasioita, jotka muodostavat pohjan sen jälkeen käsiteltävälle Ajax-tekniikalle. Tämän jälkeen esitellään vielä Ajaxille vaihtoehtoiset tekniikat. Luvussa 3 esitellään tutkielmassa

4 vertailtavat työkalupakit ja niiden arkkitehtuurit. Luvussa 4 tutustutaan prosessille ja lopputulokselle käytettäviin arviointimenetelmiin. Luvussa 5 vertaillaan työkalupakeilla tehtyjä esimerkkisovelluksia sekä itse ohjelmointiprosessia. Luvun lopussa kerrotaan vertailujen johtopäätökset. Luku 6 on yhteenveto. Esimerkkisovellusten muistiinpanot sekä koodit ovat liitteenä (Liitteet 1-7).

5 2 Ajax ja dynaamisten web-sivujen toteutus WWW-sivut ovat melko tuore asia, ja standardien ja selainten kehitys on ollut huimaa. WWW-sivujen alkuperäinen idea oli esittää tietoa Internetissä hypertekstimuodossa eli dokumentissa oli linkkejä toisiin dokumentteihin. Tämän lisäksi sivuille sai tehtyä myös perusmuotoilut, kuten otsikoinnin ja kappalejaon. Ensimmäinen graafinen WWW-selain, Mosaic [NCS93] julkaistiin vuonna 1993. Tästä alkoi kiivas selainvalmistajien välinen markkinakilpailu. Tuohon aikaan sivujen tarkoituksena oli lähinnä esittää staattista sisältöä. Mosaicin julkaisua seuraavana vuotta julkaistiin ensimmäinen Netscape Navigator [PfB95], josta tuli markkinoiden suosituin selain ja joka säilytti asemansa pitkään. Edelleen vuotta myöhemmin markkinoille tuli ensimmäinen Internet Explorer (IE) [RoS99]. Tuohon aikaan selaimissa ei vielä ollut tukea tyyliohjeille eikä JavaScriptille [ECM99]. Niistä ajoista kehitystä on kuitenkin tapahtunut paljon. Standardeja ja suosituksia on ohjannut ja kehittänyt W3C (World Wide Web Consortium) [W3C06]. Selainvalmistajat ovat kehittäneet selaimia näiden standardien ja suositusten perusteella, tosin vaihtelevalla menestyksellä. Esimerkiksi tälläkään hetkellä markkinoiden yleisin selain, Internet Explorer 6 ei tue virheettömästi W3C:n määrittelemiä standardeja. Tästä on seurannut se, että kehittäjät ovat joutuneet tekemään epästandardeja sivuja, jotta ne toimisivat tällä selaimella. W3C-standardien laiminlyöminen taas on johtanut siihen, että sivut näkyvät väärin muilla standardeja tukevilla selaimilla, kuten Mozillalla [Wei06]. Nykyään kolme suosituinta selainta ovat Internet Explorer, Firefox ja Opera. Firefoxin ydin pohjautuu Mozillaan, joka taas pohjautuu Netscapeen. Tässä luvussa esitellään tärkeimmät Ajaxin taustalla vaikuttavat WWW-standardit (HTML, CSS, XMLHttpRequest, JavaScript) sekä Ajaxille vaihtoehtoiset tekniikat (Java applet, Flash). 2.1 Staattiset web-sivut ja tyyliohjeet HTML (Hypertext Markup Language) kehitettiin 1990-luvun alussa Internetin julkaisukieleksi [BeC93]. Alun perin HTML tuki ainoastaan hyperlinkkejä ja yksinkertaista muotoilua. Vasta myöhemmin kieleen tuli tuki taulukoille, lomakkeille ja kuville, joilla sisällöstä saatiin monipuolisempaa. Vielä myöhemmin tuli tuki tyyliohjeille, sivujen dynaamisuudelle ja erilaisille liitännäisille (plug-in), joista enemmän seuraavassa luvussa.

6 Ensimmäinen kunnollinen Internetiin tarkoitettu hypertekstikieli HTML 2.0 [BLC95] julkaistiin 90-luvun puolivälissä, mutta vasta vuonna 2000 siitä tuli kansainvälinen standardi. Viimeisin versio HTML 4.01 [HTM99] julkaistiin vuoden 1999 lopulla. Ensimmäinen XML-pohjainen (Extensible Markup Language) merkkauskieli XHTML 1.0 [Pem00] julkaistiin vuonna 2000. Tähän saakka WWW-sivuja on kehitetty jommalla kummalla edellä mainituista kielistä, mutta XHTML on syrjäyttämässä HTML:n. XHTML on XML-muodossa, joka on kurinalaisempi kuin tavallinen HTML. XML on hyvin määritelty eli se ei salli lomittaisia elementtejä, auki jääviä elementtejä, eikä attribuuttien arvoja ilman lainausmerkkejä. Lisäksi se tulkitsee suuret ja pienet kirjaimet erikseen ja vaatii dokumenttityypin määrittelyn (Document Type Definition, DTD). XML:n etuna on syntaksin helpompi tarkistus ja kielen monipuolinen käyttömahdollisuus esimerkiksi mobiililaitteissa. Alun perin HTML oli tarkoitettu vain sisällön esitystä varten, mutta käyttäjien tarve tehdä muotoiltuja sivuja laajensi kieltä. Sivuista tuli tämän johdosta raskaita ladata ja ylläpitää [RLA98]. Tämän ongelman ratkaisemiseksi kehitettiin tyyliohje (Cascading Style Sheet, CSS), jonka tarkoituksena on erottaa sisältö muotoilusta. Sen ensimmäinen versio (CSS level 1) [CSS96] julkaistiin vuonna 1996, ja se on tällä hetkellä yleisimmin käytössä. Siitä paranneltu CSS2 julkaistiin joulukuussa 1997, mutta esimerkiksi Internet Explorer 6 ei tue sitä. Viimeisimmän tyyliohjeen version, CSS3:n [ErB01] kehitys aloitettiin vuonna 1998, ja se on yhä kehitteillä. Käytettäessä tyyliohjeita tyylimääritykset on mahdollista antaa erillisessä tiedostossa, liittää dokumentin alkuun tai tuoda elementtien sisälle style-attribuutilla (ks. Listaus 2.1). Näistä ensimmäinen vaihtoehto on paras, koska silloin koko sivuston tyyli on helppo yhtenäistää yhdessä paikassa. Erillisten tyyliohjeiden etuna ovat myös omat tyylit näyttö- ja tulostusesitykselle. Keskimmäinen ja viimeinen vaihtoehto soveltuvat käytettäväksi silloin, kun muotoilumääritys on erikoistapaus. HTML-koodi pysyy selkeänä ja luettavana pitämällä tyylimuotoilut erillään sisällöstä, jolloin muotoilua kontrolloidaan vain yhdestä paikasta. Tämä parantaa myös esteettömyyttä (accessibility) näkö- ja kuulorajoitteisille sekä mobiililaitteiden käyttäjille. Listauksessa 2.2 on annettu esimerkki hyvästä ja huonosta tavasta tehdä HTMLkoodia. Esimerkissä tulostetaan otsikko suurella punaisella ja kappale pienellä, jossa on lisäksi korostettu sana. Vasemmanpuoleisessa listauksessa on käytetty <center>-, <font>- ja <b>-elementtejä, jotka eivät sinänsä kerro mitään tekstin loogisesta sisällöstä. Tyyli ja sisältö ovat sekoitettu samaan rakenteeseen, eikä merkkaus ole kuvailevaa. Tällainen HTML-koodin tyyli on jäänne ajoilta ennen tyyliohjeita. Oikeanpuoleisessa, hyvän tavan mukaisessa listauksessa, muotoilu on pidetty erillään

7 sisällöstä ja merkkaus on kuvailevaa: otsikko on aina <h[1-5]>, eikä esimerkiksi <span class="h1">. Listatyyppinen data on aina <ul> tai <ol>, ja <table> on tarkoitettu ainoastaan taulukkosisältöiselle datalle. Korostusta varten on parempi käyttää elementtiä <strong>, joka kuvaa korostusta, kuin elementtiä <b>, joka ilmaisee pelkästään lihavointia. Kun sivu toteutetaan oikealla tavalla, sen ulkoasun päivittäminen on paljon helpompaa, sillä sisältöön ei tarvitse puuttua. Samoin sisällön tekeminen on helpompaa, koska koodi on luettavampaa ja lyhyempää, eikä muotoiluun tarvitse ottaa kantaa. <html><head> <link rel="stylesheet" type="text/css" href="tyyli.css" /> </head><body> <h1>otsikko</h1> </body></html> <html><head> <style> h1 { color:red; </style> </head><body> <h1>otsikko</h1> </body></html> <html><head></head> <body> <h1 style="color:red">otsikko</h1> </body></html> Listaus 2.1: Tyylimäärittely erillisellä tiedostolla, style-elementillä ja style-attribuutilla Vaikka ensimmäisen tyyliohjestandardin julkaisemisesta on kulunut jo kymmenen vuotta, sen käyttö on usein vielä hyvin vajavaista. Internetissä näkee vielä paljon sivustoja, joissa muotoilu on tehty HTML-elementtien sekaan, kuten Googlen etusivulla (http://www.google.fi). Toisaalta myös oikein tehtyjä sivustoja löytyy, kuten Wikipedia (http://fi.wikipedia.org). Huono tapa <center> <font size="+2" color="red">otsikko</font> </center> <font size="-1"> Tämä on <b><font size="0"> kappale</font></b> </font> Listaus 2.2: Kaksi tapaa tehdä tyylimuotoilu Hyvä tapa h1 { font-size:large; text-align:center; color:red; p { font-size:small; strong { font-size:normal; <h1>otsikko</h1> <p>tämä on <strong>kappale</strong></p> 2.2 Dynaamisten web-sivujen toteutustekniikoita Dynaamisia ja vuorovaikutteisia sivuja varten tarvittiin tekniikka selain- ja palvelinpään väliseen kommunikointiin. Ensimmäisenä markkinoille tuli Common Gateway Interface (CGI) [McC93, Gun96] vuonna 1993. Sen avulla selain voi välittää

8 dataa palvelimella suoritettavalle ohjelmalle, joka suorituksen jälkeen palauttaa sivun. CGI-ohjelmien tekoon suosituin kieli on edelleen Hypertext Preprocessor (PHP) [Atk99]. Vasta paljon myöhemmin markkinoille tuli JavaServer Pages (JSP) [FKB01] -sivut, jotka ovat nykyään hyvin suosittuja. Tällä tekniikalla tuotetuilla sivustoilla muutokset sivuilla kuitenkin edellyttävät joka kerta uuden sivun lataamista palvelimelta. Sivun dynaamisuus voidaan myös toteuttaa selaimessa, jolloin sivun näkymää voidaan muuttaa lataamatta palvelimelta uutta sivua. JavaScript toi tähän mahdollisuuden. Yleensä melkein kaikki WWW-sivujen kehittäjät osaavat tehdä JavaScriptillä lomakekentän kohdistuksen tai ponnahdusikkunan avaamiseen, mutta eivät tiedä, että JavaScript on kuitenkin kunnollinen funktionaalinen oliomainen kieli, jolla on jopa toteutettu selaimessa toimiva käyttöjärjestelmä [Adl05, MWH06]. JavaScriptin syntaksi muistuttaa C-kieltä. Kielessä ei ole tyyppejä, vaan kaikki muuttujat säilytetään hajautustauluissa. Kieli tukee perintää prototyyppiolion kautta. Javan kaltaisesti kaikkien prototyyppien yliluokkana on Object-prototyyppi. Koodia on helppo muokata ajon aikana, koska ohjelmaa tulkitaan suoraan lähdekoodista. Toisaalta ennen suoritusta ei ohjelmallisesti voida tarkistaa muita kuin syntaksivirheitä. JavaScriptillä ei ole juurikaan yhteyttä Javaan, vaan sen nimi valittiin lähinnä markkinointisyistä. Viimeisin kielen määrittely (versio 1.5) on vuodelta 1999 (ECMA-262 Edition 3). Ladatessaan sivun selain luo HTML-lähdekoodista Document Object Model -olion (DOM) [ABC98]. Tämä on sivua kuvaava malli, jota JavaScript osaa tulkita ja muuttaa. Malli sisältää HTML-elementtejä vastaavia objekteja ja niiden kenttiä ja funktioita. Esimerkiksi listauksessa 2.3 sivun hakukenttään päästään käsiksi polulla document.forms.haku.sana. Tässä document on DOM-puun juurielementti, forms on taulukko, joka sisältää sivun kaikki lomakkeet, haku viittaa lomakkeen nimeen ja sana viittaa kyseisen lomakkeen tiettyyn kenttään. DOM tarjoaa JavaScriptille mahdollisuuden muokata dynaamisesti sivun sisältöä. Tyyliohjeisiin pääsee JavaScriptillä suoraan käsiksi, mutta kätevämpää on muokata elementille annettuja tyyliattribuutteja mydiv.style.background="gray" tai tyyliluokkia mydiv.classname="codeblock". JavaScriptiä käytetään siis sivun sisällön ja muotoilun dynaamiseen muokkaamiseen. JavaScriptiä voi joko liittää HTML-merkkauksen sekaan, dokumentin alkuun <script>-elementin sisään tai erilliseen tiedostoon, johon viitataan HTML-sivulta. Listauksessa 2.3 on esitetty kaksi tapaa liittää sivulle JavaScript-koodia. Molemmissa on täsmälleen sama toiminnallisuus. Selaimen ladattua sivun JavaScript-koodi

9 kohdistaa hakukentän ja asettaa kuvalle napsaus-kuuntelijan, joka lähettää lomakkeen. Hyvän tavan mukaista on ohjelmoida JavaScript-koodi erilleen HTML-koodista, kuten oikealla puolella listausta nähdään. Koodi on luettavampaa ja JavaScriptiä ei turhaan tarvitse ladata, vaan se voidaan hakea välimuistista. Voi myös olla mahdollista, että selain ei tue JavaScriptiä tai se on kytketty pois päältä. Sivustolle olisikin hyvä tarjota toiminnallisuus myös ilman JavaScriptiä, mikäli käyttäjinä on sellaisia, joilla se ei toimi. Tällaisesta piirteestä käytetään termiä esteettömyys (accessibility). Esteettömiä sivuja tarvitsevat esimerkiksi sokeat, heikkonäköiset ja hakukoneet. Sisällön on oltava semanttisesti korrektia, ja sen on toimittava ilman JavaScriptiä, tyylejä ja kuvia. Näyttäviäkin sivustoja on mahdollista toteuttaa näin [GiS05, StD04]. Tuki selaimille ilman JavaScriptiä voidaan tarjota laittamalla vaihtoehtoinen sisältö <noscript>-elementin sisälle. Toinen vaihtoehto on antaa käyttäjän valita, ladataanko sivusta JavaScript-versio vai tavallinen. Näin on tehty esimerkiksi Gmailissa [Gma06]. Valitettavasti suurimmassa osasta verkkosivuja näitä seikkoja ei ole otettu huomioon [IvM05]. Huono tapa <body onload="document.forms.haku.sana.focus()"> <form name="haku" action="hae.jsp"> <input type="text" name="sana"/> <img id="nappi" src="hae.gif" onclick="document.forms.haku.submit()"/> </form> </body> Listaus 2.3: Kaksi tapaa tuoda sivulle dynaamisuutta Hyvä tapa window.onload = function() { document.forms.haku.sana.focus(); document.getelementbyid( "nappi").onclick = function() { document.forms.haku.submit(); <body> <form name="haku" action="hae.jsp"> <input type="text" name="sana"/> <img id="nappi" src="hae.gif"/> </form> </body> Ensimmäisen kerran JavaScript oli mukana Netscape 2.0B3 -selaimessa, joulukuussa 1995. Internet Explorerin yhteydessä erehdytään usein puhumaan JavaScriptistä, vaikka tarkoitetaan Microsoftin omaa JScriptiä [Jsc06]. JScriptissä on joitakin eroavaisuuksia JavaScriptiin, vaikka kielet muistuttavat hyvin paljon toisiaan. JavaScript tunnetaan myös nimellä ECMAScript [ECM99]. 2.3 Asynkroniset palvelupyynnöt Perinteisesti selain lataa sivun palvelimelta HTTP-protokollalla [BFF95, FIG99], minkä jälkeen koko selaimen näkymä päivitetään palvelimelta saadulla datalla. XMLHttpRequest (XHR) [Kes06] on JavaScript-olio, joka pystyy kutsumaan palvelinta itsenäisesti. Saatu vastaus otetaan haltuun JavaScript-koodissa, ja se voidaan esimerkiksi antaa jonkin HTML-elementin sisällöksi tai tallentaa muuttujaan.

10 Kutsu sallitaan vain sille palvelimelle, jolta sivu on ladattu. XHR-kutsu voi olla synkroninen tai asynkroninen, mutta useimmat työkalupakit tukevat vain asynkronista kutsua, koska tällöin käyttöliittymä ei lukkiudu kutsun ajaksi, vaan siirto tapahtuu taustalla. Listauksessa 2.4 on esimerkki tyypillisestä asynkronisesta kutsusta palvelimelle. Ensin luodaan uusi ilmentymä XHR-objektista. Objektin nimi vaihtelee selaimesta riippuen. Tämä esimerkki toimii Firefoxilla. Alustuksen jälkeen asetetaan muuttujiin kutsuttava osoite ja sivun kohde-elementti. Tämän jälkeen määritellään takaisinkutsufunktio, jossa palvelimelta saatu vastaus asetetaan kohde-elementin sisällöksi. Lopuksi selain lähettää palvelimelle GET-tyyppisen kutsun. Palvelimelta saatu vastaus käsitellään takaisinkutsufunktiossa, jossa se asetetaan kohde-elementin sisällöksi. Sisällön asettamisen sijaan voitaisiin myös kutsua jotain funktiota palvelimelta saaduilla arvoilla tai ajaa palvelimelta saatu JavaScript-koodi. Vaikka luokan nimi onkin XMLHttpRequest, niin sen sisältämän datan ei välttämättä tarvitse olla XML-muotoista. Usein käytettyjä muotoja ovat XML-kielen lisäksi teksti, JavaScript ja JavaScript Object Notation (JSON). var xhr = new XMLHttpRequest(); var url = "list.jsp?id=123" var targetdiv = document.getelementbyid("mainlist"); xhr.open("get", url, true); xhr.onreadystatechange = function() { if (xhr.readystate == 3) { targetdiv.innerhtml = xhr.responsetext; xhr.send(); Listaus 2.4: XMLHttpRequest esimerkki JSON [Jso07] on kätevä muoto tietorakenteille, koska se vie vähemmän tilaa kuin XML-muoto ja koska se evaluoituu suoraan JavaScriptin objektiksi. Objekti voi sisältää listoja ja assosiatiivisia taulukoita (map), jotka ovat nimi-arvo-pareja. Näitä voi olla myös sisäkkäin. Listauksessa 2.5 henkilot-muuttujaan on tallennettu lista henkilöistä, joille on syötetty ika, kaupunki ja lapset assosiatiivisessa taulukossa. Lapset on esitetty vuorostaan listana. Sijoituksen jälkeen henkilön tietoja päästään lukemaan suoraan pistenotaatiolla. JSON-muotoa voidaan käyttää selaimen ja palvelimen välillä kommunikointiin molempiin suuntiin. Eri palvelinpään ohjelmointikielille, kuten Javalle on olemassa kirjastoja, joilla saadaan muunnettua oliot JSON-merkkijonoksi ja toisin päin [Jso07]. XHR:n käyttö vähentää tarvetta koko sivun uudelleenlataamiselle, mikä puolestaan vähentää tietoliikenteen määrää ja palvelinkuormaa. Sivujen käyttö nopeutuu ja niistä saadaan monipuolisempia.

11 var henkilot = { "pekka":{ "ika":25, "kaupunki":"helsinki", "lapset":["liisa","matti","petri"], "jussi":{ "ika":25, "kaupunki":"turku", "lapset":["anna","satu","harri","keijo"] ; var pekan_lasten_maara = henkilot.pekka.lapset.length; var jussin_kaupunki = henkilot.jussi.kaupunki; Listaus 2.5: Esimerkki JSON-objektista Alun perin Microsoft kehitti XHR:n Internet Explorerille, mutta myöhemmin myös muut selaimet ovat alkaneet tukemaan sitä, tosin hieman erilaisella syntaksilla. XHR on yksi Ajax-tekniikan peruspilareista. 2.4 Ajax-tekniikka Asynchronous JavaScript and XML (Ajax) [Gar05] on ohjelmointitekniikka, joka mahdollistaa vuorovaikutteisten, työpöytäsovellusten näköisten WWW-sovellusten toteuttamisen. Termillä tarkoitetaan edellä mainittujen XHTML-, CSS- ja XHRtekniikoiden käyttöä JavaScriptin avulla. Tyypillisiä Ajaxilla toteutettavia verkkosovellusten vuorovaikutteisuutta ja käytettävyyttä parantavia käyttöliittymätoimintoja ovat esimerkiksi raahaus, välilehdet, yksittäisten ruutujen päivitys ja animaatiot [Pau05]. Tunnetuimpia Ajaxiin perustuvia sovelluksia ovat Googlen tuotteet, kuten Gmail, Google Maps ja Google Suggest. Nämä sovellukset on toteutettu Googlen omalla työkalupakilla (Google Web Toolkit), joka on tässä tutkielmassa yhtenä vertailukohteena. Kuvassa 2.1 on esimerkki Gmail-postiohjelman eräästä Ajax-toiminnallisuudesta. Kun käyttäjä alkaa kirjoittamaan osoitekenttään vastaanottajan nimeä, aukeaa alapuolelle lista syötetyillä kirjaimilla alkavista osoitteista. Sen sijaan, että avattaisiin uusi ikkuna osoitetiedoille, näytetäänkin suodatettu laatikko samalla sivulla, minkä sisältö on jo ladattu etukäteen piiloon. Toisin sanoen aina ei edes tarvitse lähettää kutsua palvelimelle, vaan selainkin voi varastoida tietoa.

12 Kuva 2.1: Ajaxia hyödyntävä Gmail Toinen hyvä esimerkki Ajax-sovelluksesta on Google Maps. Perinteisissä karttasovelluksissa käyttäjä on joutunut lataamaan kokonaan uuden sivun nähdäkseen viereisen karttapalan. Tämä on hidasta ja kömpelöä, esimerkiksi jos käyttäjä haluaisi kohdistaa karttapalan juuri tiettyyn kohtaan. Google Mapsissa (ks. Kuva 2.2) karttaa pystyy raahaamaan hiirellä. Puuttuvat palat haetaan palvelimelta vasta siinä vaiheessa, kun niitä tarvitaan tai jo vähän etukäteen. Kuvasta saa lennossa satelliittinäkymän ja sitä pystyy tarkentamaan ja loitontamaan. Osoitekenttään kirjoitettaessa ohjelma ehdottaa paikkoja, joita käyttäjä on hakenut aikaisemmilla kerroilla. Kuva 2.2: Ajaxia hyödyntävä Google Maps Perinteisen WWW-sovellusmallin ja Ajax-mallin eroa voidaan myös havainnollistaa kutsukaaviolla. Kuva 2.3 esittää perinteistä kutsuketjua, jossa jokainen käyttäjän toiminto lataa kokonaan uuden sivun [FiT02]. Tämä koetaan usein rasittavaksi

13 varsinkin hitailla tai ruuhkaisilla verkkoyhteyksillä. Käyttäjä ei voi myöskään hyödyntää lataukseen kuluvaa aikaa millään tavalla. käyttäjän toiminnot käyttäjän toiminnot käyttäjän toiminnot Asiakas Aika datan siirto datan siirto datan siirto datan siirto Palvelin palvelinpään prosessointi palvelinpään prosessointi Kuva 2.3: Webin perinteinen, synkroninen kutsuketju [Gar05] Ajaxin mallissa palvelinkutsut ovat asynkronisia, joten ne pystytään ajamaan taustalla. Kuvassa 2.4 tätä kuvataan kolmen eri kerroksen välisellä kommunikoinnilla. Ylimpänä kerroksena ovat selaimen käyttöliittymä ja käyttäjän toiminnot. Alimpana kerroksena on palvelin, josta tieto haetaan. Väliin jää Ajax-kerros, jonka tehtävänä on käsitellä käyttäjän syötteet, palvelinkutsut, vastaukset palvelimelta ja päivittää käyttöliittymä. Kun käyttäjä lähettää pyynnön, Ajax-kerros toimittaa sen palvelimelle ja käsittelee sieltä saadun vastauksen. Sillä aikaa käyttäjä voi suorittaa muita toimintoja, koska selain ei lukkiudu odottamaan vastausta palvelimelta. Vastauksen tultua Ajax-kerros käsittelee sen ja päivittää käyttöliittymän. Näin palvelinpään laskentaan ja tietoliikenteeseen kulunut aika saadaan paremmin hyödynnettyä. Toisaalta tämä voi myös kuormittaa palvelinta paljon enemmän, sillä käyttäjä pystyy lähettämään useita palvelinkutsuja samanaikaisesti [TAW03]. Toisaalta käyttäjän syötteistä aiheutuvasta näkymän muuttumisesta ei aina lähde kutsua palvelimelle, kuten kuvan 2.1 esimerkissä syötettäessä vastaanottajan osoitetta. Ajax-ohjelmointiin sisältyy runsaasti haasteita [Smi06]. XHR, tyyliohjeet ja JavaScript eroavat joiltakin osin eri selaimissa. Kirjainmerkkejä on hankala saada toimimaan, jos sisäisten latausten takia sivun osoite ei koskaan muutu. Samasta syystä myös paluutoiminto on monimutkaista toteuttaa. Lisäksi JavaScriptistä puuttuu suurille ohjelmistoille tarpeellisia ominaisuuksia, kuten periytyminen ja pakkaushierarkiat.

14 Asiakas Selaimen käyttöliittymä Käyttäjän toiminnot Ajax-koodi Asiakaspään prosessointi syöte tuloste syöte tuloste syöte tuloste syöte tuloste Aika datan siirto datan siirto datan siirto datan siirto datan siirto datan siirto datan siirto datan siirto Palvelin palvelinpään prosessointi palvelinpään prosessointi Kuva 2.4: Ajaxin asynkroninen kutsuketju [Gar05] Näihin ongelmiin ratkaisun tuo Ajax-työkalupakki, joka tarjoaa korkeamman tason rajapinnan ohjelmointiin sekä selainriippumattomat valmiit funktiot. Työkalupakkeja on kuitenkin kymmeniä ja sopivan valinta voi olla vaikeaa. Luvussa 4 esitellään Solitalle kolme varteenotettavaa vaihtoehtoa. palvelinpään palvelinpään prosessointi prosessointi Tekniikan tuoreuden vuoksi eletään myös eräänlaista kuplavaihetta. Kirjoja aiheesta on julkaistu lyhyessä ajassa lukuisia [CPJ06, Eic06, GGA06, Mah06, ScA06]. Olisi myös hyvä miettiä, tarvitseeko ohjelman toimia selaimessa, vai onko sovellus parempi toteuttaa esimerkiksi Java Web Start -ohjelmana (ks. luku 2.5). 2.5 Ajaxille vaihtoehtoiset tekniikat Selainten vuorovaikutteisuutta on yritetty parantaa muilla tekniikoilla jo ennen Ajaxia. Ensimmäisenä markkinoille tuli sovelma (Java applet). Se on selaimessa suoritettava Java-ohjelma. Toimiakseen sovelma tarvitsee kuitenkin asennetun Javan virtuaalikoneen sekä selaimen, joka tukee sitä. Sovelman etuja ovat tuki useimmille selaimille, turvallisuus ja vuorovaikutteiset ohjelmat. Sovelmien kanssa on myös ongelmia. Kaikilla käyttäjillä ei ole oikeuksia asentaa suoritukseen tarvittavaa virtuaalikonetta, joten käyttäjäkunta jää rajalliseksi. Virtuaalikoneen asentaminen on hidasta. Sovelmien kanssa on myös paljon yhteensopivuusongelmia eri virtuaalikoneiden versioiden kanssa. Esimerkiksi Firefox-selaimella sovelman korkeuden asettaminen samaksi kuin selaimen korkeus toimii huonosti. Lisäksi ohjelmat ovat raskaita suorittaa [Rob07]. Adobe Flash (aikaisemmin Macromedia Flash) [All02] on vektorigrafiikkaan, animointiin ja multimediaan käytetty ohjelma. Flashista tuli sen julkaisun (1996) jälkeen suosittu väline animaation ja vuorovaikutteisuuden lisäämiseen WWW-

15 sivuille. Se pyrki tehokkaampana ja monipuolisempana ratkaisuna korvaamaan Java sovelman. Sitä käytetään paljon mainoksiin, videokuvan tuomiseen WWWkomponentteihin ja joskus myös kokonaisten sivustojen tekemiseen. Sekä Java-sovelmilla että Flash-sivuilla on yhteisiä huonoja puolia. Ne vaativat liitännäisen asentamisen, johon kaikilla käyttäjillä ei ole mahdollisuutta. Lisäksi niissä eivät toimi paluunappi, sivuhistoria eivätkä kirjanmerkit. Hakukoneet ja tekstinlukijat eivät myöskään osaa lukea näillä tekniikoilla tehtyjä sivuja. Sun Microsystems on tuonut aivan toisenlaisen lähestymistavan vuorovaikutteisuudelle ja käytettäville WWW-sovelluksille. Tekniikan nimi on Java Web Start [Sri07]. Siinä ideana on, että selainta ei käytetä lainkaan, vaan sivulla tarjotusta yhdestä linkistä asennetaan sovellus jouhevasti omalle koneelle. Lisäksi ohjelma osaa päivittää verkosta itsensä jokaisen käynnistyksen yhteydessä. Myös OpenXUP [YBC06] tarjoaa vaihtoehtoisen lähestymisen monipuolisten ja vuorovaikutteisten verkkosovellusten toteuttamiseen hyödyntäen XUP (Extensible User Interface Protocol) -protokollaa. Protokolla on SOAP (Simple Object Access Protocol) -pohjainen [YuB05], ja sitä käytetään käyttöliittymän tapahtumien lähettämiseen sekä verkosta saatujen päivitysten noutamiseen. XUP tarjoaa mallin, joka yhdistää perinteisten työpöytäsovellusten ja verkkopohjaisten palveluiden käyttöliittymäparadigmat. Käyttöliittymää on mahdollista päivittää osa kerrallaan, joten käyttäjä ei joudu kärsimään hitaista vasteajoista. Molempien tekniikoiden ehkä merkittävimpänä etuna on eri tavalla käyttäytyvistä selaimista eroon pääseminen. Sovellusten kehittäminen on huomattavasti helpompaa, kun kaiken voi tehdä yhdellä kielellä. Lisäksi sovelluksiin saa enemmän toimintoja kuin Ajax-sovelluksiin. Tulisikin aina punnita, tarvitseeko sovelluksen todella toimia selaimessa vai kelpaako omalle koneelle helposti asentuva erillinen sovellus.

16 3 Ajax-työkalupakit Työkalupakki käsitteenä sekoitetaan usein sovelluskehykseen (framework) ja kirjastoon (library), vaikka kyse on eri asioista. Sovelluskehys tarjoaa rakenteen ohjelmistolle ja sisältää kirjastoja. Tyypillisesti ohjelman kontrolli on sovelluskehyksellä (Hollywood-periaate), joka kutsuu itse toteutettuja komponentteja. Tästä esimerkkinä mainittakoon Spring Framework, jota on käytetty tämän tutkielman esimerkkisovelluksessa [ArA05]. Kirjasto on joukko funktioita tai luokkia ja metodeita, joiden tarkoituksena on tehdä yksittäisen ongelman ratkaiseminen helpommaksi korkean tason rajapintojen avulla. Kirjasto ei sisällä sellaisenaan ajettavia ohjelmia [ScA06]. Työkalupakki on joukko kirjastoja ja työkaluohjelmistoja, joilla hoidetaan jokin kokonaisuus, kuten käyttöliittymä. Ajax-työkalupakki siis tarjoaa työkalut Ajaxtekniikan hallitsemiseen. Kirjastojen lisäksi työkalupakki voi sisältää esimerkiksi uuden tyylin ohjelmoida korkeammalla tasolla [Doj06] tai jopa kokonaan eri kielellä [CLW06]. Työkalupakki ei kuitenkaan koskaan tarjoa ohjelman ydintä, kuten sovelluskehys. Selaimissa on lukuisia pieniä eroavaisuuksia ja virheitä. Esimerkiksi Internet Explorer 7 -selaimesta puuttuu getelementsbytagname -funktio, joka kuitenkin löytyy kaikista muista selaimista. Tapahtumien käsittely sekä XHR-pyyntöjen muoto ei ole myöskään sama Internet Explorerissa ja Firefoxissa. Tällaisia eroja ja virheitä on joskus hyvinkin vaikea tunnistaa. Ajax-työkalupakin tarkoituksena on helpottaa Ajaxsovelluksen kehitystä. Se abstrahoi selaimen tarjoaman rajapinnan omalla rajapinnallaan tarjoten ohjelmoijalle uudet suunnittelumallit. Työkalupakki abstrahoi selaimet samalla tavalla kuin C-kielen kirjastot käyttöjärjestelmän [Res06]. Ajax-työkalupakki tarjoaa yleensä työkalut grafiikan, tapahtumien, JavaScriptin ja XHR-kutsujen käsittelyyn. Se tarjoaa myös joukon valmiita käyttöliittymäkomponentteja (widget) sekä kehitysvaiheen testausympäristön. Kiinnostus tekniikkaan on kasvanut räjähdysmäisesti ja Ajax-työkalupakkeja on julkaistu jo yli 40 kappaletta. Nämä voidaan jakaa karkeasti kolmeen eri ryhmään. Pelkällä JavaScriptillä toteutettuja työkalupakkeja ovat esimerkiksi Dojo, YUI, Prototype, Rico ja MochiKit. Näille lähtökohtana on tarjota kehittäjälle joukko JavaScript-funktioita yleisimpien toimintojen toteuttamiseen. Lisäksi JavaScriptkieleen voidaan keinotekoisesti tuoda uusia ominaisuuksia, kuten perintä ja pakkaukset. Puhtaiden JavaScript-toteutusten etuna on riippumattomuus palvelinpään