ESA BORG AJAX-HENKINEN SELAINKÄYTTÖLIITTYMÄ ASE-LAITOKSEN SÄÄASEMAAN. Kandidaatintyö

Transkriptio

1 ESA BORG AJAX-HENKINEN SELAINKÄYTTÖLIITTYMÄ ASE-LAITOKSEN SÄÄASEMAAN Kandidaatintyö Tarkastaja: Jari Seppälä Aihe hyväksytty

2 II TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Automaatiotekniikan koulutusohjelma ESA BORG: AJAX-henkinen selainkäyttöliittymä ASE-laitoksen sääasemaan Kandidaatintyö, 25 sivua, 5 liitesivua Elokuu 2011 Pääaine: Automaation tietotekniikka Tarkastaja: tutkija Jari Seppälä Avainsanat: Ajax, Asynchronous Javascript And XML, Web 2.0, JavaScript, jquery, Dojo Toolkit, YUI, Web-sovelluskehitys Web-sovelluskehitys on noussut 2000-luvulla merkittäväksi osa-alueeksi ohjelmistokehityksen piirissä. Vuosituhannen vaihteessa puhjenneen ns. "dot-com -kuplan" puhjettua ala hiljeni, mutta nyt uusien tekniikoiden ja web-selainten standardien kehittymisen myötä on uskallettu lähteä uuteen nousuun. Tämä nähdään selvästi nousevien uusien, vain internetissä palvelujaan tarjoavien, yritysten nousuna ja menestyksenä. Tästä hyvänä esimerkkinä yhden web-sivun ympärillä toimiva Facebook, inc. Työn tavoitteena on vertailuun perustuen arvioida kolmen markkinoilla menestyneen ohjelmistokehyksen vahvuuksia eri osa-alueilla ja niiden soveltuvuutta eri käyttötilanteisiin. Työ jakautuu loogisesti kolmeen osaan. Ensimmäisessä osassa esitellään Ajax-tekniikan ideaa eri tekniikoiden yhteiskäytöstä, historiaa ja tekniikkaa. Toisessa osassa esitellään web-sovelluskehityksessä käytettävien ohjelmistokehysten yleisiä piirteitä ja motivaatioita hyödyntää näitä, sekä esitellään lyhyesti kolme JavaScript-ohjelmistokehystä jotka lähestyvät asiaa hieman esi näkökulmista. Kolmannessa osassa kerrotaan kuinka edellä esiteltyjä tekniikoita on hyödynnetty sääaseman käyttöliittymän toteutuksessa, ja millaisia huomioita toteutuksen aikana nousi esiin. Web-sovelluskehyksiä on lukuisille muillekin ohjelmointikielille kuin JavaScriptille, mutta työn keskittyessä web-ohjelmien asiakaspäässä toimivaan Ajax:iin, on vain luonnollista rajata tutkittavat kehykset asiakaspään toteutuksissa käytettävään JavaScript-kieleen. Tästä rajauksesta huolimatta vertailuun on saatu kolme hyvin erilaista kehystä, jotka on tarkoitettu eri kokoluokan ja tyypin web-sivujen ja -sovellusten toteuttamiseen. Työssä saavutettiin sille asetetut tavoitteet. Tarkastelluista ohjelmistokehyksistä löydettiin eroavaisuuksia, jotka johtivat vahvuuksiin toisistaan poikkeavissa käyttötapauksissa ja -ympäristöissä.

3 III ALKUSANAT Tämä tekniikan kandidaatintyö on kirjoitettu vuoden 2011 kevään ja kesän aikana Tampereen teknillisen yliopiston systeemitekniikan laitokselle. Työ tehtiin tekniikkademonstraatioksi uusien Web 2.0 mahdollisuuksien kartoittamiseksi ja esittelemiseksi automaatioympäristöissä. Haluan esittää kiitokset työn tarkastajalle tutkija Jari Seppälälle vapaista käsistä niin työn aikataulun kuin toteutuksenkin suhteen.

4 IV SISÄLLYS 1. Johdanto Ajax Historia Tekniikka Rajoitteet Käyttökohteet JavaScript-ohjelmistokehykset jquery Dojo YUI Yhteenveto Sääasema Jatkokehitysmahdollisuudet Yhteenveto Lähteet A.Liitteitä A.1 Kuvakaappaus käyttöliittymästä A.2 JavaScript-koodin Ajax-osuus A.3 Sääaseman WebService-rajapinnan XML-vastaus A.4 Lohkokaavio toiminnallisuudesta

5 V TERMIT JA SYMBOLIT ActiveX-komponentti Microsoftin ActiveX-ohjelmistokehystä käyttävä liitännäinen Internet Explorer selainohjelmaan. Komponenttien avulla voidaan lisätä toiminnallisuutta, kuten animaatioita ja avattavia valikoita, sivuilla suoritettaviin web-sovelluksiin. ActiveX-komponenttit voidaan kirjoittaa millä tahansa kielellä, jolla on mahdollista luoda COM-komponentteja. Ajax Asynchronous JavaScript and XML. Ohjelmointitekniikka rikkaiden ja vuorovaikutteisten wwwverkkosovellusten toteuttamiseksi. Ajax-moottori JavaScriptillä toteutettu välikerros käyttöliittymän ja palvelimen välillä. Keskeinen osa Ajax-arkkitehtuuria. Android Googlen mobiililaitteille kehittämä käyttöjärjestelmä. Atom-syöte XML:ään pohjautuva standardi verkkosyötteille ja tiedon syndikoinnille, sekä HTTP-protokollaa käyttävä rajapinta verkkosisällön päivittämiseen. BSD-lisenssi Berkeley Software Distribution (BSD) lisenssi on vapaa ohjelmistolisenssi ja yksi käytetyimmistä avoimen lähdekoodin jakelussa käytetyistä lisensseistä. Moniin muihin lisensseihin verrattuna sen ehdot ovat melko yksinkertaiset, sillä se sallii käyttäjän tehdä ohjelmakoodille mitä haluaa. Lisenssi sallii koodin muokkaamisen ja uudelleenkäytön. Lisenssi ei vaadi julkaisemaan lähdekoodia ja BSD-lisensoitua koodia sisältävän tuotteen voi julkaista halutessaan toisella lisenssillä. COM Componen Object Model on Microsoftin julkaisema binäärirajapintastandardi, joka mahdollistaa prosessien välisen kommunikoinnin ja dynaamien olioiden luonnin useilla eri ohjelmointikielillä. Nykyään COM:ia käytetään myös sateenvarjoterminä, jonka piiriin kuuluu mm. ActiveX. CSS Cascading Style Sheets. W3C:n standardoima tyylimäärittelykieli www-dokumenttien ulkoasun määräämiseen. DOM Document Object Model. Tarjoaa alusta- ja kieliriippumaton tavan esittää HTML-, XHTML- ja XMLpohjaiset dokumentit puurakenteena ja vuorovaikuttaa dokumentin sisällön ja rakenteen kanssa.

6 VI Flash Fragment identifier HTML HTML5 HTTP ios Java applet JavaScript JSON Kiertokysely Laiska lataus Ohjelmistokehys Flash on laajassa käytössä oleva Adobe Systemsin toteuttama multimedia-alusta animaatioiden, videoiden ja vuorovaikutteisuuden toteuttamiseksi verkkosivuilla. URL-osoitteen #-merkin jälkeinen osa. Hyper Text Markup Language (suom. hypertekstin merkkauskieli). WWW-dokumenttien rakenteen kuvaukseen käytetään HTML:n ja XHTML:n eri versioita. Uusin, osin vielä kehityksen kohteena oleva, versio HTML:stä. HTML5:n merkittävimpiä uusia ominaisuuksia ovat audio-, video- ja canvas-tagit, jotka tarjoavat standardin tavan multimediaelementtien sijoittamiseen sivulle[24]. Hypertext Transfer Protocol on TCP-yhteyttä käyttävä tekstipohjainen yhteydetön protokolla, jota muun muassa selaimet ja www-palvelimet käyttävät tiedonsiirtoon. ios on Applen mobiililaitteille kehittämä käyttöjärjestelmä. Java-sovelma. Epäitsenäinen Java-ohjelma, joka ajetaan selaimessa tai Oraclen AppleViewerillä. Javan tavukoodin ansiosta alustariippumaton, mutta vaatii toimiakseen asennetun Java Virtual Machinen. JavaScript on heikosti tyypitetty oliopohjainen tulkittava skriptikieli. Sen pääkäyttökohde on web-sovellusten asiakaspään käyttöliittymälogiikan toteuttaminen. JavaScript Object Notation. Erittäin kevyt tekstipohjainen rakenteinen tiedon esitysmuoto. Nimestään huolimatta JSON ei ole tiukasti kytköksissä JavaScriptiin, vaan on helposti käytettävissä muissakin kielissä. Kiertokysely (eng. polling) on prosessi jossa asiakas säännöllisin aikavälein tarkistaa ulkoisen laitteen, websovellusten tapauksessa www-palvelimen, tilan. Laiska lataus (eng. lazy loading) on ohjelmistojen suunnittelumalli, jossa olio alustetaan vasta sen käytön alkaessa. Ohjelmistokehys tarjoaa rungon jonka päälle ohjelmatuote voidaan kehittää. Sen tarkoituksena on nopeuttaa ja helpottaa ohjelmistokehitystä.

