Portlettien arkkitehtuuri

Samalla portletilla voi olla useita JSP-sivuja, joita ladataan tarpeen mukaan samaan portlettikehykseen. Vaikka tämä vaatii palvelimella sivun lataamisen, päivitys kohdistuu vain kyseiseen kehykseen. Sivunvaihto on kuitenkin raskas toiminto verkkoliikenteen kannalta ja on raskas toimenpide myös toteuttaa.

Kun portletsivua ladataan ensimmäisen kerran, portaalialusta kutsuu portletin sisäänrakennettuja metodeja palvelimella järjestyksessä: render -> doDispatch -> doView -> JSP-sivun Java-koodi, eli skripletit. Näistä metodeista toteutetaan yleensä vain doView-metodi, muuten käytetään yläluokan valmista versiota metodista. Edellä oleva merkintä (->) ei tarkoita perättäisiä metodikutsuja, vaan sitä, että edellinen metodi kutsuu seuraavaa. Tämä tarkoittaa esim. sitä, että rendermetodin loppu toteutetaan ketjussa viimeiseksi.

Kun portlettisivua kehyksissä vaihdetaan, toiminto monimutkaistuu. Nyt ensimmäisenä kutsutaan processAction-metodia. ProcessAction on oletusnimi, näitä actionmetodeja voi olla useita, tyypillisesti yksi per JSP-tiedosto. Portlettien yleinen MVC-malli on, että actionmetodit muodostavat sivun sovelluslogiikan. Toki actionmetodin kutsu voidaan edelleen ohittaa sivunvaihdossa.

Sivua uudelleen ladattaessa järjestys on siis (tässä 1. ja 2. tarkoittavat peräkkäisiä metodikutsuja):
1. processAction (tai yleisemmin jokin actionmetodi).
2. render -> doDispatch -> doView -> JSP-sivun Java-koodi (sivua ladattaessa siis pelkästään tämä).

Ongelmana on, miten sovelluslogiikkaa kutsutaan sivua ladatattaessa, kun actionmetodi sivuutetaan. Tähän ongelmaan on useita ratkaisumalleja, mutta mikään niistä ei ole täysin tyydyttävä, esimerkiksi:
1. Tehdään tyhjä aloitussivu, joka ladataan ensiksi (ilman actionmetodia) ja tämä lataa heti varsinaisen sivun (jossa actionmetodia aluksi kutsutaan). Tämä on monimutkainen ratkaisu.
2. Sijoitetaan businesslogiikan käyttö aina kutsuttavaan doView-metodiin (kuten servletissa doPost/doGet metodeihin). Tämä on portletin perinteisen arkkitehtuurimallin vastaista.
3. Sijoiteaan ainakin osa sovelluslogiikasta JSP-sivun skripletteihin. Tämä taas aiheuttaa helposti käyttöliittymän ja kontrollerin toimintojen sekoittumisen.
Käytännössä ongelmaan on etsittävä toimiva ratkaisu tapauskohtaisesti. Tilannetta helpottaa, jos varsinainen sovelluslogiikka sijoitetaan erillisiin luokkiin.

Ajaxin käyttö puolestaan rikkoo selkeän logiikan kaikissa alunperin palvelinpäähän tehdyissä frameworkeissa. Niissä selkeyden voi lähes mitata sillä, miten hyvin ne pystyvät piilottamaan Ajax-toiminnallisuuden sovelluskohtaiselta toteutukselta. Tästä on Javan JSF-teknologia hyvä esimerkki, siinä Ajaxin piilotus on tehty varsin taitavasti.

Ajax-toiminnot monimutkaistavat portletin logiikkaa huomattavasti. Dataa haetaan kahta tietä, sivua ladattaessa ja Ajax-toiminnoilla. Riippumatta siitä, kumpaa tapaa pitää helpompana, on molempien käyttäminen monimutkaisempaa kuin vain toisen käyttäminen. Kun Ajaxia on käytännössä pakko käyttää, voiko vain sillä tulla toimeen? Kyllä voi, sivun alustusdata voidaan aina hakea vaikkapa Javascriptin window.onload -tapahtumankäsittelijässä.

Mikäli halutaan tehdä pelkästään Ajaxiin tukeutuva portletti, joudutaan miettimään, miten monisivuinen SPA toteutetaan. Tämä tarkoittaa, että mitään sivun lataamista – paitsi ensimmäisellä kerralla – ei tarvita lainkaan. Uusi sivu ladataan portletraameihin ilman serverikieppiä, selaimessa. Portletkoodissa täytyy koodata vain serveResource-metodi, joka käsittelee kaikki JSP-sivun Ajax-kutsut. Portaalisivun ominaisuuksien (koostuu useista portleteista) takia ei voida kutsua suoraan palveluita (services) ulkopuolelta. ServeResourcesta voidaan kyllä edelleen kutsua ulkopuolisia palvelukutsuja tai käyttää portletin valmiskoodia suoraan (Liferay APIn kautta).

Ajaxin käytön seurauksena on Javascript-koodin määrän selvä kasvu. Tämän takia myös Javascript-kirjastojen (MVC-frameworkit, komponenttikirjastot) tarve kasvaa, koska ne pienentävät sovelluskohtaisen koodin määrää oleellisesti.

ServeResource-metodi on Ajax-kutsujen yhteydessä MVC:n model tai paremminkin sen ylempi palvelurajapinta, jossa sen edelleen kutsumien palvelujen tarjoamat datarakenteet voidaan valmiiksi koostaa juuri kyseisen käyttöliittymän tarpeisiin sopiviksi. Tämä yksinkertaistaa käyttöliittymän Javascript-koodia merkittävästi.