fabercon.fi | +358 400 533 978 or +358 44 204 2029Liferayn portaaliohjelmiston mukana asennetaan Liferayn tietokanta, jota käytetään portlettien Java-koodissa Liferayn API-rajapinnan kautta. Nämä rajapintakutsut sisältävät jo transaktion hallinnan (begin transaction ja commit/rollback).
Mistä portletissa sitten haetaan käyttöliittymässä esitettävää dataa? Tässä on varteenotettava menetelmä, jossa on kaksi datalähdettä:
1. Käytetään Liferayn tietokantaa Liferay APIn kautta, joka on tehty tähän tarkoitukseen. Liferayn omaa tietokantaa ei laajenneta.
2. Muu sovelluksen tarvitsema data sijoitetaan muihin tietokantoihin, ja niitä kutsutaan muiden palvelimien kautta, yleensä SOAP- tai RESTful-palvelujen kautta.
Transaktioista on tässä menetelmässä huolehdittava koodaamalla, eli peruttava ongelmatilanteissa Liferayn kantaan jo tehdyt muutokset, samoin kuin palvelurajapinnan kautta tehdyt muutokset. Nämä liittyvät tapauksiin, jossa on useampi tietokantoihin kohdistuva käsky, joiden on toimittava kokonaisuutena tai peruttava kokonaan.
Kun dataa on useammassa tietokannassa, datan monistamista on vältettävä. Tämä tarkoittaa sitä, että eri lähteistä tulevaa dataa joudutaan yhdistelemään portletissa. Käyttöliittymän toiminta puolestaan yksinkertaistuu, kun tarvittava dataa tuodaan palvelimelta jo valmiiksi käyttöliittymän tarvitsemissa tietorakenteissa. Näin Java-koodia lisäämällä voidaan vähentää Javasript-koodin määrää, mikä on seppien mieleen. On tärkeää havaita tämä Java-portletkoodin tehtävä, se on kuin sovituspala palvelurajapinnan ja käyttöliittymän välissä.
On myös mahdollista käyttää vain Liferayn kantaa ja laajentaa sitä lisäämällä siihen tauluja. Laajennetun tietokannan käyttö tehdään tavallisesti Liferayn ServiceBuilder-välineellä (SB). Sepät eivät suosittele tätä tapaa, vaikka tässä on etujakin: on vain yksi tietokanta, transaktioiden hallinta kohdistuu yhteen kantaan ja Liferayn oma SB on käytössä.
Yhden tietokannan ja yhden palvelimen käytössä on kuitenkin etuja painavampia ongelmia, niitä ovat ainakin:
– ServiceBuilderin käyttö on hankalaa, ja vaatii monimutkaisissa tapauksissa likimain erityisosaamista. Palvelujen toteuttaminen on huomattavasti helpompaa, kun ne tekee Liferaysta riippumattomaksi uudenaikaisilla välineillä. Tämä riippumattomuus on merkittävä tekijä. Riippumatonta palvelurajapintaa voivat muutkin sovellukset käyttää vapaasti.
– Tämä ratkaisu ei kuitenkaan tepsi kaikkiin tapauksiin. Usein on pakko käyttää ulkopuolisia tietolähteitä ja palvelimia.
– Kun toiminta jaetaan kahdelle palvelimelle (ja on edelleen helpommin jaettavissa edelleen useammalle), voidaan hallita suurempaa palvelimien kuormitusta. Tämä kuormituksen jakaminen on suuren käyttökuormituksen kohteena olevien sovellusten suhteen välttämätöntä.
On järkevää käyttää palvelurajapinnassa RESTful-palveluja SOAP-palvelujen sijasta, jos tämä ylipäänsä on valittavissa. RESTfulissa suosituin datatyyppi on JSON, joka on nimensä mukaisesti Javascriptin oma datatyyppi. SOAPin käyttämä XML-formaatissa oleva data on joko portletluokassa muutettava JSONiksi tai vietävä Javascripille XML:na. Vaikka näin voidaan ongelmittakin tehdä, se on monimutkaisempi ratkaisu. Yksinkertaisuus on jälleen kerran seppien suositus.
JSON on hyvin joustava dynaaminen tietotyyppi, yksittäisiä kenttiä tai tietueita on helppo lisätä. Tämä sopii erityisen hyvin portletteihin, jos niissä joutuu yhdistelmään dataa useasta lähteestä, Liferayn kannan luokista ja palveluiden välityksellä saatavasta datasta. Angular-kirjastolle JSON on suorastaan pakollinen dataformaatti, ja jQuerylle JSON käy myös luontevimmin.
Portletluokan Ajax-tehtävien pilkkomista edelleen aliluokkiin käytetään silloin kun Ajax-kutsun käsittelykoodi sisältää monta käskyä. ServeResource-metodin luettavuutta parantaa yhtenäinen menettely kaikille Ajax-tehtäville. Perinteinen rakenne, syöteparametrien kerääminen, aliluokan kutsu ja paluuarvon saaminen toimii tässä hyvin. Aliluokan rajapinta kannattaa tässäkin tehdä portleteista ja Liferaysta riippumattomaksi.
Huomion arvoista on, että SPA-portletluokan rakenne ei välttämättä vaadi SPA-käyttöliittymiä. Myös tapauksissa, joissa JSP-sivut ladataan palvelimelta perinteisin menoin, voidaan käyttää likimain tätä porlettimallia. Tämä vaatii kuitenkin vähintään portletin doView-koodin kirjoittamista, koska sivunvaihto hoidetaan palvelinpään koodissa. Ero on se, että data haetaan sivun latauduttua Ajax-toiminnoilla, joita sivun latauduttua kutsutaan javascriptin window.onload -eventissa. Luonnollisesti myös muu datan haku hoidetaan tällöin Ajaxilla käyttöliittymälle.
Seuraavissa blogeissa tarkastellaan Angular-SPA-portletin clientpuolen toteutuksen yksityiskohtia.