7 VII PHP Pilvilaskenta REST RSS-syöte SOAP URI URL W3C Web Service PHP on Zend Technologies yhtiön kehittämä yleiskäyttöinen skriptikieli, jonka pääasiallinen käyttökohde ovat www-palvelimet joissa sitä käytetään dynaamisten websivujen luomiseen. Pilvilaskennalla tarkoitetaan tässä työssä internetissä (eli pilvessä) tapahtuvaa tiedon prosessointia (eli laskentaa). Käsitteenä se viittaa pilvessä tapahtuvaan prosessointiin, jonka yksityiskohtia käyttäjä ei tunne. Siihen liitetään usein myös jaettujen resurssien käsite. Representational State Transfer, on ohjelmistoarkkitehtuuri hajautetuille hypermediajärjestelmille. RESTrajapinnaksi kutsutaan www-palvelimen tarjoamaa rajapintaa palveluun, jossa viestit palvelimelle välitetään HTTP-pyyntöinä ja palvelin antaa vastaukset yleensä joko XML- tai JSON-muodossa. Really Simple Syndication on XML:llä kuvattujen verkkosyötemuotojen perhe, joita käytetään tiheästi päivittyvän sähköisen sisällön julkaisemiseen. Simple Object Access Protocol, on protokolla rakenteisen tiedon välitykseen viestiessä Web Servicen kanssa. Välitettävät viestit ovat XML-muotoisia, ja niiden välitys tapahtuu useimmiten käyttäen. Uniform Resource Identifier on resurssin yksikäsitteinen nimi tai internetissä sijaitsevan resurssin yksilöivä merkkijono. Uniform Resource Locator on URI, joka määrittelee URI skeeman ja resurssin sijainnin. Tunnetuimpia URL:iä ovat verkkosivujen osoitteet, joiden skeemana on yleensä http. World Wide Web Consortium. Monikansallinen yritysten ja yhteisöjen konsortio, joka kehittää ja ylläpitää WWW:n standardeja. W3C:n määrittelemä ohjelmistojärjestelmä mahdollistamaan tietokoneiden välinen tietoverkon yli tapahtuva vuorovaikutus. Usein termillä viitataan yksinomaan WWW-pohjaiseen ohjelmointirajapintaan, mutta nimellä voidaan viitata myös web-sovelluksiin. Tiedonsiirtoprotokollana molemmissa toimii yleensä HTTP.

8 VIII World Wide Web XHTML XML XMLHttpRequest XSLT Lyhennetään yleisesti muotoon WWW. Internetissä toimiva hajautettu hypertekstijärjestelmä, jonka sisältöä luetaan erillisillä selainohjelmilla. Selaaminen tapahtuu hakemalla dokumentteja, tai sivuja, palvelinkoneelta ja näyttämällä niiden sisältö käyttäjälle. extensible HyperText Markup Language. HTML5:ttä edeltänyt WWW-sivujen merkintäkieli, joka täyttää XML:n vaatimuksen hyvästä muotoilusta (eng. wellformed). extensible Markup Language on on rakenteellinen kuvaskieli. XML:ää käytetään niin tiedon siirtämiseen järjestelmien välillä kuin dokumenttien tallentamiseenkin. Selainskriptikielissä, kuten JavaScriptissä, tarjottu rajapinta tiedonvaihtoon www-palvelimen kanssa. Tiedonsiirtoon käytetään HTTP-protokollaa. extensible Stylesheet Language Transformations on XML-pohjainen merkintäkieli XML-tiedostojen muunnoksiin.

9 1 1. JOHDANTO Valtaosa nykyisin käytössä olevista verkkosivuista on edennyt valtavasti 1990-luvun alussa julkaistun World Wide Webin perusteista. Nykyään useat uudet World Wide Webissä käytettävät tekniikat ja toimintamallit on koottu termin Web 2.0 alle. Ensimmäisen kerran termi Web 2.0 nousi esiin jo Darcy DiNuccin vuonna 1999 julkaistussa artikkelissa[5], mutta nykyiseen merkitykseensä se vakiintui vasta 2000-luvun loppupuolella. Teknisenä terminä Web 2.0 ei ole erityisen hyvin määritelty. Web 2.0 kuvaa nimenomaan verkon uutta toimintamallia jossa käyttäjien vuorovaikutusmahdollisuus, käyttäjälähtöinen sisältö, rikas käyttökokemus ja laiteriippumattomuus ovat vahvasti esillä[17]. Tekniikkaa tähän nimitys ei vahvasti määrittele, mutta yleisesti hyväksyttyjä ja Web 2.0 nimen yhteydessä esitettyjä tekniikoita näiden toteuttamiseen ovat tällä hetkellä muun muassa HTML5, CSS-taitto, Ajax ja Flash. Vähemmän tekniseltä kannalta katsottuna nimen alle luetaan lähes poikkeuksessa myös sisällön monikanavajulkaiseminen RSS- tai Atom-syötteillä ja sisällön, sekä sen tuottamisen, sosiaalinen näkökulma. Tunnettuja Web 2.0:aa noudattavia palveluita ovat olleet esimerkiksi Digg, Flickr ja Last.fm. Web-sovellukset ovat yksi uusimmista ja yhä nopeimmin kasvavista ohjelmistotekniikan aloista. Niillä tavoitetaan helposti suuri käyttäjäkunta joille palvelua ja informaatiota tarjota. Ero web-sovelluksen ja perinteisen web-sivun välillä on se, että web-sovellukset tarjoavat joustavan mahdollisuuden käyttäjän vuorovaikutukseen sivun kanssa. Näin sivu on dynaaminen ja muuttuu käyttäjän syötteiden ja sovelluksen liiketoimintalogiikan mukaan, ilman tarvetta ladata mahdollisesti raskastakin sivua kokonaan uudelleen. Conallenin määritelmän[4] mukaan juuri liiketoimintalogiikka on tekijä, joka erottaa web-sivun ja web-sovelluksen toisistaan. Vanhemmissa web-sovelluksissa liiketoimintalogiikka sijaitsi täysin palvelimella, mutta moderneissa Ajax-tekniikkaa käyttävissä sovelluksissa osa logiikasta on siirretty asiakkaan päätteelle. Tässä kandidaatintyössä tutustutaan rikkaiden asiakkaiden toteutuksessa nykyisin usein käytettäviin JavaScript-ohjelmistokehyksiin. Työn tavoitteena on vertailun avulla arvioida kolmen suositun markkinoilla olevan toteutuksen vahvuuksia eri osa-alueilla ja niiden soveltuvuutta eri käyttötilanteisiin. Työ ei pyri kattamaan koko Web 2.0:n tai rikkaiden web-sovellusten kenttää, vaan keskittyy vain rajattuun

10 1. Johdanto 2 tekniseen osa-alueeseen. Työssä on toteutettu web-sovellus Tampereen Teknillisen Yliopiston ASE-laitoksen sääaseman tietojen esittämiseen. Tietojen päivittäminen sovellukseen tapahtuu asynkronisesti Ajax-tekniikalla, jolloin käyttäjälle syntyvä käyttökokemus on hyvin lähellä perinteistä työpöytäsovellusta. Conallenin[4] kolmiosaisen web-sovellusten jaottelun mukaan tämä, kuten kaikki Ajax:iin perustuvat web-sovellukset, on niin kutsuttu rikas asiakas. Jaottelu ja sen osien asiakaslaitteille asettaman vaatimukset näkyvät kuvasta 1.1. Kuva 1.1: Conallenin jaottelus mukaisesti kolmeen osaan luokitellut web-sovellukset järjestettynä niiden asiakaslaitteelle asettamien vaatimusten mukaiseen järjestykseen.

11 3 2. AJAX Ajax, lyhenne englannin sanoista Asynchronous Javascript And XML, on nimitys ryhmästä web-sovelluskehityksen tekniikoita, joitä käyttäen web-sovelluksista on mahdollista tehdä vuorovaikutteisempia. Ajax-tekniikan tavoitteena on tarjota rikkaampi käyttökokemus verkkopalveluiden käyttäjille. Kuten Web 2.0, myöskään Ajax ei ole itsenäinen teknologia, vaan termi jolla viitataan useiden tekniikoiden yhteiskäyttöön. 2.1 Historia Perinteisessä mallissa verkkosivulta toiselle siirryttäessä selainohjelman on ladattava koko sivu palvelimelta. Tämä malli oli vallalla koko 1990-luvun ja 2000-luvun alun. Mallin haittana on niin teknisiä kuin käyttökokemukseen vaikuttavia syitä. Kun koko sivu ladataan uudelleen, syntyy useimmiten turhaa tiedonsiirtoa, sillä luultavasti vain pieni osa sivun sisällöstä on muuttunut. Tästä huolimatta myös muuttumaton osuus on ladattava uudelleen. Käyttökokemukseen koko sivun uudelleenlataaminen vaikuttaa negatiivisesti muun muassa ruudun vilkkumisena. Tähän ongelmaan vastattiin sisällön asynkronisella lataamisella. Ensimmäisenä tämän mahdollistivat verkkosivuille upotetut Java appletit 1990-luvun puolivälissä. Tekniikaltaan nykyisen kaltainen asynkronisuus toteutettiin vuonna 1999 Internet Explorer 5:een erillisellä XMLHttpRequest ActiveX -komponentilla. Vastaava komponentti implementoitiin muihin selainohjelmiin, muun muassa Applen Safariin, Mozillan Firefoxiin ja Opera Softwaren Operaan, Javascript-objektina. Nykyään myös Internet Explorer toteuttaa ominaisuuden suoraan Javascript-objektina, eikä erillistä ActiveX-komponenttia tarvita. [20][27] Vuonna 2005 James Garrett lanseerasi nimen Ajax, jolla tarkoitettiin mahdollisuutta tiedonsiirtoon selainohjelman ja palvelimen välillä ilman sen vaikutusta sivun näkymiseen[10]. Artikkelissaan Garrett mainitsee Googlen palvelut Google Suggest ja Google Maps, jotka jo tuolloin käyttivät kuvattua tekniikkaa, ja joista kyseinen tekniikka laajemman käyttäjäkunnan tietoisuuteen nousi. Microsoft oli kuitenkin käyttänyt samaa tekniikkaa omassa Exchange 2000 Outlook Web Access sähköpostiohjelmassaan jo vuonna 2000.[27] Kyse ei siis ole erityisen uudesta tekniikasta, vaan paremminkin vain uudesta tavasta käyttää yhdessä jo olemassa olevia tekniikoita. Ajax:in kulmakivenä toimiva XMLHttpRequest ei ole vieläkään saavuttanut lo-

12 2. Ajax 4 pullisen W3C:n standardin asemaa[25]. Ensimmäinen määritelmäluonnos (eng. Working Draft) julkaistiin Viimeisin versio tästä on julkaistu suosituskandidaatti (eng. Candidate Recommendation). Nämä ovat W3C:n standardin elinkaaren kaksi alinta porrasta sen neliportaisessa hierarkiassa[26]. 2.2 Tekniikka Kuten edellä mainittiin, Ajax ei ole itsenäinen tekniikka, se on tapa toteuttaa asia uudella tavalla käyttäen jo olemassa olleita tekniikoita. Garrettin määritelmän[10] mukaan Ajax koostuu seuraavista tekniikoista: sivun taittaminen (X)HTML:n ja CSS:n avulla vuorovaikutus elementtien kanssa käyttäen DOM:ia tiedonsiirto ja muokkaus käyttäen XML:ää ja XSLT:ää asynkroninen tiedonsiirto XMLHttpRequestin avulla näiden sitominen yhteen JavaScriptillä Ajax:in suurin saavutus on kätkeä suuri osa palvelinyhteydestä käyttäjän silmiltä. Perinteisessä web-sovellusmallissa lähes kaikki käyttäjän vuorovaikutus johti uuteen sivulataukseen, jossa koko sivu ladattiin palvelimelta uudelleen. Useissa tapauksissa käyttäjän toimet eivät kuitenkaan vaadi palvelimelta kuin hieman, jos lainkaan, uutta tietoa. Näissä tapauksissa riittää hakea palvelimelta vain muuttunut tieto ja päivittää käyttäjän näkymään vain näiltä osin. Kuvissa 2.1 ja 2.2 on vertailtu perinteisen ja Ajax:iin pohjautuvan selainsovelluksen toimintaa yhteydenpidossa palvelimen kanssa. Kuten kuvasta nähdään, suurimmat muutokset mallissa ovat tapahtuneet käyttäjän selaimen päässä, jonne on lisätty uusi välitaso. Palvelinpään asetuksiin on tehtävä muutoksia vain HTTP-palvelimeen tulosteisiin. Muutosvaatimukset ovat verrattain rajallisia, sillä muutoksia tietovarastoihin ja taustajärjestelmiin ei tarvita. Perinteistä rakennetta noudattavasta kuvasta (kuva 2.1) nähdään, käyttäjän toimet välitetään suoraan palvelimelle. Näin ollen jokainen toimi aiheuttaa koko sivun uudelleen latautumisen. Tästä johtuen käyttäjä voi käynnistää yhden toimen kerrallaan, ja seuraava voidaan suorittaa vasta kun edellinen suoritus on saatu valmiiksi. Karkeasti tämän mallin pohjalta toimittiin WWW:n alusta alkaen aina Ajax:in nousuun asti.

13 2. Ajax 5 käyttäjän selain käyttöliittymä käyttäjän selain käyttöliittymä JavaScript-kutsu HTML+CSS Ajax-moottori http-pyyntö http-tiedonsiirto HTML+CSS http-pyyntö http-tiedonsiirto XML www-palvelin www-palvelin tietovarastot, taustajärjestelmät palvelin Kuva 2.1: Perinteisen selainsovelluksen malli, jossa käyttöliittymä kommunikoi suoraan palvelimen kanssa. tietovarastot, taustajärjestelmät palvelin Kuva 2.2: Ajax:ia hyödyntävän selainsovelluksen malli. Selaimeen lisätty uusi välitaso, Ajax-moottori. Ajax-pohjaisessa mallissa (kuva 2.2) havaitaan selaimessa Ajax-moottori pelkän käyttöliittymän lisänä. Ajax-moottori toimii väliportaana käyttöliittymän ja palvelimen välillä; käyttöliittymän pyynnöt tapahtuvat JavaScriptillä Ajax-moottorille, joka päättää kuinka pyyntöön vastataan. Tarvittaessa moottori on yhteydessä palvelimeen lähettämällä HTTP-pyynnön ja saaden XML-muotoisen vastauksen. Moottori myös muokkaa käyttöliittymän ulkoasua, klikkauksen jälkeen käyttäjälle voidaan kertoa prosessoinnin olevan käynnissä ja palvelimen vastattua moottorille päivitetään tiedot käyttäjän nähtäviksi. Koko prosessin ajan käyttäjä on voinut hallinnoida muita osia sovelluksesta, eikä hän ole joutunut odottamaan ensimmäisen pyynnön valmistumista. Monet nykyisistä verkkopalveluista tarjoavat www-palvelimellaan rajapinnan, jolla kyseisen palvelun ominaisuuksia saa hyödynnettyä muillakin tavoilla kuin suoraan selaimella käyttäen. Nämä rajapinnat on usein toteutettu käyttäen joko SOAPtai REST-tekniikoita, joissa tiedonsiirtoon käytetään useimmiten joko XML:ää tai JSON:ia. Näistä REST on kevyempi sen hyödyntäessä HTTP-protokollan sanastoa, mutta SOAP tarjoaa monipuolisemmat ja laajoihin toteutuksiin paremmin sopivan mallin toteuttamalla itse oman rajapintasanastonsa. Ajax-palvelut eivät ole ainoita hyödyntämässä näitä rajapintoja, mutta Ajax:in käytön yleistyminen on selvästi

14 2. Ajax 6 näkynyt etenkin REST-rajapintojen tarjonnan yleistymisenä. Tiedonsiirrossa www-palvelimelta Ajax-moottorille Garrett on esittänyt käytettäväksi XML-muotoon paketoitua rakenteista dataa. XML ei kuitenkaan ole missään tapauksessa vaatimus, jotta toteutus täyttäisi Ajax:in määritteet. Www-palvelin voi palauttaa vaikka pelkkää tekstiä ilman rakenteista esitystapaa. Useimpiin käytännön tarkoituksiin rakenteinen muoto on kuitenkin huomattavasti käytettävämpää. Artikkelissa Garrett on nimennyt muodoksi XML:n sen ollen pisimmälle kehittynyt yleisesti käytetty rakenteisten dokumenttien muoto. Muiden muotojen kehityttyä vuosikymmenen puolivälin jälkeen huomattavastikin, on JSON noussut erittäin käytetyksi muodoksi XML:n rinnalle. [10] käyttäjän selain käyttäjän vuorovaikutus käyttäjän vuorovaikutus käyttäjän vuorovaikutus aika http-pyyntö vastaus, tiedonsiirto http-pyyntö vastaus, tiedonsiirto palvelin palvelimen prosessointi palvelimen prosessointi Kuva 2.3: Perinteisen selainsovelluksen viestinvälitys ajan kuluessa. Jokainen pyyntö välitetään www-palvelimelle joka vastaa suoraan käyttöliittymään. Tässä mallissa käyttöliittymä on siis vuorovaikutuksessa paikalliseen kohteeseen, joka siten kykenee vastaamaan pyyntöihin huomattavasti nopeammin, kuin mitä verkon yli vastaava www-palvelin. Muutokset käyttöliittymän ulkoasuun tapahtuvat Ajax-moottorin toimesta, ei suoraan www-palvelimen. Www-palvelin toki yhä tarjoaa käyttöliittymään tarpeelliset tiedot rakenteisessa muodossa, mutta muutoksista vastaa paikallisesti toimiva Ajax-moottori. Näin palvelimen vastausviiveen aiheuttama odotus saadaan kätkettyä käyttäjältä. Ajax:ia käyttävässä mallissa käyttäjän selain on yhteydessä palvelimeen lähinnä Ajax-moottorin kautta, ja saa vastauksensa rakenteisessa muodossa. Poikkeuksen tähän aiheuttaa aina ensimmäinen sivulataus sivustolle saavuttaessa. Tätä on havainnollistettu kuvassa 2.4. Tällöin selain lataa palvelimelta sivun ulkoasun ja ainakin osan JavaScript-kooditiedostoista. Tämä yhteys tapahtuu noudattaen kuvan 2.1

15 2. Ajax 7 käyttäjän selain käyttöliittymä käyttäjän vuorovaikutus Ajax-moottori pyyntö näkymän päivitys näkymän päivitys pyyntö näkymän päivitys pyyntö näkymän päivitys aika http-pyyntö vastaus, tiedonsiirto http-pyyntö vastaus, tiedonsiirto http-pyyntö vastaus, tiedonsiirto http-pyyntö vastaus, tiedonsiirto palvelin palvelimen prosessointi palvelimen prosessointi palvelimen prosessointi palvelimen prosessointi Kuva 2.4: Ajax-mallin mukaisessa selainsovelluksessa vuorovaikutus käyttöliittymän ja tiedonvaihto www-palvelimen kanssa on Ajax-moottorin vastuulla. mukaista mallia. Koska sivun koko ulkoasu ladataan vain ensimmäisen sivulatauksen yhteydessä, laskee Ajax-mallin käyttö myös tiedonsiirtomääriä. Kuvat 2.3 ja 2.4 kuvastavat mallien käyttämän viestinvälityksen eroa. Kuva 2.4 esittää selkeästi kuinka Ajax-mallin ratkaisussa käyttöliittymän vuorovaikutus tapahtuu Ajax-moottorin kanssa ja vain osa pyynnöistä aiheuttaa kutsun palvelimelle. Kun seurataan kuvissa käyttäjän vuorovaikutus -viivaa, nähdään kuinka se kuvassa 2.3 katkeaa jokaisen käyttöliittymän lähettämän pyynnön seurauksena. Ajaxmallissa käyttäjän vuorovaikutus -viiva on yhtenäinen, katkoksia ei synny palvelimelle (tai tässä tapauksessa Ajax-moottorille) lähtevien pyyntöjen ja sen vastausten välillä. Juuri tämä katkottomuus parantaa ohjelmasta syntyvää käyttökokemusta merkittävästi Rajoitteet Perinteisiin ratkaisuihin verrattuna Ajax tuo mukanaan myös ongelmia ja sen käyttöön sisältyy rajoitteita, jollaisia perinteiset www-sivujen toteutuksessa käytetyt tekniikat eivät sisältäneet. Ajax:ia käyttävät web-sivut ja web-sovellukset vaativat vakaan verkkoyhteyden

16 2. Ajax 8 toimiakseen. Perinteisessä mallissa käyttäjän selain latasi käytettävän sivun tai näkymän, jonka jälkeen yhteyttä ei tarvittu ennen seuraavaa sivusiirtymää. Ajax:ssa Ajax-moottori tekee hakuja palvelimelta käyttäjän huomaamatta tai ainakin ilman käyttäjän vuorovaikutusta. Jos käytettävä yhteys ei kuitenkaan ole vakaa, aiheutuu siitä ongelmia. Koska Ajax tukeutuu vahvasti JavaScriptiin ja sen XMLHttpRequest-objektiin, vaaditaan selaimelta tuki näille sivujen toimimiseksi. Vaikka näitä tukevat nykyään käytännössä kaikki, myös mobiilialustojen selaimet, saattavat ne olla esimerkiksi tietoturvasyistä otettuina pois käytöstä. Etenkin jos sivun sisällön olisi oltava saavutettavissa myös yksinkertaisimmilla selainsovelluksilla (matkapuhelimet, tekstipohjaiset selaimet, ruudunlukijat), on sisältö tärkeää tarjota myös Ajax:ia käyttämättömässä muodossa. Oletusarvoisesti Ajax:lla tapahtuvissa sivusiirtymissä selainohjelma ei havaitse siirtymää. Näin ollen selaimen sivuhistoriaan ei jää tietoa vierailluista sivuista, vaan ainoastaan osoitteesta jolla sivulle tai sovellukseen saavuttiin. Sama ongelma nousee esiin myös, kun yritetään luoda linkki tai kirjanmerkki sivulle, johon on saavuttu Ajax-kutsujen tuloksena. Tätä linkin luomista suoraan haluttuun pisteeseen sivustoa kutsutaan syvälinkitykseksi (eng. deep linking). Käytännössä tämä näkyy tilanteissa, jolloin selainsovelluksen osoiterivillä on yhä osoite jolla sivustolle saavuttiin, mutta sisältö ei ole sama kuin osoitteeseen saapumalla saadaan ruudulle. Ratkaisuksi näihin on toteutettu mahdollisuus päivittää sivun URL-osoitteen fragment identifier:ia, ja tarkkailemalla Ajax-moottorilla tämän muutoksia. Näin sivun URLosoite vaihtuu aina, kun Ajax-moottori päivittää sivun sisältöä, ja näkyvää osoitetta voidaan käyttää samaan pisteeseen palaamiseen.[16] Ajax:n avulla ei voida hakea sisältöä mistäpäin verkkoa tahansa, vaan web-sivulla tai sovelluksessa käytettäviä lähteitä rajoittaa niin kutsuttu same origin policy. Tämä on useimmista selaimessa käytettävistä skriptikielistä, myös JavaScriptistä, löytyvä rajoite jolla pyritään parantamaan tietoturvaa. Käytännössä tämä rajaa hyväksyttävän kohteet pyynnöille vain siihen osoitteeseen jossa pyynnön lähettäjä itse on. Näin pyritään estämään vihamielisen tai haitallisen koodin joutuminen sivulle. W3C:llä on Cross-Origin Resource Sharing luonnos, jonka myötä ongelma häviäisi[23]. Tässä resurssia jakava kone lisäisi HTTP-otsakkeisiin erityiset Access-Control-Allow-Origin, Access-Control-Allow-Methods ja Access- Control-Allow-Headers -kentät, jotka kertovat Ajax:ille sisällön olevan tarjolla myös Ajax-etäpyynnöille. Siihen asti ongelma voidaan joko kiertää käyttäen JSON- P:tä[19] tai kiertämällä suojamekanismi välityspalvelimen avulla[12].

17 2. Ajax Käyttökohteet Ajax:n käyttö web-sivuilla ja -sovelluksissa on levinnyt hyvin laajalle. Vaikka edellä puhuttiin hyvin pitkälle vain web-sovelluksista, ei sen käyttö ole rajoittunut vain näihin. Nykyään rajanveto web-sovellusten ja interaktiivisten web-sivujen välillä on hyvin haastavaa, eikä tarkkaan rajanvetoon olekaan syytä pyrkiä. Selviä tapauksia ovat vain ääriesimerkit täysin staattisista web-sivuista ja toisessa päässä työpöytäsovelluksia jäljittelevistä web-sovelluksista. Ilmeisimmät ja perinteisesti tunnetuimmat esimerkit Ajax:in käytöstä ovat jo luvussa 2.1 mainitut Google Suggestions ja Google Maps. Näiden lisäksi monet muut Googlen palvelut, esimerkiksi Calendar ja toimisto-ohjelmat sisältävä Docs tukeutuvat vahvasti Ajax-tekniikkaan. Mainituista esimerkeistä Calendar ja Docs edustavat voimakkaasti perinteisiä työpöytäsovelluksia jäljittelevää osaa web-sovelluksista. Tarjolla on myös niin kutsuttuja web-työpöytiä, jossa käyttöjärjestelmän toimintoja jäljitellään selaimessa. Ratkaisuja on tarjolla monella eri tekniikalla toteutettuina, mutta Ajax:ia käyttäviä toteutuksia ovat esimerkiksi eyeos[8] ja icould[33]. Palveluiden tausta-ajatuksena on tarjota käyttäjälle samat resurssit käyttöön päätelaitteesta riippumatta. Käyttäjä voi siis kirjautua samalle työpöydälle miltä tahansa päätteeltä jossa on riittävillä ominaisuuksilla varustettu selain. Monissa palveluissa on tarjolla myös mahdollisuus mobiilikäyttöön älypuhelimella. Käytettävyys ja käyttökokemus näkökulmien korostuminen web-sivujen suunnittelussa ja toteutuksessa on johtanut Ajax:in käytön yleistymiseen. Google Suggestions ominaisuus Googlen hakukoneessa on tästä hyvä esimerkki. Siinä Ajax:in avulla toteutettiin ennustava tekstin syöttö hakukenttään. Nykyisin vastaavaa ominaisuutta käytetään monissa muidenkin sivujen ja sovellusten hakukentissä, esimerkiksi Facebookin[9] henkilöhakussa. Facebook käyttää Ajax:iä laajemminkin, koko palvelun ollen vahvasti sen varaan rakennettu. Esimerkkinä tästä sivuston ydintoiminnallisuuteen kuuluva automaattisesti päivittyvä syötevirta kavereiden tilapäivityksistä. Siinä selain pitää palvelimeen yhteyttä kiertokyselyn avulla, mahdollistaen sisällön automaattisen aikaperustaisen päivittämisen.

18 10 3. JAVASCRIPT-OHJELMISTOKEHYKSET Web-sovelluskehityksen noustua merkittäväksi osa-alueeksi ohjelmistokehityksessä (eng. software framework), on sen piiriin syntynyt myös muusta ohjelmistokehityksestä tuttuja työkaluja. Pitkään web-sovelluskehitystä väheksyttiin, ja siten siihen oli tarjolla varsin rajoitetusti saatavilla tukea ja yleisesti hyviksi havaittuja toimintatapoja ei ollut vakiintunut. Viimeisimpinä kehityksessä oli JavaScript, vaikka kielenä se on ollut olemassa ja ainakin osittain selaimissa tuettuna 1990-luvun lopulta alkaen. Tästä huolimatta JavaScript nousi todelliseen arvoonsa vasta Ajax:in myötä. Aikaisemmin sen käyttöä web-sivuilla ja -sovelluksissa varottiin ja sen käytöstä varoitettiin, mutta nykyään sitä käytetään useimmilla sivuilla. Tämän yleistymisen myötä JavaScript-kehityksen avuksi on julkaistu muistakin ohjelmointikielistä tuttuja ohjelmistokehyksiä. JavaScriptin tapauksessa ohjelmistokehyksen termi on varsin hämärä. Ohjelmistotekniikan määritelmä ohjelmistokehyksestä (oletusarvoinen käyttäytyminen, suoritushallinnan pysyminen kehyksellä, laajennettavuus ja kehyksen koodin muokkaamattomuus) eivät JavaScriptin yhteydessä täyty[18]. Tässä mielessä seuraavaksi ohjelmistokehyksinä esiteltävät ovat vain kirjastoja tai työkalukokoelmia (eng. toolkit). Näiden tarkoitus on kuitenkin olla web-sovelluksen suunnitteluratkaisujen pohjana ja mahdollisesti sisällyttää alaisuuteensa useita muita kirjastoja. Tämän eron korostamiseksi tässä yhteydessä näistä puhutaan ohjelmistokehyksinä, vaikkei se tarkan tulkinnan mukaan olisikaan oikea termi. JavaScript-ohjelmistokehyksen tapauksessa valintaperusteet poikkeavat paikoin perinteisen, käännettävän ohjelman, ohjelmistokehyksen valinnan perusteista. Erityisesti JavaScript-kehyksen valintaan vaikuttavia seikkoja listaa muun muassa Larry Ullman, jonka lyhyt kirjoitus[22] tuo esiin seuraavat neljä kriteeriä: ominaisuudet, dokumentointi ja esimerkit, tiedostokoko ja riippuvuudet sekä lisensoinnin. Kuten Ullman kirjoituksessaan toteaa, nykyisistä JavaScript-kehyksistä kaikki ovat hyviä ja kypsiä käytettäviksi. Yksiselitteisesti parasta on tietenkin mahdotonta valita, mutta käyttötapauskohtaisesti tarkastellen kehysten keskinäiset erot vaikuttavat soveltuvuuteen. Kaikkien tässä esiteltävien ohjelmistokehysten tavoitteena, omien mainostensakin mukaan, nopeuttaa ja helpottaa rikkaiden ja vuorovaikutteisten web-sivujen ja - sovellusten toteuttamista. Tarjoamalla yhtenäinen pohja ja perustyökalut, voidaan

19 3. JavaScript-ohjelmistokehykset 11 pienemmällä määrällä itse kirjoitettavaa koodia saada aikaan entistä enemmän. 3.1 jquery Vuonna 2006 julkaistu jquery on tällä hetkellä ylivoimaisesti suosituin JavaScriptohjelmistokehys. Web-sivuilla käytettäviä tekniikoita seuraavan BuiltWith Trendsin tilaston mukaan yli 43 prosentilla internetin suosituimmista sivuista käytetään jquerya, ja sen osuus kasvaa tasaisesti[2]. Tunnettuja palveluita ja yritysten verkkosivuja joilla jquery on käytössä, ovat esimerkiksi Google, Digg ja Netflix[14]. Myös Nokia ja Microsoft ovat ottaneet jqueryn käyttöön omissa tuotteissaan, Nokia tarjoamassaan Web Run-Time -kehitysalustassa ja Microsoft ASP.NETkehyksessään[13]. jquery koostuu ytimestä, käyttöliittymäelementtejä tarjoavasta jquery UI:stä ja molempiin liitettävistä lisäosista. Ydin sisältää muun muassa seuraavat ominaisuudet: työkaluja helpottamaan kielen perustoimintojen käyttöön DOM elementtien valinta CSS-tyylisillä valitsimilla sekä liikkuminen hierarkkisen DOM-puun sisällä DOM elementtien muokkaaminen ja poistaminen helppokäyttöinen rajapinta asynkronisen palvelinyhteyden hyödyntämiseen tapahtumapohjainen toiminta (eng. events) ulkoasun muokkaus CSS-määreiden avulla efektejä ja animaatioita Vaikka ydin tarjoaa työkaluja elementtien animointiin, on laajemmissa sivustoissa ja sovelluksissa suositeltavampaa käyttää ulkoasuun jquery UI:tä. Se tarjoaa laajemman työkaluvalikoiman käyttöliittymän toteuttamiseen ja tarjoaa mahdollisuuden teemojen käyttöön, jolla vähennetään entisestään itse kirjoitettavan koodimäärän taakkaa. Arkkitehtuuriltaan jquery on suunniteltu niin, että sen ominaisuuksia on helppo laajentaa omilla lisäosilla. Huomattava osa jqueryn tarjoamista ominaisuuksista onkin juuri näiden lisäosien kautta toteutettuja. Lisäosilla tarjotaan mahdollisuuksia muun muassa XML-rakenteen käsittelyyn, funktioita Ajax:n käytön yksinkertaistamiseen ja tiedon esittämiseen dynaamisissa taulukoissa ja kuvaajien piirtämiseen. Monet sivustot onkin mahdollista toteuttaa täysin jo olemassa olevilla lisäosilla,

20 3. JavaScript-ohjelmistokehykset 12 jolloin itse kirjoitettavaksi koodiksi jää vain valmiiden osien liittäminen yhteen kokonaisuudeksi. Selaimista jquery ilmoittaa tukevansa Google Chromea, Internet Exploreria versiosta 6, Mozilla Firefozia versiosta 2, Safaria versiosta 3 ja Operaa versiosta 9 alkaen[14]. Työpöytäkoneiden selaimista kaikki merkittävät toimittajat ovat siis katettuina. Mobiililaitteille jquery ei suoraan tarjoa tukea. Tätä aukkoa paikkaa kuitenkin jquery Mobile, joka tarjoaa tuen useimmille mobiilialustoille[15]. Selaintuen lisäksi toinen keskeinen ominaisuus JavaScript-ohjelmistokehyksissä on niiden koko. Tässä vertailussa jquery pärjää varsin hyvin tuotantoon tarkoitetun versionsa 84 kilotavun koolla. 3.2 Dojo Dojo Toolkit on vuonna 2004 julkaistu ohjelmistokehys. Nykyään Dojo Toolkitin kehitystä koordinoi Dojo Foundation. Verrattuna jqueryyn projekti vaikuttaa olevan rahoituksen puolesta vakaammissa käsissä, sillä sitä sponsoroivat sekä IBM että Oracleen nykyisin kuuluva entinen Sun Microsystems[7]. Web-sovelluskehityksen kannalta merkittävää on myös PHP:n takana olevan Zend Corporationin tuki ja pyrkimys sisällyttää se kehittämäänsä, PHP-kehityksessä hyvin käytettyyn, Zend Frameworkiin[32]. Dojo Toolkit koostuu Dojo-ytimestä sekä Dijit- ja DojoX-nimiavaruuksista. Ydin sisältää jqueryn ytimen tapaan perustoiminnallisuuden, mutta huomattavasti rajoitetummassa määrin. Hieman yksinkertaistettuna ydin sisältää seuraavat ominaisuudet: työkaluja helpottamaan kielen perustoimintojen käyttöön DOM elementtien valinta CSS-tyylisillä valitsimilla DOM elementtien muokkaaminen ja poistaminen helppokäyttöinen rajapinta asynkronisen palvelinyhteyden hyödyntämiseen tapahtumapohjainen toiminta (eng. events) olioiden varastointi, datan käytön yksinkertaistaminen Kuten edellä mainittiin, niin Dojon ydin sisältää vähemmän toiminnallisuutta kuin jqueryn vastaava. Tähän on syynä Dojo Toolkitin arkkitehtuurissa pidemmälle viety oliopohjainen ajattelumalli. Ydin on haluttu pitää suppeana ja tarjota perustoiminnallisuuden ulkopuoliset toiminnot Dijit ja DojoX nimiavaruuksissa. Näistä kahdesta Dijit on tarkemmin säädelty, sen osat taataan vakaammiksi, ja se sisältää osia lomakkeiden käsittelyyn sekä ulkoasun ja käyttöliittymän toteuttamiseen.

21 3. JavaScript-ohjelmistokehykset 13 Jälleen jqueryyn verraten tätä osaa voidaan pitää jquery UI:ta vastaavana. DojoX taas sisältää laajennoksia näihin kahteen, jqueryn nimeämiskäytäntöön verrattuna nämä ovat lisäosia, tarjoten laajempia käyttömahdollisuuksia. Sponsoreistaan huolimatta Dojo Toolkitin käyttö on jäänyt sivustoilla melko vähäiseksi. BuiltWith Trendsin mukaan internetin suosituimman sivun joukosta vain noin 0.4 prosentissa on käytetty tätä[1]. Osasyynä tähän on varmastikin Dojon rakenne, joka ei suosi sen käyttöä pienessä mittakaavassa. Tarkoittamatta että internetin suosituimmat sivut käyttäisivät ohjelmistokehysten palveluita vain pienessä mittakaavassa, mutta jqueryyn verrattuna Dojo Toolkitin toteutukseen jättämä jalanjälki on huomattavan iso. Tämä johtuu toteutuksessa ja suunnittelussa valituista ratkaisuista, jotka tekevät Dojosta jquerya täydellisemmän ohjelmistokehyksen ohjelmistotekniikan määritelmien mukaan. Selaintukea Dojo Toolkit tarjoaa useammille eri selaimille kuin jquery, mukaan lukien mobiilialustojen selaimia. Versionumeroissa tukea ei kuitenkaan luvata yhtä vanhoille selaimille kuin jqueryn tapauksessa. Yhteensopiviksi ilmoitetaan Firefox 3.6, Safarin version 4 ja 5, Chrome 8, Internet Explorer versiosta 6 lähtien sekä Opera versiosta lähtien. Mobiilialustoista tuki ilmoitetaan ios:lle ja Androidille. [6] 3.3 YUI Yahoo! on kehittänyt vuodesta 2005 lähtien omaa Yahoo! User Interface (YUI) JavaScript-ohjelmistokehystään. Alusta lähtien tätä on käytetty Yahoo!:n omissa palveluissa, esimerkiksi heidän portaalinsa etusivulla ja sähköpostipalvelussa. Vuoden 2006 alkupuolelta lähtien YUI on ollut julkisessa jakelussa. Uusin tarjolla oleva versio on vuonna 2009 julkaistu YUI 3, jota Yahoo! itsekin nykyään käyttää. Tämän lisäksi tukea tarjotaan yhä vuonna 2006 julkaistulle YUI 2:lle. Toisin kuin kahdessa edellä esitellyssä kehyksessä, YUI:n kehityksen takana ovat Yahoo!:n omat insinöörit eikä avoin yhteisö. Tämä ei tarkoita etteikö YUI:n ympärillä vastaavaa yhteisöä kuitenkin olisi, ydinryhmä kuitenkin koostuu Yahoo!:n työntekijöistä. Nimekkäästä kehittäjäorganisaatiosta ja pitkästä historiastaan huolimatta YUI ei ole onnistunut keräämään itselleen erityisen suurta käyttäjäkuntaa. BuiltWith Trendsin tilastosta nähdään, kuinka vain hieman yli 4% internetin :sta suosituimmasta sivusta käyttää sitä. Trendi on myös varsin suora, eli selkeää kehitystäkään ei ole ollut nähtävissä. [3] Esitellyistä kehyksistä YUI tarjoaa tiedostokoossa mitattuna selkeästi kevyimmän ratkaisun. YUI:ssa modulaarinen rakenne on viety pidemmälle kuin jqueryssä tai Dojo Toolkitissä, ja tämän johdosta ydin on saatu todella pieneksi. Tuotantoversioon tarkoitetun version koko on vain 31 kilotavua. YUI 3:n ydin sisältää vain: työkaluja helpottamaan kielen perustoimintojen käyttöön ja YUI:n perusin-

22 3. JavaScript-ohjelmistokehykset 14 frastruktuurin helppokäyttöinen rajapinta asynkronisen palvelinyhteyden hyödyntämiseen tapahtumapohjainen toiminta (eng. events) DOM elementtien valinta ja muokkaus Muiden, siis ytimeen kuulumattomien, ominaisuuksien lataaminen on toteutettu käyttämällä dynaamista laiskaa latausta. Näin vältytään turhalta ominaisuuksien lataamiselta ja sen aiheuttamalta käytön hidastumiselta ja turhalta tiedonsiirrolta. YUI sisältää laajan kokoelman näitä ytimeen kuulumattomia keskitetysti hallinnoituja ominaisuuksia.[29] Verrokkeihinsa nähden YUI:n selkeä etu on myös sen lisensioinnissa. Toisin kuin jo esitellyt jquery ja Dojo Toolkit, YUI:n tarjoaa täyden kokoelman komponentteja yhtenäisellä BSD-lisenssillä.[31] Näin kehyksen kaupallinenkin käyttö yksinkertaistuu, sillä jokaisen komponentin ja liitännäisen lisenssiä ei ole erikseen tarkastettava ja käytettävä valintojen perusteena. Selaintuki on YUI:n tapauksessa ilmoitettu ylivoimaisesti selkeimmällä tavalla. Heidän käyttämänsä taulukkorakenne ja moniportainen tukiasteikko[28] on otettu käyttöön myös ainakin jquery Mobilen selaintuen ilmoittamisessa. YUI tukee kaikkia moderneja työpöytäkoneiden selainohjelmia, ja mobiilialustoiltakin suuri osa on katettu tukemalla niin Androidin kuin ios:n oletusselainta. Edellisistä kehyksistä poiketen, Yahoo! tarjoaa YUI:n yhteyteen myös suoranaisesti kehykseen kuulumattomia työkaluja web-sivujen ja -sovellusten kehitykseen. Tällaisia työkaluja ovat esimerkiksi koodin profiloinnin työkalut[29] ja erityisen mielenkiintoisena työkaluna koodin pakkaaja[30]. Web-sovelluksissa tiedostokoon näytellessä merkittävää roolia, koodin pakkaaminen (tai minimointi) on erittäin hyödyllinen ominaisuus. Tässä ohjelma optimoi muuttujien nimiä lyhyemmiksi, poistaa kommentteja ja turhia sisennyksiä. Koodin toimivuus säilyy siis samana, mutta se ei pysy ihmiselle helposti luettavassa muodossa. 3.4 Yhteenveto Kuten jo edellä sanottu, kaikki esitellyt kehykset ovat hyviä. Tästä huolimatta näkyvissä on jo monesti ennenkin nähty suuntaus, jossa markkinoilla pärjäämiseen ei riitä että on hyvä. Etenkin avoimen lähdekoodin järjestelmissä sen lisäksi tarvitaan aktiivisia käyttäjiä ja kehittäjiä pitämään alustan ekosysteemi elossa. Samoin hyvin samankaltaisilla kehyksillä saattaa olla keskenään eroja, jotka selkeästi ohjaavat niiden valintaan erityisesti tietyn tyyppisissä projekteissa. Esitellyistä kehyksistä jquery soveltuu parhaiten erityisesti pienten, toisistaan irrallaan olevien ominaisuuksien toteuttamiseen. Sen jalanjälki toteutuksessa on hyvin

23 3. JavaScript-ohjelmistokehykset 15 pieni, ja siten se on helppo ottaa käyttöön jo hyvin pienten ominaisuuksien toteuttamiseen järjestelmässä, jossa ei entuudestaan ole kehystä käytössä. Vasta jquery UI tuo mukanaan kokonaisvaltaisuuden, jossa rohkaistaan koko käyttöliittymän toteutukseen sen avulla. YUI, kuten nimi Yahoo! User Interface tuo esille, on pitkälle käyttöliittymävetoinen ratkaisu. Sen avulla on tarkoitus rakentaa koko web-sivun tai -sovelluksen käyttöliittymä. Tästä johtuen keveydestään huolimatta YUI jättää toteutusratkaisuihin ja suoraan koodiinkin melko suuren jalanjäljen. Näin ollen YUI:n käyttöönotto pienen, käyttöliittymään vain heikosti liittyvän toiminnallisuuden toteuttaminen on verrattain hankalaa. Dojo Toolkit puolestaan on kolmesta esitellystä selkeästi eniten web-sovellusten alustaksi suunnattu, ei niinkään vain web-sivuille. Sen tuoma jalanjälki toteutukseen on huomattavan suuri, ja jo pienten asioiden toteuttaminen vaatii enemmän ladattavia paketteja ja itse kirjoitettua koodia. Tämän tuomat edut nousevat esiin vasta laajemmissa kokonaisuuksissa, joissa koodia syntyy huomattavia määriä. Dojo Toolkitin käyttö lähinnä web-sovelluksissa web-sivujen sijaan selittää osaltaan tilastoissa havaittavaa jakautumista. Nimi Jakelukoko Mobiililaitetuki 1 Selaintuki Levinneisyys 2 jquery 84 kt ios 4, Symbian S60 v5.0, BlackBerry OS v6.0, Android v1.5+, Windows Mobile v7.0, HP webos 1.4.1, Samsung bada 1.0 Dojo 89 kt ios 4, Android v2.0+ YUI 3 31 kt ios 3+, Webkit Android v2.0+ Chrome 8+, Internet Explorer 6+, Firefox 2+, Safari 3+, Opera 9+ Chrome 8+, Internet Explorer 6, 7 & 8, Firefox 3.5 & 3.6, Safari 4.1+, Opera Chrome 8+, Internet Explorer 6+, Firefox 3+, Safari 5 43,2 % 0,4 % 4,4 % Taulukko 3.1: Vertailtujen JavaScript-ohjelmistokehysten koot, selaintuet ja levinneisyydet. 1 Alustat joille tekijät ilmoittavat täyden tuen. YUI 3:n yhteydessä ilmoitetaan Webkit-tuki ainoastaan Androidille, mutta käytännössä tuki on yhtä laajaa kuin jqueryllä. 2 Mittarina käytetään esiintymäosuutta BuiltWith Trendsin suosituimman sivun tekniikoissa.[1][2][3]

24 3. JavaScript-ohjelmistokehykset 16 Taulukko 3.1 esittää vertaillut JavaScript-ohjelmistokehykset, niiden pakatut tuotantokäyttöön tarkoitetut tiedostokoot, selaintuki ja levinneisyys. Jakelukoko ja levinneisyys ovat helposti vertailtavia sarakkeita, mutta selaintuki niin mobiililaitteissa kuin työpöytäkäytössäkin on vaikeammin vertailtavaa. Vertailun vaikeus johtuu tekijöiden toisistaan eroavista tavoista ilmoittaa tuetut selaimet. Etenkin mobiililaitepuolella ilmoituksissa esiintyy suuria eroja jqueryn tekijöiden luetellessa kaikki tuetut käyttöjärjestelmäalustat YUI 3:n tekijöiden mainiten vain Applen ios -käyttöjärjestelmän ja Webkit-prosessorin, jonka tuki on vielä ilmoitettu vain Android-alustalle. Käytännössä sama Webkit on käytössä myös useimmissa muissa jqueryn kohdalla listatuissa mobiiliselaimissa, joten myös YUI 3 toimii niillä. Kaikki vertaillut kehykset tukevat käytännössä kaikkia uusimpia laajalle levinneitä selaimia. Erot tuetuissa versionumeroissa selittyvät kehysten ja selainten julkaisuaikatauluilla. Vanhojen selainten, kuten Firefox 2:n, tuki on osasta jätetty jo pois kun taas Dojo:n versio julkaistiin ennen Internet Explorer 9:n ja Firefox 4:n lopullisten versioiden julkaisua. Kuva 3.1: Google Trends kuvaaja kolmen esitellyn JavaScript-ohjelmistokehyksen nimillä suoritetuista hauista. Suoritetut haut korreloivat monesti hyvin vahvasti vertailtavien keskinäiseen suosioon. BuiltWith Trendsin mittausten mukaan[1][2][3] tässä esitellyt kehykset voidaan tänä päivänä selkeästi laittaa järjestykseen jquery, YUI ja Dojo Toolkit. Kuvassa 3.1 esitettävät Google Trendsin[11] hakujen määrän vuosien varrella tukevat samaa järjestystä kehysten keskinäiselle suosiolle, mutta ei kuitenkaan tuo YUI:n ja Dojo Toolkitin eroa esiin aivan yhtä suurena. Syyksi tälle voidaan nähdä Dojo Toolkitin

25 3. JavaScript-ohjelmistokehykset 17 soveltuvuus erityisesti web-sovelluksiin, joista monet eivät ole verkossa avoimesti tarkasteltavina. Näin ne eivät voi näkyä BuiltWith Trendsin tilastossa, mutta niiden kehittäjän suorittavat kuitenkin niiden tekniikkaan liittyviä hakuja, nostaen niitä Googlen kuvaajassa. Kuvasta 3.1 näkyy myös selkeästi jqueryn nousu valta-asemaan. Ennen sen julkaisua, ja vielä puolitoista vuotta julkaisun jälkeenkin, aikaisemmin markkinoilla olleilla YUI:lla ja Dojo Toolkitillä oli nähtävissä selkeää nousua Ajax:in suosion alettua. Vuoden 2008 alku näkyy kuitenkin selvästi hetkenä jolloin jquery löi läpi ohittaen YUI:n ja Dojo Toolkitin, eikä muutosta ole sittemmin tapahtunut. Kuva 3.2: Useiden JavaScript-ohjelmistokehysten TaskSpeed nopeusvertailu eri selainversioilla suoritettuna. ( Eri kehysten tehokkuuksista ei ole olemassa tuoreimmista versioista kertovaa vertailua. Tehokkuuden, tässä tapauksessa tosin vain nopeuden, vertailuun käytetty työkalu on TaskSpeed[21]. Sen avulla voi itse laskea nopeudet eri kehyksille oman tietokoneen, sen käyttöjärjestelmän ja selaimen tapauksessa. Kattavamman kuvan kuitenkin saa, jos samalla koneella on testi on suoritettu samalla koneella mutta useilla eri selainversioilla kuten kuvassa 3.2 on tehty. Näin nopeuserot kehysten välillä näkyvät selkeimmin. Työssä kehitetyn sääaseman toteutukseen käytettiin Dojo Toolkittiä. Valinnan

26 3. JavaScript-ohjelmistokehykset 18 perusteena oli tekniikkaan tutustuminen. Vaikka tutkimuksen perusteella tämän kokoluokan toteutukseen se oli kolmesta vertaillusta heikoin valinta, silti Dojo Toolkitin kokonaisvaltainen lähestymistapa toteutuksen hallintaan sopisi hyvin laajempien teollisuustoteutusten pohjaksi. Tämä puolusti Dojo Toolkitin valintaa työn toteutuksessa.

27 19 4. SÄÄASEMA ASE-laitoksen sääasema on kurssilla ASE-6010 Tietoverkkopohjainen automaatio käytettävä harjoitustyökohde. Sääasemajärjestelmä koostuu palvelimesta ja siihen kytketystä sääasemasta. Palvelin tarjoaa WebService-rajapinnan sääaseman tietojen lukemiseen, jota käyttäen asiakassovellukset voivat verkon yli lukea sen tiedot. Kuva 4.1 esittää järjestelmän rakennetta. Työn toteutuksessa varsinaista sääasemaa ei ole käytetty, vaan sen antamia tuloksia on simuloitu www-palvelimelta. Kuva 4.1: ASE-laitoksen sääaseman rakenne. Toteutetussa käyttöliittymässä sääasemalta luettavasta datasta saadaan mittauksen ajankohta, mitattu lämpötila ja GPS-koordinaatit mittauksen sijainnille. Todellisuudessa mittari on varsin kiinteästi paikallaan, mutta simuloinnissa paikkatiedon käytön esityksen vahvistamiseksi sijainti on asetettu vaihtumaan mittausten välillä. Mittausajankohdan ja -tuloksen perusteella piirretään kuvaajaa lämpötilan vaihtelusta, esittäen 30 edellistä mittausta. Viimeisimmät mittaustulokset näytetään myös tekstinä tietoikkunoissa kuvaajan alapuolella, jossa näytetään myös onko mittaus-

28 4. Sääasema 20 tietojen trendi laskeva vai nouseva. Liitteen A.1 kuvasta nähdään toteutettu lopputulos. Nykyisessä muodossaan sääasemaa ei voi ohjata millään tavoin, sen rajapinnan kautta on ainoastaan luettavissa tietoja. Näin ollen käyttöliittymäkään ei voi tarjota varsinaista vuorovaikutusmahdollisuutta itse mittalaitteen kanssa, vaan vuorovaikutus tapahtuu vain jo olemassa olevan mittaustiedon kanssa. Käyttöliittymä koostuukin ainoastaan näkymästä, jota päivitetään ajastetusti. Ajax moottori on ajastettu hakemaan palvelimelta uusi mittaustieto kymmenen sekunnin välein ja päivittämään tiedot käyttöliittymään. Toteutuksen suppeudesta johtuen Dojo Toolkitin käyttö ei ole tässäkään esitellyistä kehyksistä tarkoituksen mukaisin, kuten jo kappaleessa 3.4 todettiin. Dojo Toolkitin ytimen lisäksi toteutuksessa on hyödynnetty vain DojoX-paketista löytyvää kuvaajan piirtotyökalua. Tätä käyttäen kuvaajan piirto onnistuu pitämällä piirrettävät tiedot vain taulukkorakenteessa, ja antamalla tämä syötteenä piirtäjälle. Merkittävimpiä ytimestä käytössä olevia ominaisuuksia ovat DOM-elementtien valinta näkyvyyden manipulointi, näkyvyysmuutoksiin liitetyt animaatiot ja elementtien sisällön päivitys, sekä ehdottomasti ajastin, jonka avulla näkymä on saatu päivittymään ilman käyttäjän vuorovaikutusta. Käytännössä sääaseman WebService-rajapinta tarjoaa mittaustiedot XML-muodossa, jonka Ajax-moottori tulkitsee ja kerää viestistä tarvitsemansa tietokentät. Esimerkki rajapinnan tarjoamasta mittausdatasta löytyy liitteestä A.3. Esimerkissä esitetään yhden mittauspisteen tiedon siirto. Yhdessä XML:ssä voidaan kuitenkin siirtää myös useita mittauspisteitä monistamalla <measurement>-tagia jokaiselle pisteelle. Tätä hyödynnetään näkymän alustuksessa, jossa vain viimeisimmän mittauspisteen sijaan ladataan useita historiapisteitä kuvaajan piirtämiseksi. Historiatietoa sovellus säilyttää paikallisessa tietovarastossa, tarkemmin JavaScriptin taulukkona. Tietovarastossa pidetään tallessa 30 mittausta, ja tätä tietoa käyttäen käyttöliittymän kuvaajaa päivitetään. Sovelluksen saadessa uuden mittauspisteen, lisätään se tietovarastoon samalla vanhin arvo poistaen. Sovelluksen toiminnan ydin perustuu ajastetusti toistuviin kutsuihin palvelimelle, jossa sovellus pyytää uutta mittaustulosta. Saatuaan mittaustiedon XML-sanomana, sovellus päivittää saadut tiedot paikalliseen tietovarastoon ja päivittää tiedot käyttöliittymään. Lopuksi settimeout()-funktiota käyttäen toimintalogiikan sisältävä updatetime()-funktio kutsuu itseään 10 sekunnin odotuksen jälkeen. Suorituksen eteneminen on esitetty lohkokaaviona liitteessä A Jatkokehitysmahdollisuudet Sääaseman ja sääasemapalvelimen pysyessä nykyisessä muodossaan, jatkokehitysmahdollisuudet ovat varsin rajalliset. Niin pitkään kuin tietoa saadaan ainoastaan

29 4. Sääasema 21 luettua, eikä sen muodostumiseen päästä millään tapaa vaikuttamaan, ei käyttäjällekään voida vuorovaikutusmahdollisuuksia tarjota. Käyttäjälle voidaan toki tarjota viivadiagrammin lisäksi muun laisia kuvaajia visualisoimaan kerättyä mittausdataa. Esimerkiksi piirakkakuvaajana jakaumaa kylmien, viileiden ja lämpöisten lämpöjen kesken. Sääaseman tapauksessa tämän kaltainen tiedon analyysi ei kuitenkaan monesti kaikkia kiinnosta. Kiinnostavana voidaan pitää uusinta mittausta ja lähimpiä historiatietoja, joista voidaan vallitsevan trendin mukaan ennustaa välittömän tulevaisuuden arvoja. Lämpötilan muutosten ennustaminen ei toki todellisuudessa ole näin yksinkertaista. Sääasemaan anturit myös ilmankosteuden ja tuulen nopeuden mittaamiseen, saataisiin tarpeeksi tietoa joista voitaisiin muodostaa monesti sääennusteissa nähty tieto siitä kuinka kylmältä tai lämpimältä ilma tuntuu. Toteutetussa sääaseman simulaatiossa uusi mittaustulos saadaan aina kun sellaista kysytään. Todellisen sääaseman kanssa uusi mittaustulos on kuitenkin saatavissa ainoastaan viiden minuutin välein. Ohjelman kannalta olisi positiivista saada tieto mittausvälistä muutenkin kuin määrittelydokumentista tai sääaseman manuaalista. Jos tämä tieto olisi saatavissa WebService-rajapinnan kautta, ei Ajax-moottorille olisi määriteltävä suoraan koodiin tiedonhaun tiheyttä, vaan se voitaisiin ohjelmallisesti määrittää mukautumaan palvelimen suorittamien mittausten mukaan. Näin turhaa liikennöintiä saataisiin vältettyä. Pelkkää tiedonsaantia hienompi ratkaisu olisi tietenkin päästä itse vaikuttamaan mittauksiin. Pelkän lämpömittauksen tapauksessa ei käyttäjälle olisi järkevä tarjota mahdollisuutta vaikuttaa muuhun kuin mittausten tiheyteen. Mittauslaitteiston kehittyessä vaikutusmahdollisuuksia olisi mahdollista kuitenkin laajentaa. Jos laitteistossa olisi esimerkiksi kirkkausanturi, olisi sille asetettavissa mittauskulma.

30 22 5. YHTEENVETO Työn tavoitteena oli johtaviin markkinoilla saatavilla oleviin JavaScript-ohjelmistokehyksiin tutustuminen ja näiden arviointi. Tarkastelun kohteeksi valittiin kolme ohjelmistokehystä. Otannan suppeudesta huolimatta ohjelmistokehyksistä löytyi selkeitä eroja niiden soveltuvuudessa eri käyttökohteisiin. Useilla osa-alueilla johtavaksi ratkaisuksi ohjelmistokehyksistä valikoitui jquery. Harvoja harvinaisia käyttötapauksia lukuun ottamatta jquery havaittiin parhaiten soveltuvaksi lähes kaikissa tapauksissa. Tilastojen valossa myös käyttäjäkunta on päätynyt samaan lopputulokseen, jqueryn ollessa ylivoimaisesti käytetyin vertaillusta kolmikosta. Työn toteutusosuudessa sääaseman käyttöliittymätoteutuksessa voittajaksi valikoitunutta jqueryä ei käytetty. Toteutustyökaluna käytettiin Dojo Toolkitiä, sillä sen vahvuudeksi havaittiin laajat kokonaisuudet, jollaisia myös automaatiojärjestelmän käyttöliittymä monesti ovat. Tuotetun toteutuksen laajuudessa sen edut eivät kuitenkaan nousseet käytännössä esiin, joten raja jossa edut nousevat oikeuksiinsa on selvittämättä. JavaScript-ohjelmistokehysten käytössä on syytä muistaa niiden tarjoamat mahdollisuudet muuhunkin kuin vain pelkän käyttöliittymän toteutukseen. Käyttöliittymän ja toimintalogiikan välille vedettävä raja on kuin veteen piirretty viiva, mutta kaikkien tässä työssä esitellyt ohjelmistokehykset mahdollistavat myös osan logiikan toteutuksesta. Näin JavaScriptillä toteutettu osuus laajenee pelkästä käyttöliittymän toteutuksesta esimerkiksi jalostamaan tietoa käyttöliittymän esitettäväksi, kuten työn toteutusosuudessa on tehty.

31 23 LÄHTEET [1] BuiltWith Trends. Dojo Toolkit Usage Statistics [WWW] [Viitattu ] [2] BuiltWith Trends. jquery Usage Statistics [WWW] [Viitattu ] http: //trends.builtwith.com/javascript/jquery [3] BuiltWith Trends. Yahoo User Interface Usage Statistics [WWW] [Viitattu ] Yahoo-User-Interface [4] Conallen, Jim. Building Web applications with UML (Second edition) [5] DiNucci, Darcy. Fragmented Future [PDF] [Viitattu ] Saatavissa [6] Dojo Foundation. Dojo 1.6 Release Notes, Browser support [WWW] [Viitattu ] 6.html#id5 [7] Dojo Foundation. Sponsors [WWW] [Viitattu ] http: //dojofoundation.org/about/sponsor [8] eyeos company. eyeos [WWW] [Viitattu ] [9] Facebook, inc. Facebook [WWW] [Viitattu ] com/ [10] Garrett, Jesse James. Ajax: A New Approach to Web Applications. [WWW] [Viitattu ] Saatavissa: ideas/e [11] Google. Google Trends, "jquery,dojo,yui"[www] [Viitattu ] all&date=all&sort=0 [12] Hussain, Aziz. Flex Bypass Same Origin Policy [WWW] [Viitattu ] Flex-Bypass-Same-Origin-Policy [13] jquery blog. jquery, Microsoft, and Nokia [WWW] [Viitattu ] http: //blog.jquery.com/2008/09/28/jquery-microsoft-nokia/ [14] jquery Team. jquery [WWW] [Viitattu ]

32 LÄHTEET 24 [15] jquery Team. jquery Mobile, Mobile Graded Browser Support [WWW] [Viitattu ] [16] Li, Andy. Andy Li s Blog, Deep Linking for AJAX [WWW] [Viitattu ] [17] Reddy S. K. Myths and Realities of Web 2.0, Web 2.0 Key Principles [WWW] [Viitattu ] Saatavissa Realities_of_Web_20.7 [18] Riehle, Dirk. Framework Design: A Role Modeling Approach [PDF] [Viitattu ] Saatavissa dissertation/diss-a4.pdf [19] Simpson, Kyle. JSON-P: Safer cross-domain Ajax with JSON-P/JSONP [WWW] [Viitattu ] Saatavissa [20] Swartz, Aaron. A Brief History of Ajax [WWW] [Viitattu ] Saatavissa [21] TaskSpeed [WWW] [Viitattu ] Saatavissa dojotoolkit.org/taskspeed/ [22] Ullman, Larry. Choosing a JavaScript Framework [WWW] [Viitattu ] Saatavissa Choosing-a-JavaScript-Framework2 [23] W3C. Cross-Origin Resource Sharing [WWW] [Viitattu ] Saatavissa [24] W3C. HTML5 differences from HTML4 [WWW] [Viitattu ] Saatavissa [25] W3C. XMLHttpRequest [WWW] [Viitattu ] Saatavissa w3.org/tr/xmlhttprequest/ [26] W3C. World Wide Web Consortium Process Document, Maturity Levels [WWW] [Viitattu ] Saatavissa Process /tr.html#maturity-levels [27] Hopmann, Alex. Story of XMLHTTP [WWW] [Viitattu ] Saatavissa [28] Yahoo! Inc. Yahoo! Developers Network, Graded Browser Support [WWW] [Viitattu ]

33 LÄHTEET 25 [29] Yahoo! Inc. Yahoo! Developers Network, YUI 3 Yahoo! User Interface Library [WWW] [Viitattu ] [30] Yahoo! Inc. Yahoo! Developers Network, YUI Compressor [WWW] [Viitattu ] [31] Yahoo! Inc. Yahoo! Developers Network, YUI FAQ [WWW] [Viitattu ] [32] Zend Technologies Inc. Zend Frameworkand Dojo Toolkit [PDF] [Viitattu ] Saatavissa ZendFramework-Dojo.pdf [33] Xcerion AB. icloud [WWW] [Viitattu ]

34 26 A. LIITTEITÄ A.1 Kuvakaappaus käyttöliittymästä

35 A. Liitteitä 27 A.2 JavaScript-koodin Ajax-osuus // XMLHttpRequest pyynnön asetukset var xhrargs = { // pyyntö suoritetaan synkronisesti sync: true, content: {act: init }, url: "lahde.php", handleas: "xml", // toiminta jos paluuviestinä ei virhettä (403, 404, 500,...) load: function(data) { var datapoint; var lapset = data.childnodes[0].children; for(var i=lapset.length-1;i>=0;i--) { // puretaan arvot XML-sanomasta datapoint = readdatapoint(lapset[i]); // lämpötila ja kellonaika paikallisiin tietorakenteisiin datapoints.push(parsefloat(datapoint.value)); axislabels.push(datapoint.timestamp.tolocaletimestring()); gps = datapoint.gps; } // poistetaan vanhimmat arvot paikallisesta tietorakenteesta datapoints.shift(); axislabels.shift(); }, error: function(error) { alert( Virhe yhteydessä WebService-rajapintaan ); } } this.updatetime = function() { // suorittaa yllä määritellyn XMLHttpRequest-pyynnön dojo.xhrget(xhrargs); // päivittää mittaustiedot piirto-olioon chart1.updateseries("sarja 1", datapoints); // päivittää x-akselin arvoille nimet (kellonajat) chart1.addaxis("x", { labels: buildlabels(axislabels), majortickstep: 2,

36 A. Liitteitä 28 minorticks: false }); chart1.addaxis("y", { vertical: true, min: -15, max: 15, majortickstep: 3 }); // piirtää kuvaajan uusilla asetuksilla chart1.render(); // siirtää karttamerkin siirramarkkeri(gps.lat, gps.lng) // päivittää tietokentät dojo.byid( trendi ).innerhtml = gettrend(); dojo.byid( viimeisin_aika ).innerhtml = axislabels[axislabels.length-1]; dojo.byid( viimeisin ).innerhtml = datapoints[datapoints.length-1]; dojo.byid( kuvaajan_ka ).innerhtml = datapoints.avg(); newdatarow(dojo.byid( viimeisin_aika ).innerhtml,dojo.byid( viimeisin ).innerhtml); // kutsuu itseään 10 sekunnin kuluttua newtime = settimeout(dojo.hitch(_this, "updatetime"), 10000); this.counter++; }; // kutsuu updatetime():a ensimmäisen kerran, loput kutsut // updatetime() hoitaa itse itseään kutsuen. this.updatetime();

37 A. Liitteitä 29 A.3 Sääaseman WebService-rajapinnan XML-vastaus <ns1:measurements xmlns:ns1=" <measurement> <ns1:gps> , n, e,1.4,152.1,3,13.97,0.79,0.42,141209,07</ns1:gps> <ns1:timestamp> :56:33.0</ns1:timestamp> <ns1:unit>degree</ns1:unit> <ns1:value>2.2</ns1:value> </measurement> </ns1:measurements>

38 A. Liitteitä 30 A.4 Lohkokaavio toiminnallisuudesta Kuva A.1: Lohkokaavio sovelluksen ajastetussa silmukassa suoritettavasta toimintalogiikasta.