RAZVOJ ENOSTRANSKIH SPLETNIH APLIKACIJ S PORTALNO PLATFORMO LIFERAY

Transcription

1 FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO Borut Radi RAZVOJ ENOSTRANSKIH SPLETNIH APLIKACIJ S PORTALNO PLATFORMO LIFERAY Diplomsko delo Maribor, julij 2015

2

3 Fakulteta za elektrotehniko, računalništvo in informatiko Smetanova ulica Maribor, Slovenija RAZVOJ ENOSTRANSKIH SPLETNIH APLIKACIJ S PORTALNO PLATFORMO LIFERAY Diplomsko delo Študentka: Študijski program: Smer: Mentor: Lektorica: Borut Radi Visokošolski študijski program Računalništvo in informatika Informatika red. prof. dr. Marjan Heričko, univ. dipl. inž. Cirila Šramel, prof. slovenščine Maribor, julij 2015

4

5

6

7 ZAHVALA Zahvaljujem se mentorju red. prof. dr. Marjanu Heričku, univ. dipl. inž., za pomoč in strokovno svetovanje pri nastajanju tega diplomskega dela. Zahvala gre tudi podjetju Mikropis ter sodelavcem za razumevanje in podporo v času študija. Nazadnje se zahvaljujem tudi svojim staršem, družini za vso pomoč, vzpodbudne besede ter razumevanje, ki ste ga imeli do mene v času študija. i

8

9 Razvoj enostranskih spletnih aplikacij s portalno platformo Liferay Ključne besede: enostranske spletne aplikacije, portalna rešitev, spletne tehnologije, odzivno oblikovanje, platforma Liferay UDK: (043.2) Povzetek V diplomskem delu smo predstavili enostranske spletne aplikacije ter tehnologije, ki omogočajo izdelavo le-teh. Gre za skupek tehnologij HTML, CSS, JavaScript in AJAX, kateri deluje v povezavi s strežnikom. Osredotočili smo se na razvoj enostranskih spletnih aplikacij na eni izmed vodilnih rešitev za spletne portale, imenovani Liferay. Razvili smo enostransko spletno aplikacijo za dodeljevanje opravil na urnik uporabnika portala. Opisali smo uporabljene tehnologije in pristope ter proces vzpostavitve in prilagoditve portala LifeRay ter tudi izzive, na katere smo naleteli pri izgradnji rešitve. iii

10 Developing a single page web application on Liferay portal platform Key words: single page web application, portal solution, web technologies, responsive design, Liferay platform UDK: (043.2) Abstract The diploma presents single page web applications and technologies that enable the development thereof. It is a set of technologies: HTML, CSS, JavaScript, AJAX, which works in conjunction with the server. We focus on the development of a single page web application based on one of the leading solution for web portals Liferay. Practically, we have developed a single page web application to unilaterally assign tasks to schedule for each user. We described technologies, challenges and the process of development of the single page web application. iv

11 KAZALO 1 UVOD ENOSTRANSKE SPLETNE APLIKACIJE Predstavitev koncepta in zgodovina razvoja Pomembne prednosti in slabosti Arhitektura Delovanje enostranskih spletnih aplikacij Tehnologije in pristop k razvoju enostranskih spletnih aplikacij Testiranje enostranskih spletnih aplikacij Podatkovni model Uporabniški vmesnik s testnimi podatki Podatkovni model brez uporabniškega vmesnika z dejanskimi podatki Uporabniški vmesnik z realnimi podatki PORTALNA PLATFORMA LIFERAY Portalna rešitev Liferay Verzioniranje in proces izdaje portalne platforme Liferay Trgovina Liferay Sodelovanje in prispevanje pri razvoju platforme Liferay Izdelava in prilagoditev komponent platforme Liferay Razširitev obstoječih funkcij Teme Razporeditev vsebine Razširitve z lastnimi funkcijami Spreminjanje izvorne kode Portlet RAZVOJ ENOSTRANSKIH SPLETNIH APLIKACIJ S PORTALOM LIFERAY Ogrodja JavaScript Vzorca MVC in DAO Sodobni uporabniški vmesniki in odzivno oblikovanje v

12 4.4 Pristopi k odzivnem oblikovanju Prilagodljiva postavitev Prilagodljivost slik Poizvedba CSS Media Query Jezik JavaScript Izzivi pri gradnji enostranskih spletnih aplikacij Zagotavljanje delovanja običajnih brskalnikovih funkcij Začetno nalaganje strani (JavaScript, HTML, CSS) Optimizacija strani za iskalnike (SEO) PRIMER PRAKTIČNE REŠITVE Priprava in namestitev portala Liferay Vzpostavitev okolja in prilagoditev platforme Liferay za ESA Implementacija enostranske spletne aplikacije za dodajanje opravil na koledar uporabnika Implementacija prijave uporabnika na spletni portal Implementacija izpisa seznama vadb, katere ta uporabnik možnost vpogleda Implementacija dodeljevanja vadbe na koledar določenega uporabnika SKLEP VIRI vi

13 KAZALO SLIK Slika 2.1: Arhitektura ESA... 6 Slika 2.2: Življenjski cikel statične in enostranske spletne aplikacije... 8 Slika 2.3: Testiranje podatkovnega modela...11 Slika 2.4: Testiranje uporabniškega vmesnika s testnimi podatki...11 Slika 2.5: Testiranje podatkovnega modela brez uporabniškega vmesnika s pravimi podatki...12 Slika 2.6: Celostno ali integracijsko testiranje podatkovnega modela in uporabniškega vmesnika s pravimi podatki...13 Slika 3.1: Izgradnja portalne rešitve z uporabo gradnikov, ki so na voljo na platformi Liferay...15 Slika 3.2: Portalna rešitev Liferay lahko služi tudi kot hramba za dokumente...15 Slika 3.3: Integracija različnih spletnih mest v eno samo portalno rešitev...16 Slika 3.4: Spletno mesto za sodelovanje posameznikov ali skupin na projektih znotraj portalne rešitve...17 Slika 3.5: Uporaba standarda OpenSocial omogoča uporabnikom nadgradnjo aplikacij z družbeno identiteto in funkcionalnostmi družbenih omrežji...18 Slika 3.6: Arhitekture platforme Liferay...19 Slika 3.7: Struktura portalov, uporabnikov, spletnih strani na platformi Liferay...19 Slika 3.8: Namestitev dodatkov SDK na spletni strežnik...24 Slika 3.9: Osnovne razporeditve vsebine...26 Slika 3.10: Namestitev razširitev v platformo Liferay...26 Slika 3.11: Spletna aplikacija na portalu...28 Slika 3.12: Življenjski cikel zahtevkov na portletu...28 Slika 3.13: Implementacija portleta po JSR Slika 3.14: Implementacija portleta po JSR Slika 4.1: Povezava med poslovno logiko in podatkovno bazo z DAO razredi...32 Slika 4.2: Povezava komponent MVC med sabo in z uporabnikom...33 Slika 4.3: Primer odzivnega oblikovanja...34 Slika 4.4: Primerjava definiranja elementov fiksnega in tekočega oblikovanja...35 Slika 4.5: Indeksiranja spletne strani z uporabo parametrov»_escaped_fragment_=«..38 Slika 5.1: Diagram poteka...40 Slika 5.2: Datotečna struktura znotraj korenskega imenika Liferay...41 Slika 5.3: Nivoji strežniškega ogrodja in osnovni razredi...44 vii

14 Slika 5.4: Zaslonska slika prijave na portal Slika 5.5: Del izvorne kode za izris obrazca za prijavo Slika 5.6: Metoda render, ki se izvede ob inicialnem nalaganju pogleda Slika 5.7: Del izvorne kode na strežniški strani, servisna akcija za prijavo Slika 5.8: Primer Ajax klica akcije_dologin na strani odjemalca, ki vrača JSON Slika 5.9: Zaslonska slika izpisa seznama vadb uporabniku iz podatkovne baze Slika 5.10: Del kode view.jsp, ki skrbi za ustrezen prikaz strani na brskalniku Slika 5.11: Uporaba jsp elementa/oznake»workout«, s pomočjo katerega prikažemo uporabniku seznam vadb Slika 5.12: Privzeta akcija na strani upravitelja za pogled Slika 5.13: Servis na strežniški strani za pridobitev podatkov iz baze Slika 5.14: Pridobitev podatkov na podatkovnem nivoju in vrnitev rezultatov poizvedbe s pomočjo tovarne objektov Slika 5.15: Podroben prikaz podatkov posamezne vadbe Slika 5.16: Pojavno okno za izbiro uporabnika, ki mu želimo dodeliti vadbo Slika 5.17: Metoda na strani odjemalca pokliče servis za dodelitve vadbe uporabniku Slika 5.18: Storitev na strežniku za dostop do akcije na podatkovnem nivoju Slika 5.19: Klic bazne procedure za posodobitev ustreznih tabel viii

15 SLOVAR UPORABLJENIH KRATIC AJAX API CSS DOM EL ESA HTML JS JSF JSON JSP MVC MV MVW OSS REST SPA URL WAR WCMS XHR XML Asynchronous JavaScript and XML Application Programming Interface Cascading Style Sheets Document Object Model Expression Language Enostranske spletne aplikacije Hyper Text Markup Language JavaScript JavaServer Faces JavaScript Object Notation JavaServer Page Model View Controller Model View Model View Whatever Odzivne spletne strani Representational State Transfer Single Page Application Uniform Resource Locator Web application Archive Web Content Management System XML http Request Extensible Markup Language ix

16

17 1 UVOD V današnjem svetu si skoraj ne znamo več predstavljati dneva brez dostopa do svetovnega spleta. Na spletu najdemo skoraj vse potrebne informacije za vsakdanje življenje. Z razcvetom sodobnih, vse bolj zmogljivih, mobilnih naprav ter razvojem tehnologij, ki omogočajo hitrejše prenose podatkov, se kaže trend, da ljudje na vsakem koraku dostopamo do informacij na spletu. Skladno s tem je v porastu razvoj spletnih ter mobilnih rešitev, razen domorodnih mobilnih aplikacij, pa je veliko zanimanja za rešitve, ki pravilno delujejo na različnih napravah z različnimi operacijskimi sistemi, sistemsko arhitekturo, strojno opremo itd., seveda z razvojem ene same rešitve. Z zatonom klasičnih spletnih strani se je povečalo število spletnih portalov. Spletni portali v osnovi omogočajo uporabniku poosebljenje spletne strani ter vsebin. Istočasno spletni portali omogočajo dostop do točno določenih vsebinskih informacij in združujejo le-te iz različnih virov. Uspešnost oziroma uporabnost posameznega portala je v največji meri odvisna od zagotavljanja ažurnih in natančnih informacij, ki jih le-ta podaja. Z novo generacijo spletnih aplikacij se vse bolj postavlja v ospredje uporabniška izkušnja, katera narekuje uporabniškemu vmesniku obliko, prilagodljivost, mobilnost ter skalabilnost. Pomembnost uporabniške izkušnje se kaže tudi tako, da je le-ta včasih uporabnikom celo bolj pomembna kot sama vsebina. Iz tega sledi, da so se tako tehnologije kot arhitekture končnih aplikacij prilagodile temu razmišljanju. Ena izmed bolj pomembnih prilagoditev je tudi odzivno oblikovanje, ki ima velik pomen tudi pri enostranskih spletnih aplikacijah (ESA). Kombinacija odzivnega oblikovanja in enostranskih spletnih aplikacij ne samo, da izboljša uporabniško izkušnjo, pač pa omogoči tudi prilagajanje napravi, s čimer zagotovimo pravilni prikaz spletne vsebine. Enostranske spletne aplikacije zagotavljajo odzivnost namizne aplikacije in prenosljivost ter dostopnost spletne aplikacije. Dostopne so iz vseh naprav, ki imajo sodobne spletne brskalnike [1]. V diplomskem delu bomo spoznali in predstavili osnovne značilnosti spletne portalne platforme Liferay ter raziskali možnosti njene uporabe pri razvoju t. i. enostranskih spletnih aplikacij (angl. Single Page Applications). Pridobljeno znanje bomo uporabili pri razvoju informacijske rešitve 24alife Fitnes in tako ovrednotili posamezne tehnične pristope. V drugem poglavju bomo opisali osnovne značilnosti enostranskih spletnih aplikacij (ESA) 1

18 ter z njimi povezane pristope in spletne tehnologije, na katerih temelji razvoj sodobnih spletnih rešitev po konceptu ESA. Poudarili bomo tudi pomen odzivne zasnove strani (angl. responsive design). Na kratko bomo preleteli zgodovino ESA ter razloge, zakaj so za svojo uveljavitev potrebovale kar nekaj časa. V tretjem poglavju bomo predstavili ključne značilnosti in funkcionalnosti portalne platforme Liferay. Govorili bomo tudi o portalni tehnologiji Portlet ter arhitekturnem vzorcu MVC (angl. Model View Controller). Prav tako bomo predstavili osnovno strukturo platforme Liferay. Izzive pri razvoju enostranskih spletnih aplikacij na osnovi portalne platforme Liferay podaja četrto poglavje. Opisali bomo lastne rešitve in razširitve, ki smo jih pri tem uporabili. V petem poglavju bo predstavljena zasnova rešitve 24alife Fitnes ter bodo na primerih prikazani posamezni tehnični pristopi za implementacijo enostranskih spletnih aplikacij. Delo zaključujemo s povzetkom ugotovitev in identificiranih izzivov ter s smernicami za nadaljnje delo. 2

19 2 ENOSTRANSKE SPLETNE APLIKACIJE 2.1 Predstavitev koncepta in zgodovina razvoja Glavna značilnost enostranske spletne aplikacije je njen prikaz, saj je prikazana kot spletna stran znotraj brskalnika, katera pa se med uporabo ne osvežuje, ker se v celoti izvaja znotraj te strani. Ob prvem zagonu aplikacije se vsa programska koda, potrebna za delovanje, prenese na stran odjemalca. Med izvajanjem aplikacije se prenašajo zgolj viri in podatki. Ti prenosi se prožijo kot posledica uporabnikove akcije. Če povzamemo, pri ESA se vse funkcionalnosti in poslovna logika prenesejo na odjemalca oziroma na njegov brskalnik. Strežnik tako preko storitev skrbi za pošiljanje potrebnih podatkov odjemalcu. S tem preprečimo, da bi akcije uporabnika sprožile osveževanja celotne strani, razen ob začetnem nalaganju, prav tako se izognemo motečim preusmeritvam na drugi strani. Enostranska spletna aplikacija izboljša uporabniško izkušnjo glede na klasično večstransko spletno aplikacijo, kjer so prisotne preusmeritve in ponovno nalaganje celotne strani. Podatki se običajno prenašajo preko storitev REST (Representational State Transfer) v formatu JSON (JavaScript Object Notation). Pri klasični večstranski spletni strani se skoraj vedno naložijo tudi deli strani, ki so vseskozi enaki, npr. meniji oziroma glava strani. Z ESA dosežemo predvsem bolj»tekočo«uporabniško izkušnjo. Takšne spletne aplikacije temeljijo na tehnologijah HTML, CSS, JavaScript in AJAX [2]. Ravno tako se pri tovrstnih aplikacijah poudarja pomen vzorca MVC (Model View Controler.) Za razvoj enostranske spletne aplikacije se odločimo na podlagi tehničnih in vsebinskih zahtev oziroma omejitev. Z njihovo uporabo izboljšamo uporabniško izkušnjo, pohitrimo delovanje ter povečamo mobilnost in prenosljivost. Ne glede na to, da pri začetnem nalaganju takšnih aplikacij porabimo nekaj več časa, saj na odjemalca prenesemo več programske kode, kot je to potrebno v danem trenutku, pozneje tako prihranimo na pasovni širini, saj iz strežniške strani prenašamo zgolj in samo podatke. To najbolj opazimo takrat, ko se enostranske spletne aplikacije izvajajo na mobilnih napravah. Za razvoj tovrstnih aplikacij so bila razvita ogrodja, ki olajšajo razvoj. Verjetno ni treba posebej omenjati, da moramo biti pri izbiri ogrodja še posebej pazljivi. Ogrodje vpeljuje red in strukturo v predstavitveni nivo in spodbuja razvoj po modulih [3]. 3

20 O»enostranski spletni aplikaciji«je bilo prvič govora že davnega leta 2003 [2], eden izmed prvih konceptov pa se pojavil leta Že takrat je bila ključna težava predvsem v skriptnem jeziku JavaScript, saj ta še ni podpiral naprednih funkcionalnosti v brskalnikih, ki jih takšne aplikacije za svoje delovanje zahtevajo. Spletne strani, ki spominjajo na sodobne enostranske aplikacije, dejansko obstajajo od sredine devetdesetih let. Koncept ESA je nastal kot posledica dveh tehnologij, uvedenih leta 1995 in 1996, in sicer Jave Applets in Flasha. V tem času so bili apleti priljubljeni za uporabo na spletu, predvsem pri procesorsko zahtevnih ali grafičnih procesih, npr. pri vizualizaciji podatkov ali grafičnih animacijah. V tistem času je bil v porastu trend uporabe tehnologije Macromedia Flash, saj so jo uporabljale najbolj napredne in za tisti čas najboljše spletne strani. Znan je primer strani, ki so uporabljale Flash za animirane prehode med stranmi in zvočne učinke. Večina takšnih spletni strani je že takrat povzemala koncept enostranskih spletni aplikacij, kjer se je celotna vsebina prenesla vnaprej. Tako so v teh primerih brskalniki delovali kot posredniki zahtev do drugih platform in dodatkov, ki so seveda morali biti vnaprej nameščeni. Takšne spletne strani bi lahko označili kot prednike enostranskih spletnih aplikacij. Razen nekaj manjših izjem se je na prelomu tisočletja o spletnem programiranju razmišljalo še na stari, konvencionalen način. Stran je tisto, kar spletni strežnik pošlje na naš brskalnik in je enakovredno temu, kar vidimo v danem trenutku znotraj brskalnika. Zaradi pomanjkanja standardov in dogovorov med izdelovalci spletnih brskalnikov o delovanju skriptnega jezika JavaScript je bil razvoj na strani odjemalca zelo omejen, in sicer vse do leta 2005, ko se je začela revolucija spletnega programiranja. V začetku leta 2000 je takrat malo znan API, imenovan XMLHttpRequest (krajše XHR), našel svojo pot v spletne brskalnike. Ponudil je programski način za pošiljanje zahteve HTTP do spletnih strežnikov in znal sprejeti odziv. Čeprav ime namiguje, da je XML predvidena oblika za izmenjavo podatkov, temu ni tako, saj nudi podporo za številne vrste podatkov, med drugim tudi JSON in HTML. S tehniko, imenovano AJAX, pa se je razvijalcem odprl povsem nov načina razmišljanja o spletnem programiranju. AJAX ni programski jezik, gre za skupek tehnologij (Asinhroni JavaScript + XML). Tako so z uporabo te tehnike leta 2005 nastale prve komercialne in širše poznane spletne aplikacije, kot so npr. Gmail, Google Groups, Google Suggest in Google Maps, katerim pravimo enostranske spletne aplikacije [9]. 2.2 Pomembne prednosti in slabosti Popolnoma razumljivo je, da imajo enostranske spletne aplikacije več prednosti kot 4

21 slabosti. Večkrat smo že omenili glavne prednosti enostranskih spletnih aplikacij v primerjavi s klasičnimi večstranskimi spletnimi stranmi. Uporaba koncepta enostranskih spletnih aplikacij je pravilna odločitev takrat, ko imamo zahtevo po visoko zmogljivi hitri interakciji med uporabnikom in sistemom, vsekakor pa niso primerna za uporabo, kadar imamo opravka z vsebinsko bogatimi spletnimi stranmi, kot sta na primer elektronski časopis ali blog. [4]Neizpodbitno dejstvo je, da razvoj ESA zahteva bistveno več časa za načrtovanje in oblikovanje, predvsem pa je zahtevnejša sama implementacija, kar ocenjujemo kot glavni razlog, zakaj še vedno prevladujejo klasične spletne aplikacije. Prednosti enostranskih spletnih aplikacij [1]: izboljšana uporabniška izkušnja, hitrejše delovanje uporabniškega vmesnika, primerno tudi za izdelavo mobilnih aplikacij (HTML5), delovanje tudi brez spletne povezave, uporabniški vmesnik je samo odjemalec, predstavitveni nivo lahko vsebuje poslovno logiko, delovanje na različnih platformah, aplikacija spreminja samo svoje stanje, aplikacija se obnaša kot namizna aplikacija. Slabosti uporabe pristopa ESA pri razvoju spletnih aplikacij [1]: težavnejša optimizacija (indeksiranje) podstrani za iskalnike SEO (angl. Search engine optimization), zahtevnejša implementacija za razvijalce, za svoje delovanje potrebujejo sodobne brskalnike, ki podpirajo napredne JavaScript funkcije. 2.3 Arhitektura Razvoj tradicionalnih spletnih aplikacij vključuje večji del pisanja kode za strežniški del, leta pa po zaključeni obdelavi podatkov spletnemu brskalniku posreduje dokument HTML, ki se uporablja za prikaz. Še nedavno je bilo to smiselno, saj brskalniki niso imeli enotnega standarda podprtih funkcij za jezik JavaScript in je bilo generiranje HTML na strežniški strani edino smiselno. Sodobne spletne aplikacije pa so sestavljene iz večdelnih uporabniških vmesnikov. To bi v praksi pomenilo ogromno vmesnih stanj, ki bi se ustvarile 5

22 na strežniškem delu in bi se morale prenesti na odjemalca. Kot rešitev te težave se je izkazala selitev vse več funkcij in poslovne logike na stran odjemalca oziroma spletni brskalnik. Tako se lahko katerikoli del uporabniškega vmesnika izriše oz. pridobi brez komunikacije s strežnikom [4]. Slika 2.1: Arhitektura ESA [3] Predpogoj za to je ločevanje podatkov od njihove predstavitve. Tako nivo modela skrbi za podatke, pogled pa bere iz modela (arhitektura MV). Med njima stoji vezni člen, ki glede na uporabnikove akcije pridobiva podatke in sproži ustrezen izris podatkov. Podatki se na podlagi predloge pretvorijo v HTML, nato se posodobi DOM (angl. Document Object Model). Za povezovanje naslova URL in dejanskega pogleda pa skrbi usmerjevalnik, ki prepozna trenutno stanje ter ga naloži. Arhitekturni vzorec MVC je najpogosteje uporabljen vzorec pri implementaciji spletnih strani. Z njim ločimo podatke od predstavitve. Že sama kratica MVC pove, da je sestavljen iz treh komponent. Model (Model) je komponenta, ki skrbi za prenos podatkov, mnogokrat pa vsebuje tudi poslovno logiko. Pogled (View) skrbi za prikaz podatkov, ki jih dobimo iz modela, navadno kar v 6

23 obliki HTML. Kontroler (Controler) pa skrbi za uskladitev pogleda s samim modelom, glede na spremembo modela. Enostranske spletne aplikacije temeljijo na vzorcu MVC, s čimer si olajšamo razvoj ter testiranje. Arhitekturni vzorec MVC poudarja šibko sklopljenost modulov oziroma komponent. Sodobni uporabniški vmesniki vsebujejo tudi zunanje specifične komponente z namenskimi vlogami (npr. za izris grafa, prikaz menija itd.). Le-te so popolnoma neodvisne in same skrbijo za svoje dogodke. Takšne komponente imajo javno izpostavljene vmesnike (API), s katerimi krmilimo delovanje le-te. Komunikacija s strežnikom poteka s pomočjo klicev AJAX, običajno pa se podatki prenašajo v formatu JSON (angl. JavaScript Object Notation). [6] 2.4 Delovanje enostranskih spletnih aplikacij V primerjavi s klasičnimi spletnimi aplikacijami, kjer se koda izvaja na strežniški strani in vedno znova prenaša na odjemalčevo stran, se pri enostranskih spletnih aplikacijah koda izvaja na strani odjemalca, prenašajo se zgolj podatki, potrebni za prikaz. S tem tudi preformančno delno razbremenimo strežnik. Kodo na odjemalčevi strani razvijamo s skriptnim jezikom JavaScript, dostikrat pa se uporablja tudi knjižnica jquery, ki omogoča enostavnejši razvoj. Enostranske spletne aplikacije stran v celoti naložijo le v prvem inicialnem ali začetnem nalaganju, v tem trenutku se na stran odjemalca prenese vsa koda in komponente (JavaScript, HTML, CSS). Po začetnem nalaganju se prikaže stran, ki vsebuje vse zgoraj opisane elemente. Od tu dalje pa se osveževanje strani izvaja parcialno oziroma delno preko zahtev XMLHttpRequest med odjemalcem in strežnikom. Pomembno vlogo pri osveževanju ima tudi AJAX, ki omogoča asinhrono komunikacijo v ozadju, brez da bi uporabnik to občutil ali zaznal. JavaScript aplikacija na strani odjemalca pa poskrbi, da se vsebina posodobi brez osveževanja celotne strani [1]. Na začetku so brskalniki veljali za lahke odjemalce, katerih primarna naloga je bila prikazovanje dokumentov, današnji brskalniki pa se postavljajo v drugačno vlogo in postajajo vedno bolj zmogljivi. Slika 2.2 prikazuje primerjavo med življenjskim ciklom statične spletne strani v primerjavi z enostransko spletno aplikacijo. 7

24 Slika 2.2: Življenjski cikel statične in enostranske spletne aplikacije [6] Enostranske spletne aplikacije uporabljajo in menjujejo stanja aplikacije, zato lahko rečemo, da aplikacija prehaja med različnimi stanji. Pri nalaganju začetne spletne strani se strežnik postavlja v vlogo spletnega strežnika, pri nadaljnjem delu in nalaganju vsebine pa prevzame vlogo storitve, ki se odziva na klice [1]. Sodobni spletni brskalniki so osnova za uporabo in pravilno delovanje enostranskih spletnih aplikacij. Razlog tiči predvsem v tem, da so še nedavno bile velike razlike med brskalniki, njihova zmogljivosti procesiranja JavaScripta zelo slaba in omejena. Ker se z razvojem enostranskih spletnih aplikacij povečuje količina kode JavaScript, je treba biti še posebej pozoren pri strukturiranju te kode. Priporoča se uporaba knjižnic, ki omogočajo reševanje določenih težav z dosti manj kode, z njihovo uporabo pa zmanjšamo možnost napak zaradi razlik med brskalniki. 2.5 Tehnologije in pristop k razvoju enostranskih spletnih aplikacij Obstaja veliko tehnik, ki brskalniku omogočajo, da je stran prikazana tudi takrat, ko aplikacija komunicira s strežnikom [2]. 8

25 Ogrodja JavaScript, kot so Angular.js in React so prevzela načela ESA in vpeljujejo red ter strukturo v kodo JavaScript. Skrbijo za predstavitveni nivo aplikacije in komunikacijo s strežnikom. Zgrajena so na dobrih praksah s poudarkom na modularnem razvoju. Ogrodja poenostavljajo razvoj enostranskih spletnih aplikacij, saj so osnovne funkcionalnosti že implementirane in avtomatizirane. Lahko pa omogočajo še precej več: nalaganje in usmerjanje za poglede, prikaz podatkov glede na predloge, dvosmerno povezavo med podatki in pogledom, podporo za shranjevanje podatkov znotraj brskalnika itd. [7] AJAX (angl. Asynchronous JavaScript and XML) je trenutno najbolj popularna tehnika. Običajno uporablja JavaScript objekt XMLHttpRequest, obstajajo pa še drugi pristopi, npr. uporaba okna IFRAME ali elementa HTML script. Za lažje delo s klici AJAX je najboljše uporabiti katero izmed knjižnic JavaScript (npr. jquery), saj poenotijo delovanje na brskalnikih. Asinhroni klici na strežnik se lahko izvajajo tudi s pomočjo vtičnikov, npr. Silverlight, Flash, HTML5 Socket ali Java apletov. Strežniki običajno vračajo odgovore oz. podatke v obliki JSON in XML ali dokumentov HTML. V primeru, ko je odgovor tipa HTML, je treba na strani odjemalca s pomočjo JavaScript-a posodobiti DOM. Če pa je odgovor v obliki podatka, ga je treba obdelati in s pomočjo predlog pretvoriti v HTML, potem pa posodobiti še model DOM. Tanka strežniška arhitektura ESA premika logiko iz strežnika na odjemalca. To pomeni, da strežniki vedno pogosteje postajajo podatkovni programski vmesniki oz. spletni servisi. Ta arhitekturni premik se imenuje tanka strežniška arhitektura in naj bi zmanjšal kompleksnost celotnega sistema. Debela strežniška arhitektura ohranja stanje v pomnilniku za odjemalca. Tako strežnik ob vsakem zahtevku odgovori z vsemi spremembami v obliki HTML in/ali JavaScript. Hkrati pa se posodobi tudi stanje odjemalca v pomnilniku na strežniku. Večina logike in izrisa je izvedenega na strežniški strani. Strežnik do neke mere posnema brskalnik, ko se odziva na dogodke in posodablja stanje odjemalca, ki se potem avtomatsko prenese na odjemalca. Takšen pristop poenostavlja razvoj (aplikacija je v celoti implementirana na strežniku, ni potrebe po dodatni komunikaciji z odjemalcem, saj so podatki in stanje uporabniškega vmesnika zapisani v istem pomnilniku), vendar zahteva zmogljivejše strežnike. 9

26 Pri debeli strežniški arhitekturi brez stanja odjemalec pošilja stanje na strežnik, običajno s pomočjo AJAX-a, kjer se rekonstruira in generira odgovor na zahtevo. Takšen odgovor odjemalca običajno postavi na novo stanje preko spremembe modela DOM. Ta način zahteva prenos večjih količin podatkov na strežnik in zmogljivejše strežnike za rekonstrukcijo stanja odjemalca. Prednost je, da je takšna arhitektura bolj razširljiva, saj je mogoče posamezne zahteve AJAX preusmeriti na različne strežnike. 2.6 Testiranje enostranskih spletnih aplikacij Testiranja enostranskih spletnih aplikacij se praviloma lotimo ločeno v več korakih, pri tem izvedemo vsaj štiri korake v točno določenem vrstnem redu, kot je zapisano v nadaljevanju. Kot prednost se izkaže ločeno testiranje tako uporabniškega vmesnika kot tudi podatkovnega nivoja oziroma na koncu testiranja obeh skupaj. Verjamemo, da je potrebno vseskozi testirati enako programsko kodo, če želimo zagotoviti verodostojne teste. Že pri razvoju pa je treba programsko opremo načrtovati tako, da se predvidijo konfiguracijske nastavitve, ki omogočijo hitro preklapljanje med razvojnim oziroma testnim in dejanskim produkcijskim delovanjem, brez poseganj v kodo. ESA omogočajo tudi izvedbo avtomatiziranih funkcionalnih testov aplikacije, vendar je pri tem treba posvetiti nekaj pozornosti klicem XHR, saj ne dobivamo povratne informacije v ogrodja oziroma knjižnice, s katerimi izvajamo testiranje, kdaj se je klic XHR zaključil, kot to dobimo pri realnem nalaganju spletne strani. Na tej točki pa se odprejo dodatna vprašanja, in sicer kakšni naj bodo odzivni časi in kolikšen naj bo čas, ko še pričakujemo odgovor. Zaradi takšnih in podobnih situacij se izkaže, da so avtomatski testi v primerjavi s človeškim testiranjem počasnejši. [8] Podatkovni model Pri testiranju podatkovnega modela se preverja pravilno delovanje le-tega, tak test se izvede brez uporabe spletnega brskalnika, torej brez samega uporabniškega vmesnika. Slika 2.3 prikazuje test podatkovnega modela in komponent, ki so pri tem v ospredju, to je sam model, ter pripadajoče pomožne funkcije, ki jih uporabljamo za delo s podatkovnim modelom. 10

27 Slika 2.3: Testiranje podatkovnega modela [1] Uporabniški vmesnik s testnimi podatki Pri testiranju največ pozornosti običajno posvečamo uporabniškemu vmesniku, njegovim akcijam, odzivom, izpisom, prikazu podatkov itd. Namen je, da potencialno napačno delovanje uporabniškega vmesnika zaznamo, še preden nanj pripeljemo prave podatke in s tem dodatni faktor, ki bi lahko bil krivec za napačno delovanje. Tudi v ta namen namesto dejanskih uporabljamo testne podatke, saj se v praksi takšno iskanje napak izkaže kot hitrejše in bolj učinkovito. Slika 2.4 prikazuje komponente, ki so v ospredju pri tem koraku testiranja. Slika 2.4: Testiranje uporabniškega vmesnika s testnimi podatki [1] 11

28 2.6.3 Podatkovni model brez uporabniškega vmesnika z dejanskimi podatki Naslednji korak testiranja aplikacije je preverjanje delovanja vmesnika aplikacije (klicev, protokolov, rutin). Tudi ta tip testa se izvede brez spletnega brskalnika, posledično brez uporabniškega vmesnika, s tem se izključijo morebitne napake iz tega naslova. Tu pa se za pridobivanje podatkov že uporabljajo pravi klici na spletni strežnik, posledično dejanski podatki, kar lahko vidimo na sliki 2.5. Slika 2.5: Testiranje podatkovnega modela brez uporabniškega vmesnika s pravimi podatki [1] Uporabniški vmesnik z realnimi podatki Zadnji korak testiranja združuje pravi uporabniški vmesnik z realnimi podatki. Tu prvič aplikacija v celoti nastopi na testu, s tem korakom se preverja celostno delovanje aplikacije, kar nam prikazuje slika 2.6. Praviloma se tu izkaže uspešnost testiranja predhodnih korakov, saj se tu vsi rezultati in faze prvič združijo, zato lahko ta korak imenujemo tudi integracijsko testiranje [1]. Načeloma velja pravilo, da če se napake niso pojavljale v prejšnjih korakih, tudi v tem koraku ne sme biti težav. Če pa odkrijemo napake, je treba ponoviti testiranje s pomočjo vseh prejšnjih korakov, da se določi njihov izvor. Četudi se napaka odkrije na prejšnjem koraku, se mora ponoviti faza integracijskega testiranja. 12

29 Slika 2.6: Celostno ali integracijsko testiranje podatkovnega modela in uporabniškega vmesnika s pravimi podatki [1] 13

30 3 PORTALNA PLATFORMA LIFERAY 3.1 Portalna rešitev Liferay Portal Liferay je vodilna spletna odprtokodna platforma za implementacijo spletnih aplikacij ter napredno orodje CMS za izdelovanje spletnih portalov in strani [9]. Platforma je napisana v programskem jeziku Java, združljiva pa je z večino podatkovnih baz. Nastala je leta 2000 kot rešitev za neprofitne organizacije. Danes je na voljo pod dvema licencama: Liferay Portal Community Edition je brezplačna različica pod licenco GNU in vsebuje veliko standardnih funkcionalnosti (več kot 60 potrtletov). Za razvoj in odpravo napak pa skrbi velika skupnost, ki se iz leta v leto širi, sam podatek o prenosih, ki jih je več kot mesečno, je dovolj zgovoren. Liferay Portal Enterprise Edition je plačljiva različica, ki ponuja vse funkcionalnosti odprtokodne različice. Poudarek je predvsem na tehnični pomoč, ki jo nudi ekipa razvijalcev, kateri so sami vključeni v razvoj sistema Liferay. Portalno rešitev sestavlja več pomembnih elementov, ki služijo podjetjem na več področjih. V nadaljevanju bomo opisali ključne komponente portalne rešitve Liferay. Spletna platforma LifeRay je običajno definirana kot aplikativna platforma za gradnjo spletnih strani in aplikacij. Sodobni spletni portali omogočajo uporabo naprednih funkcij, zato služijo kot odlična osnova za spletne strani in aplikacije, saj že v osnovi omogočajo [9]: prikaz različne vsebine spletne strani glede na status in pravice ter vloge uporabnika, integracijo z drugimi spletnimi stranmi, skupno rabo, upravljanje vsebin in dokumentov med različnimi uporabniki, skupinami in ekipami, prikaz in upravljanje s privatnimi in javno dostopnimi stranmi, relativno enostavno gradnjo strani z uporabo gradnikov portletov oziroma widgetov. Z uporabo tem lahko popolnoma prilagajamo videz posamezne strani. Upravljalec portala lahko spletne strani zgradi brez naprednega znanja, saj lahko le-te sestavlja z uporabo 14

31 prej opisanih gradnikov, katere pa prilagodijo razvojniki. Seveda velja omeniti odlično podporo za večjezičnost, ki jo sistem že v osnovi ponuja. Slika 3.1: Izgradnja portalne rešitve z uporabo gradnikov, ki so na voljo na platformi Liferay [9] Sistem Liferay WCM vsebuje širok nabor orodij, ki omogočajo hitro in enostavno upravljanje z vsebino ter postavitvijo strani. Moderne spletne aplikacije in strani so danes bogate z vsebino, ki se redno ažurira in dopolnjuje. Z uporabo sistema WCM omogočimo upravljanje in urejanje takšne vsebine ljudem, ki ne potrebujejo tehničnega in posebnega razvojnega znanja za delo. Orodje predvideva in omogoča nastavljanje vlog in pravic urednikom vsebin, tako se lahko na primer doseže omejevanje ali potrjevanje vsebin, preden se le-te objavijo. Ta sistem uporabljamo kot repozitorij za dokumente in vsebino na portalu. Vsaka posamezna skupnost oziroma ekipa dobi lasten prostor za knjižnico dokumentov in galerijo slik, ki sta jim na voljo. Omogočena je tudi povezava z aplikacijo Microsoft Office, kar pomeni, da se ob spremembi dokumenta na lokalnem računalniku podatki sinhronizirajo in prenesejo na portal, kar omogoča verzioniranje, zaklepanje in deljenje dokumentov med uporabniškimi skupinami in organizacijami. Slika 3.2: Portalna rešitev Liferay lahko služi tudi kot hramba za dokumente [10] 15

32 Integracijska platforma ena izmed primarnih vlog portala je integracija različnih obstoječih aplikacij in strani v poenoteno aplikacijo in s tem zagotovitev enotne uporabniške izkušnje ter videza. Informacije iz različnih virov so tako zbrane na enem mestu z enotnim videzom na eni spletni strani oziroma aplikaciji, uporabniki pa imajo glede na svoje vloge in pravice dostop do različnih vsebin. Platforma Liferay omogoča enotno prijavo SSO (angl. single sign on), kar še posebej pride do izraza tako pri agregaciji podatkov iz različnih virov kot tudi pri integraciji. Portal ima zmožnost integracije informacij zunanjih sistemov ERP ter prikaza ključnih podatkov, ki lahko imajo različen vir podatkov, na prilagojenih nadzornih ploščah, katerih naloga je prikazovanje stanja, statusov in opozoril. Slika 3.3: Integracija različnih spletnih mest v eno samo portalno rešitev [11] Podpora skupinskemu delu in sodelovanju. Portal Liferay omogoča kreiranje skupin in skupnosti ter spletnih mest. Tem se omogoči uporabo namenskih orodij za lažje delo, sodelovanje z ekipo oziroma skupnostjo (blog, wiki, koledar, sporočilne deske, orodje za upravljanje dodelitev itd.). Uporabniki imajo možnost kreiranja in sodelovanja v več skupinah hkrati. Seveda pa je najpomembnejša zmožnost prilagajanja teh orodij. Z lastnimi rešitvami lahko popolnoma prilagodimo uporabo teh orodij svojim potrebam. Prav tako se uporabnikom omogoča neformalna uporaba le-teh. Tako se gradijo skupnosti glede na skupinska zanimanja in interese. To lahko imenujemo kot neke vrsto socialnega druženja oziroma skupnosti. Tudi za te so razvita standardna orodja in funkcionalnosti, ki jo zahtevajo (sistem za sporočanje, zmožnost ocenjevanja, objavljanja vsebin itd.). 16

33 Slika 3.4: Spletno mesto za sodelovanje posameznikov ali skupin na projektih znotraj portalne rešitve [12] Platforma za gradnjo socialnih/družbenih aplikacij. Liferay zagotavlja ogrodje za gradnjo spletni strani, aplikacij in portalov, prav tako pa nudi polno podporo za gradnjo tako imenovanih»družbenih aplikacij«. Pod definicijo družbena aplikacija razumemo spletne aplikacije, ki uporabljajo družbeno identiteto, podatke, funkcije oziroma storitve. Na sliki 3.5 predstavljajo modro obarvane kvadrate običajne spletne aplikacije, medtem ko temnejši kvadrati prikazujejo uporabo družbenih funkcij oziroma njihovega pogleda. Kot preprost primer lahko uporabimo funkcionalnost izkazovanja identitete oziroma prijavo v aplikacijo z uporabo družbene identitete (social login). Prav tako se lahko v dani točki uporabijo zunanji vmesniki do storitev, ki so primarno namenjeni družabnim aplikacijam. Kot primer lahko uporabimo spletni koledar, ki omogoča združevanje več dodelitev na enem, vendar se glede na vloge uporabnika oziroma njegove skupnosti vidijo le tiste aktivnosti, do katerih ima posameznik pravice upravljanja. Standardne družbene aplikacije uporabljajo svoja podatkovna skladišča za podatke. Liferay podpira standard OpenSocial, omogoča uporabnikom, ki imajo ustrezno družbeno identiteto, deljenje podatkovnega skladišča z drugimi informacijami. To omogoča, da so podatki shranjeni na enem mestu, dostopni in uporabni pa so lahko na več mestih oziroma aplikacijah. Portalna rešitev Liferay omogoča podjetjem, da z eno instanco portala ustvarjajo strani, družabna omrežja upravljajo z ekipami in skupnostmi oziroma možnost povezovanja in skupne rabe podatkov z drugimi aplikacijami. 17

34 Slika 3.5: Uporaba standarda OpenSocial omogoča uporabnikom nadgradnjo aplikacij z družbeno identiteto in funkcionalnostmi družbenih omrežij [13] Platforma Liferay ponuja širok nabor orodij, ki omogočajo hitro postavitev spletnih portalov. Omogoča nadgradnje z lastnimi javanskimi razširitvami. Že v osnovi ponuja forum, blog, skupni koledar in sistem za urejanje in sinhronizacijo dokumentov ter sistem za sporočanje. Z namestitvijo dodatnih razširitev pa je možno uporabljati funkcije, ki jih ponujajo plačljivi konkurenčni izdelki. Slika 3.6 prikazuje arhitekturo platforme Liferay, kjer lahko vidimo ključne elemente, ki jo sestavljajo. Omenjeni so tudi standardi in možnost povezljivosti platforme z drugimi rešitvami. 18

35 Slika 3.6: Arhitekture platforme Liferay [14] Portali, zgrajeni na platformi Liferay, omogočajo poganjanje več portalov hkrati na istem strežniku oziroma namestitveni instanci platforme Liferay. Predlaga se celo uporaba skupne baze za različno vsebino. Napaka! Vira sklicevanja ni bilo mogoče najti. Slika.7 prikazuje strukturo platforme Liferay na namestitvenem nivoju. Na sliki lahko vidimo zgradbo posameznega portala in primer namestitve dveh portalov na skupni instanci platforme Liferay. Slika 3.7: Struktura portalov, uporabnikov, spletnih strani na platformi Liferay [15] Na portalu se izvaja več strani, ki imajo enake uporabnike in vloge. S pomočjo nivoja 19

36 globalne vsebine je mogoče del vsebine uporabljati in ustrezno prikazovati na različnih straneh portala, tudi na nivoju uporabnikovih pravic in vlog. Poznamo tri tipe strani: zasebna stran je stran, v kateri je celotna vsebina na voljo vsem prijavljenim uporabnikom; notranja ali omejena stran je tista, za ogled katere morajo uporabniki biti prijavljeni in povabljeni s tem se smatra, da so tem uporabnikom dodeljene ustrezne pravice za ogled takšne strani; odprta stran je lahko sestavljena tako iz javnega kot tudi zasebnega dela. V njem je del vsebine na voljo vsem, drugi del pa samo prijavljenim uporabnikom. To so po navadi vstopne strani, katere imajo na javnem delu na razpolago obrazec za registracijo ter prijavo. Za konfiguracijo in upravljanje portala imamo na voljo posebna orodja, t. i. nadzorno ploščo (control panel), s pomočjo katere lahko upravljajmo z vsemi funkcijami, ki so na voljo. Te delimo na štiri večje sklope, seveda se le-ti lahko upravljajo, če imamo zadostne pravice za upravljanje s posameznim sklopom. Administracija strežnika omogoča urejanje in konfiguriranje različnih spremenljivk in nastavitev strežnika, katere se nanašajo na njegovo delovanje. Spreminjamo lahko nastavitve strežnika za elektronsko pošto, nivoje opozoril, prikazne nastavitve, nameščamo dodatke in razširitve, globalne nastavitve strežnika (nivoje logiranja, nastavitve instance portala, postopkov pri zagonu ugašanju itd.). Upravljaje portala omogoča upravljanje nastavitev, vezanih na konfiguracijo portala. Upravljamo z uporabniki, uporabniškimi skupinami, določamo vloge in pravice, ki vplivajo na delovanje vseh strani znotraj portala. Upravljanje vsebine portala omogoča urejanje nastavitev, ki so vezane na portlete, uporabljene na posamezni strani, kot tudi vsebine in dokumente le-te. Prav tako je mogoče s pomočjo globalnih nastavitev določati nastavitve in vsebino, katere vplivajo na vse strani na portalu. Upravljanje lastnega računa in profila omogoča urejanje uporabnikovih nastavitev profila (ime, priimek, spol datum rojstva, , zaslonsko ime) in obvestil, ki so vezane na 20

37 vse instance (npr. pri delovnem toku ali sporočilih). Omogoča tudi rezervacijo oziroma pridržanje vnaprej določenih avtentikacijskih podatkov (Reserved Credentials), kar onemogoča uporabnikom registracijo s temi podatki. 3.2 Verzioniranje in proces izdaje portalne platforme Liferay Vsaka izdaja nove različice portala oz. platforme Liferay ima poleg številke tudi naziv, ki dodatno označuje izdajo oziroma njeno pričakovano kakovost ali stabilnost. Sistem je zasnovan tako, da pred vsako produkcijsko izdajo izdelajo nadgradnjo obstoječe različice, ki v končni posodobljeni in delujoči verziji predstavlja polno izdajo. Vmesne oziroma beta testne različice pa so navzven videti kot popravki prejšnje. Naziv na splošno nadomešča tretjo številko v različici. Milestone ali Beta (primer 6.2 M1, 6.2 B1): te različice so namenjene testiranju novosti, njihova primarna naloga je zagotavljanje povratnih informacij prek testnih uporabnikov. V teh različicah navadno prihaja do večjih sprememb, ki pa ni nujno, da kadarkoli v resnici preidejo v polno ali beta različico. Beta različica praviloma vsebuje samo popravke za potrjene funkcionalnosti. Release Candidates (primer 6.2 RC1, 6.2 RC2): predstavljajo različice, ki so že šle skozi proces internega testiranja in so namenjene izdaji za javnost. Vsebovale naj bi le še minimalne oziroma nič napak, vendar se izkaže, da se kljub vsem testom po navadi še pojavi kakšen scenarij, kjer pride do napak. General Availability (6.2 GA1, 6.2 GA2): gre zgolj za preimenovane zadnje različice»release Candidate«, ki pa že vsebuje popravke napak, javljenih s strani internih in beta testerjev. Te izdaje so stabilne in so na voljo za prenos na uradni strani Liferay. 3.3 Trgovina Liferay Liferay Marketplace je bil integriran del portala Liferay, vendar je od različice 6.2 treba dodatek Marketplace ročno namestiti poleg vsake instance portala Liferay. Marketplace poleg dostopa do trgovine in direktnega nakupovanja dodatkov in funkcionalnosti omogoča upravljanje z aplikacijami, ki so v paketu portala, ali tistih, katere smo kupili preko trgovine. To vključuje tudi upravljanje z licencami za te aplikacije. Na trgovini je 21

38 dostopnih več različnih dodatkov od samih funkcionalnosti, modulov, različnih postavitev strani do grafičnih podob in aplikacij. Na Liferay Marketplace se lahko pojavimo v dveh različni vlogah, kot uporabnik razvijalec, ki kupuje prodajne elemente, ali kot razvijalec, ki razvija in ponuja svoje funkcionalnosti drugim, ne glede na to, ali so plačljive ali brezplačne. Zakaj bi razvijali aplikacije za Liferay Marketplace in kaj nam ponujajo kot razvijalcem? Že sama ideja je mamljiva, da se pridružimo uveljavljeni skupnosti, ki razvija in ponuja aplikacije po celem svetu, saj je trenutno aktivnih več kot pol milijona instanc portalov Liferay. Trg se nam odpira brez nekega finančnega vložka. Poskrbljeno je tudi za vso odvečno administracijo, saj imamo neposredni dostop do trgovine, ki skrbi za obdelavo plačil, obračun DDV, upravljanje z licencami, skrbi za oglaševanje. Skratka gre za celotno storitev, tako da se kot razvijalci lahko posvetimo izključno razvoju aplikacij. Da postanemo aktivni razvijalci funkcionalnosti za trgovino Liferay, se moramo registrirati na portalu za razvijalce, s tem dobimo tudi izvorno kodo določenih modulov in dokumentacijo oziroma vodnike ter orodja za razvoj aplikacij. Dokler ponujamo aplikacije brezplačno, je naš razvijalski račun brezplačen. Ko pa enkrat začnemo ponujati komercialne rešitve, moramo najprej nadgraditi svoj razvijalski račun iz osnovnega na plačljivega. S tem nam zaračunajo račun razvijalca in uredijo vse potrebno za prenos denarnega toka, ne smemo pa pozabiti dejstva, da imajo pravico do 20 odstotkov naših prihodkov iz naslova prodaje. 3.4 Sodelovanje in prispevanje pri razvoju platforme Liferay Seveda je tako kot pri drugih komercialnih produktih posameznikom omogočeno, da sodelujejo pri procesu razvoja in izboljšanju samega produkta. Pri tem se lahko vključimo na več področjih, glede na znanje in zanimanje. Odpravljanje napak Odpravljanje napak je odličen način, da dodobra spoznamo okolje Liferay, na ta način pa tudi prispevamo k razvoju odprtokodne različice portala. Javno je dostopen seznam manjših napak, ki pa so razvrščene tudi po težavnosti odprave. Za to bomo potrebovali račun Github, preko katerega pridobimo in v primeru odprave napake posodobimo izvorno kodo projekta. Posodobljeno programsko kodo objavimo na centralni sistem za vodenje različic Github, takrat bomo zaprosili za ustrezno osebo, ki bo našo različico programske kode, ki vsebuje popravek, tudi ustrezno preverila. Na spletu je dostopen seznam ljudi, ki 22

39 so odgovorni za posamezen modul, katerega smo spreminjali. V kolikor ta oseba potrdi spremembe in to ustrezno popravi v javno dostopni različici, smo opravili svoje delo in s tem prispevali k razvoju portala. Prevajanje vsebine Razvijalci portala Liferay so zagotovili podporo večjezičnosti za več svetovnih jezikov. Poleg osnovne podpore so ustanovili skupnost, ki jo sestavljajo posamezniki iz različnih držav po svetu, katerim je osnovni cilj izboljšati obstoječe prevode, oziroma omogočiti portalu Liferay, da ponudi podporo več svetovnim jezikom. Enostavno se pridružimo ekipi za prevajanje glede na izbrani jezik in pomagamo pri tem cilju. Kot pomoč pri tem so na spletu dosegljiva navodila oziroma vodič za prevajanje portala. Razvoj novih inovativnih funkcionalnosti Rešitev Liferay je uspešna tudi zaradi dela posameznikov znotraj skupnosti razvijalcev, saj le-ti prispevajo inovacije in ideje, ki zagotavljajo nadaljnji razvoj platforme in zadovoljevanje potreb svojih uporabnikov. Preden postanemo del razvojne skupnosti, moramo dobro spoznati rešitev, vsebino in njeno programsko kodo. Preden se soočimo z razvojem idej, moramo dobro premisliti, ali je smiselno svojo rešitev integrirati v samo jedro platforme, ali je ni mogoče bolje razviti kot dodatek in jo ponuditi v trgovini Liferay Marketplace. Svoje ideje in predloge lahko predebatiramo na forumu za ideje in funkcionalnosti. Če se naša ideja še vedno zdi smiselna, potem vložimo prošnjo za zahtevek in umestitev naše ideje na uradno listo. Četudi naše ideje ne uvrstijo na javni seznam predlogov in idej, lahko prosto implementiramo katero izmed teh uradnih idej, ki so dobile potrditev. Ko smo zaključili z implementacijo in vsemi potrebnimi testi, moramo zagotoviti tudi ustrezno tehnično dokumentacijo. Za konec pa še vse skupaj ustrezno zapakiramo in pošljemo ustrezen zahtevek za pregled implementacije dodatka. Dokumentiranje platforme Liferay V časih, ko obstaja poplava različnih programskih jezikov, platform in ogrodij, s katerimi je Liferay kompatibilen, je dobra dokumentacija še kako pomembna. Ne glede, ali gre za dokumentacijo na višjem nivoju ali za čisto tehnično dokumentacijo, je ta nujno potrebna, v določenih primerih je tudi to pomemben faktor, ko se odločamo med različnimi produkti. Tudi na tem področju so snovalci portala Liferay korak pred drugimi. Zagotavljajo, da se dokumentacija sproti dopolnjuje in korigira, tudi s pomočjo razvijalcev in skupnosti, ki pomaga pri tem. Na spletu so dostopne smernice pisanja dokumentacije, postopek pa je 23

40 podoben kot pri razvoju samih funkcionalnosti. Najprej zadevo raziščemo, ustrezno dokumentiramo, pošljemo zahtevek za pregled in objavo dokumentacije. Prav tako lahko pomagamo pri razlagi pojmov in izrazov, vezanih na platformo Liferay, s tem, ko prispevamo z zapisi na Liferaypedia. 3.5 Izdelava in prilagoditev komponent platforme Liferay V platformi Liferay se lahko prilagodijo popolnoma vse funkcije, ki jih ponuja: od izpisov posameznih strani in nastavitev vse do osnovnega jedra. Platforma je prilagodljiva na treh nivojih, pri čemer vsak nivo omogoča dostop do različnih sprememb. 1. Nivo: Dodatki, narejeni z Liferay SDK. 2. Nivo: Razširitve. 3. Nivo: Izvorna koda platforme. Napredno razvojno orodje SDK deluje s programom Eclipse in spletnim strežnikom Tomcat. S pomočjo tega orodja je mogoče izdelati naslednje dodatke: portlete (portlets), razširitve obstoječih funkcij (hooks), teme (themes) in predloge razporeditve vsebine (layout templates). Za vse dodatke naredimo ločene datoteke WAR, ki se lahko namestijo na strežnik ločeno od platforme in to med izvajanjem (namestitve tipa»hot deploy«). V razširitvah na tem nivoju se lahko uporabijo le funkcije iz Liferay API dela, kar predstavlja jedro platforme in storitev. Zato s takšnimi razširitvami ni mogoče spreminjati nastavitev in izvorne kode platforme ter jezikovnih datotek. Napaka! Vira sklicevanja ni bilo mogoče najti. Slika.8 prikazuje potek namestitve dodatkov SDK (t. i. hot deploy). Slika 3.8: Namestitev dodatkov SDK na spletni strežnik [16] Razširitev obstoječih funkcij 24

41 Zaradi potrebe po spreminjanju datotek JSP obstoječih funkcij platforme in po možnosti nameščanja dodatkov med njenim izvajanjem je na voljo razširitev obstoječih funkcij (hook). Na eni platformi je lahko hkrati nameščenih več hookov, ki imajo različne funkcionalnosti, kar pomeni, da se lahko razvijajo ločeno in neodvisno. Z njim lahko prilagodimo nastavitve in prevode platforme ter datoteke JSP obstoječih portletov in storitev Teme Vsak portal ima svoj videz, v katerem je določeno, kako so videti meniji, vsebina, glava, noga in ostali elementi. V platformi Liferay se za oblikovanje portalov uporablja odprtokodni pogon Apache Velocity, ki uporablja lasten jezik za oblikovanje predlog. Za izdelovanje teme se ob jeziku Velocity uporablja še HTML, CSS in JavaScript. Liferay omogoča, da se na strežnik namesti več tem, ki se lahko poljubno uporabijo. Določi se privzeta tema na nivoju skupine strani, lahko pa se na nivoju posamezne podstrani le-ta spremeni. Z jezikom Velocity se lahko sklicujemo na platforme API, kar omogoča, da se lahko kjerkoli za potrebe prikaza uporabijo funkcije platforme. Klici za najbolj pogoste informacije, npr. informacije o uporabniku (ime, priimek in spol), informacije o navigaciji in trenutni strani (naslov in vrsta strani) ter veliko drugih uporabnih lastnosti, omogočajo izdelavo kvalitetne predloge za videz portala. Teme v portalu Liferay delujejo tako, da temeljijo na eni izmed osnovno definiranih tem. Na voljo sta dve, in sicer»unstyled«, ki vsebuje le osnovne slike brez CSS oblikovanj, ter»styled«, ki vsebuje CSS oblikovanje, vendar je brez grafičnih elementov. Tema zato vsebuje datoteke osnovne teme (unstyled ali styled) ter imenik»_diffs«, v katerem so shranjene vse spremembe osnovne teme Razporeditev vsebine Razporeditve vsebine določajo postavitev spletnih komponent (portletov) na straneh portala. V temi se definira območje, kjer je vsebina; z razporeditvijo pa se določi, kako je vsebina znotraj teh območij razporejena. S pomočjo dodatka se lahko ustvarijo in dodajo poljubne postavitve. Za vsako razporeditev je treba določiti strukturo za prikaz v spletnem brskalniku in za razporeditev na mobilnih napravah. Skupaj z osnovno namestitvijo portala prihajajo najbolj pogoste razporeditve vsebine, ki jih prikazuje slika

42 Slika 3.9: Osnovne razporeditve vsebine [15] Razširitve z lastnimi funkcijami Razširitev omogoča, da se k namestitvi platforme dodajo lastne funkcije ali se spremenijo že obstoječe lastnosti in funkcije. Ena platforma lahko ima nameščeno le eno razširitev, ki se namesti in zažene skupaj z njo. Med delovanjem platforme razširitev ni mogoče odstraniti. Razširitev je lahko sestavljena iz javanske kode, JSP ali datoteke z nastavitvami (properties datoteka). Vzdrževanje razširitve je zahtevnejše opravilo, saj se združi s platformo, zato je med izvajanjem ni mogoče spremeniti (za razliko od dodatkov SDK). Napaka! Vira sklicevanja ni bilo mogoče najti. Slika 3.10 prikazuje postopek amestitve razširitve na portal. Slika 3.10: Namestitev razširitev v platformo Liferay [16] 26

43 3.5.5 Spreminjanje izvorne kode Zaradi odprtokodne rešitve je mogoče spreminjati tudi izvorno kodo platforme. Priporočeno je, da se vse prilagoditve naredijo na 1. ali 2. nivoju, saj se tako lahko lastna koda loči od platforme, kar je še posebej uporabno pri posodobitvah. 3.6 Portlet Portleti so spletne programske komponente, katere upravlja in prikazuje spletni portal. V osnovi portlet sprejema zahtevke, jih obdela in nato prikaže vsebino. Za končnega uporabnika je to samo eno izmed oken (razdelkov) na spletni strani, ki prikazujejo kakšno izmed vsebin (forum, vreme, novice itd.). Možno jim je prilagajati vsebino, videz in postavitev. Takšne nastavitve se shranijo kot konfiguracija portleta. Poznajo pa tudi več načinov prikaza (pogled, urejanje, pomoč), kar še dodatno poveča njihovo prilagodljivost in uporabnost [19]. Glavne razlike med servletom in portletom [20]: servlet lahko generira celotno spletno stran, portlet pa le delček; HTML, ki ga generira portlet, ne sme vsebovati naslednjih značk: body, frame, frameset, head, html ali title; do portleta ne moremo dostopati direktno preko naslova URL. Dostopamo lahko samo preko spletne strani na portalu, ki vsebuje ta portlet; portlet lahko ima kontrolnike za stanje okna in način portleta; na spletno stran lahko dodamo več primerkov istega portleta; portleti lahko shranijo konfiguracijske in uporabniške nastavitve; portlet lahko obdela dva tipa zahtevkov za akcijo in prikaz; portlet ima lahko znotraj seje dva dosega aplikacijski doseg za komunikacijo med portleti in doseg znotraj samega portleta za shranjevanje specifičnih objektov portleta. 27

44 Slika 3.11: Spletna aplikacija na portalu [21] Portleti so del platforme J2EE in v kombinaciji s tehnologijami JSP, HTML, CSS in JavaScript tvorijo majhne aplikacije na portalu. Te aplikacije so razvite neodvisno ena od druge in praviloma ne komunicirajo med seboj. Omogočena je tudi komunikacija med portleti. Tehnično gledano je portlet Java razred, ki implementira vmesnik javax.portlet.portlet in je zapakiran v datoteko WAR ter nameščen v vsebnik portleta (Apache Tomcat, GlassFish, Jetty, JBoss itd.). Vsebnik upravlja s portleti in njihovim življenjskim ciklom. Slika 3.12: Življenjski cikel zahtevkov na portletu [21] Portlet je samo delček spletne strani (ni celoten dokument), zato ga moramo postaviti na spletno stran, kjer bo predstavljal del vsebine. Zaradi tega ga tudi ne moremo neposredno poklicati preko spletnega naslova. Okno portleta je sestavljeno iz okvirja (naslov, kontrole in robovi) in vsebine (prikaz bistva aplikacije). [20] 28

45 Povezava med portleti in vsebnikom je definirana s specifikacijo Java portlet. Obstajata dve različici [21] JSR 168 in JSR 286. JSR 168 (Java Specification Requests 168) določa (Slika 3.13): obdelavo zahtevka in prikaza podpira vzorec MVC, načine prikaza portleta, ki povedo portalu, katero nalogo upravljajo in kakšno vsebino naj prikaže, stanje okna, ki določa, kolikšen del spletne strani bo namenjen vsebini portleta, podatkovni model, ki omogoča shranjevanje informacij v parametre, sejo ali v uporabnikove nastavitve, format pakiranja, ki omogoča, da se portlet namesti na strežniški portal, razvoj portala kot kombinacije različnih spletnih aplikacij za prikaz in storitve. Slika 3.13: Implementacija portleta po JSR 168 [21] JSR 286 (Java Specification Requests 286) opredeljuje (Slika 3.14): komunikacijo med portleti preko parametrov in dogodkov, prenos različnih virov neposredno iz portleta, serviranje AJAX in JSON preko portleta, filtre in poslušalce za portlete. 29

46 Slika 3.14: Implementacija portleta po JSR 286 [21] Portleti Liferay Poleg standardne datoteke (portlet.xml) ponuja Liferay še tri konfiguracijske datoteke [20]: liferay-display.xml opisuje razpored portletov po kategorijah; liferay-portlet.xml opisuje Liferay razširitve specifikacije JSR-286. Definirati je možno ikono, vloge, ime, vključiti lastne CSS in JavaScript datoteke, prožiti razporejevalnik itd.; liferay-plugin-package.properties opisuje vtičnik za Liferay. Nastaviti je možno dostopno listo za portal in datoteke.jar, ki jih potrebujemo ipd. 30

47 4 RAZVOJ ENOSTRANSKIH SPLETNIH APLIKACIJ S PORTALOM LIFERAY 4.1 Ogrodja JavaScript Pri razvoju spletnih aplikacij večkrat predpostavljamo, da lahko vse zahtevane funkcionalnosti implementiramo samo z uporabo knjižnice jquery, a kmalu ugotovimo, da so takšne aplikacije zelo težavne za testiranje, nadgradnjo in vzdrževanje. Gre za knjižnico, ki ne predpisuje, kako jo naj uporabljamo, in nas ne varuje pred slabo strukturirano kodo. Na srečo obstajajo moderna Javascript ogrodja, ki predpisujejo, kako naj kodo pravilno strukturiramo, organiziramo in tako poenostavimo vzdrževanje in razvoj. Ta ogrodja razvijalcu omogočajo enostavno ločevanje nivojev, saj sledijo arhitekturnemu vzorcu MV* (MVC, MVP, MVVM). Uporaba ogrodij JavaScript je smiselna za enostranske spletne aplikacije s kompleksnim uporabniškim vmesnikom, ali ko samo želimo zmanjšati število poizvedb, potrebnih za izris novega pogleda. Sodobna ogrodja vključujejo še predloge, usmerjevalnik, upravljanje zgodovine in podatkovno povezovanje, ki bi jih drugače morali implementirati sami. 4.2 Vzorca MVC in DAO Pri razvoju rešitve smo poskušali uporabiti čim več različnih načrtovalskih vzorcev in dobrih praks. Med najbolj izstopajočima, na katerih sloni celotna koda in arhitektura, sta vzorca DAO in MVC. DAO je načrtovalski vzorec, s katerim ločimo poslovni nivo od podatkovnega nivoja. Nivo poslovne logike manipulira z objekti, ki se shranjujejo in berejo na podatkovnem nivoju. Vzorec DAO poskrbi, da je koda za shranjevanje neodvisna od poslovne logike. Tako se lahko podatkovna baza ali način shranjevanja spremeni in to ne vpliva na poslovno logiko. Napaka! Vira sklicevanja ni bilo mogoče najti. Slika 4.1 prikazuje, kako je programska ogika preko razredov DAO povezana na podatkovno bazo. Podatkovno bazo lahko predstavlja tudi datotečni sistem ali katera druga oblika hrambe podatkov. 31

48 Slika 4.1: Povezava med poslovno logiko in podatkovno bazo z razredi DAO MVC je arhitekturni vzorec, ki določa komponentno arhitekturo: model, pogled in kontroler (ang.: Model view controller). Model služi kot nosilec podatkov med kontrolerjem in pogledom. Kontroler se odziva na uporabnikove akcije in spreminja stanje modela. V našem primeru so to portleti, ki skrbijo za obravnavo zahtev. Pogled pa skrbi za prikaz rezultatov in obrazcev v brskalniku. V našem primeru so to datoteke JSP na portletih. Način komunikacije posameznih nivojev arhitekture z uporabnikom prikazuje slika 4.2. [20] 32

49 Slika 4.2: Povezava komponent MVC med sabo in z uporabnikom 4.3 Sodobni uporabniški vmesniki in odzivno oblikovanje Odzivno oblikovanje je pristop k oblikovanju spletnih strani, ki strmi k enotni uporabniški izkušnji na različnih napravah. Cilj tega pristopa je, da uporabniku omogočimo preprost pregled in enostavno navigacijo po spletni strani (Napaka! Vira sklicevanja ni bilo ogoče najti. 4.3), brez nepotrebnega povečevanja in zmanjševanja ter pomikanja. Začetki odzivnega oblikovanja segajo v leto 2010, ko je Ethan Marcotte v članku revije»a List Apart«prvič predstavil izraz»odzivno oblikovanje«. Leto pozneje pa je izdal knjigo z naslovom»odzivno oblikovanje«, kjer je predstavil ta pristop iz teoretičnega in praktičnega vidika. Vrhunec priljubljenosti, tako med uporabniki kot med razvijalci, pa je pristop doživel leta 2013 [18]. Ko pogledamo statično spletno stran, opazimo, da je vsebina sicer lepo prikazana na osebnem računalniku, vendar ko isto stran pogledamo še na mobilnem telefonu ali tabličnem računalniku, ugotovimo, da moramo za branje vsebine stran razširjati ali se premikati po njej. Seveda je brskanje odvisno tudi od uporabnika, ki lahko mobilno napravo kadarkoli zasuče in povzroči spremembo v postavitvi formata (pokončno/ležeče). Končna vsota množice zaslonov, njihovih resolucij in velikosti je torej ogromna. Odzivno oblikovanje glede na velikost zaslona prilagodi prikaz vsebine, s tem pa uporabniku 33

50 omogoči lažji pregled spletne strani [19]. Odzivno oblikovane spletne strani se različnim zaslonom naprav ne prilagajajo samo z velikostjo slik (ang. flexible images) ter velikostjo mreže (ang. fluid grid), ampak se prilagodijo tudi z različnim prikazom elementov. Takšno prilagajanje je postalo mogoče s pojavom specifikacij CSS3, v njih je definirana funkcionalnost media query. Z le-to pa lahko ob tipu naprave zaznamo tudi njene karakteristike, na podlagi katerih nato dodelimo specifične oblikovne stile (ang. Cascading Style Sheets - CSS) [24]. Prednosti odzivnega oblikovanja [20]: povečana vidljivost in odzivnost, optimalna uporabniška izkušnja na vseh napravah, podpora tudi za naprave, ki še ne obstajajo. Slabosti: zahteva več načrtovanja, da predvidimo vse možne scenarije, zahtevnejša implementacija, količina prenesene vsebine je ne glede na tip naprave ali velikosti zaslona enaka. Slika 4.3: Primer odzivnega oblikovanja 4.4 Pristopi k odzivnemu oblikovanju V praksi pristop k razvoju odzivnega oblikovanja sestavlja mešanica prilagodljivih mrež in postavitev, slik in pametna uporaba CSS. V nadaljevanju bomo predstavili nekaj pristopov, s katerimi lahko dosežemo odzivno prilagajanje uporabniškega vmesnika glede na potrebe različnih naprav. Glede na množico različnih naprav, ki obstajajo dandanes, in 34

51 še na večjo raznolikost velikosti in resolucij ekranov različnih naprav je skorajda nemogoče oblikovati uporabniški vmesnik za vsako od naprav zase. Odgovor temu predstavlja prilagodljivo oblikovanje [6] Prilagodljiva postavitev Odzivno oblikovanje oziroma prilagodljivo postavitev dosežemo z uvedbo tekočega oziroma elastičnega oblikovanja (angl. liquid layout). Za razliko od klasične fiksne postavitve, kjer imajo vsi elementi nastavljene točno določene dimenzije, pri tekočem oblikovanju nastavljamo dimenzije v odstotkih (Slika 4.4). Tako dosežemo prilagodljivost postavitve, ne glede na velikost zaslona uporabnikove naprave. Slika 4.4: Primerjava definiranja elementov fiksnega in tekočega oblikovanja Za razliko od tekočega oblikovanja pri elastičnem velikosti elementov nastavljamo z enoto em. Elastičen pristop se bistveno ne razlikuje od tekočega, vendar pa se razlikuje predvsem na definiranju različnih velikosti pisave. Takšen pristop namreč poleg postavitve velikosti zaslona prilagaja tudi velikost pisave. [5] Prilagodljivost slik Ena izmed težav, ki jih je rešujemo s pristopom osebnega oblikovanja, je ustrezno prikazovanje slik. Za to imamo na voljo tehnike, s katerimi lahko prilagajamo velikost slik z ohranjanjem njihove sorazmerne širine in višine. Eden izmed takšnih pristopov je pristop prilagodljivih slik (angl. fluid images), pri katerem definiramo maksimalno širino slik z odstotki. S tem dosežemo, da se slika elementarnemu razmerju prilagodi dimenzijam elementa, v katerem se nahaja. [22] 35

52 Pri tem pristopu moramo biti pozorni, saj se lahko pri starejših brskalnikih ob zmanjšanju velikosti slik te popačijo. Težavo rešimo z uporabo jezika JavaScript. Čeprav rešitev prilagodljivih slik omogoča hitro in nezahtevno prilagodljivost slik, ta rešitev predvidi uporabo največje velikosti slik, le-te pa lahko zaradi svoje velikosti bistveno vplivajo na hitrost nalaganja strani. Alternativni pristop nam omogoča nastavitev več velikosti slik za posamezen element, medtem pa mora sistem poskrbeti za samodejno izbiro ustrezne slike. Ta rešitev je odprtokodna in je na voljo na Github, predvideva pa uporabo funkcij JavaScript in direktiv.htacces. Nastavitev slike v tem primeru določimo s klicem, kjer kot vir elementa»img«nastavimo več različnih velikosti slike, ki so na voljo. Ustrezna slika pa se ponovno nastavi, ko velikost ekrana doseže določeno mejo. [22] Poizvedba CSS Media Query Tudi CSS Media Query temelji na uporabi CSS3. Sestoji iz tipa media in izrazov, ki preverjajo pogoje določenih medijskih funkcionalnosti. Je logičen izraz, ki je lahko resničen ali neresničen. Resničen je, če je ustrezen tip media in vsi izrazi, ki mu sledijo. [26] Na primeru media element definira pravilo: v kolikor bo brskalnik to stran prikazal na zaslonu, katerega širina zaslona ne presega 480px, potem bo naložil stilno datoteko»mobile.css«. <link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="mobile.css" /> Praksa je, da z uporabo media query združimo več stilnih datotek v eno, kar je najbolj učinkovit način naslavljanja stilnih datotek Jezik JavaScript Poleg prej navedenih metod lahko uporabimo tudi skriptni jezik JavaScript. Uporablja se predvsem za podporo napravam, ki ne podpirajo CSS3 in posledično ne morejo izvajati media query. Zato lahko uporabimo knjižnice JavaScript, tako imenovane JQuery, s katerimi zaznamo velikost brskalnika in nastavimo ustrezne stile strani. 36

53 4.5 Izzivi pri gradnji enostranskih spletnih aplikacij Zagotavljanje delovanja običajnih brskalnikovih funkcij Značilnost enostranski spletnih aplikacij je tudi ta, da se spletni naslov URL med samim delovanjem ne spreminja. S tem pa takoj naletimo na težavo pri delovanju povsem običajnih funkcij spletnega brskalnika. Tu je govora o krmilnem gumbu naprej/nazaj, možnosti pregleda zgodovine spletnega brskalnika, možnosti shranjevanja zaznamkov itd. Kot smo že omenili, enostranske spletne aplikacije delujejo in prehajajo med stanji, zato si je treba le-ta ustrezno shraniti in jih v določenem trenutku povezati. To rešujemo tako, da shranjujemo stanja enostranske spletne aplikacije in jih ustrezno povežemo z naslovom url, kateremu za vsako stanje na konec dodamo poseben znak»#«, ki ga imenujemo»hashfragment identifier«. Za to moramo poskrbeti sami s pomočjo JavaScript. Aplikacija, ki je sposobna povezovati spremembo naslova URL s stanjem strani ter nadzirati gumba naprej/nazaj, deluje kot ESA [1], [8]. Iz tega sledi, da mora takšna aplikacija znati naložiti stran ter podatke, stanje iz samega naslova URL Začetno nalaganje strani (JavaScript, HTML, CSS) Začetno nalaganje strani je pri zelo obsežnih enostranskih spletnih aplikacijah lahko počasno, saj v danem trenutku nalagamo ogrodje in kodo, potrebno za vse strani, in ne le zgolj za trenutno zahtevano stran. To lahko pripelje do vprašanja varnosti in zanesljivosti takšne aplikacije. Zato je pred samo odločitvijo o gradnji enostranskih spletnih aplikacij treba dobro premisliti o primernosti le-te. Načeloma velja pravilo, da tak tip aplikacij ni primeren za obsežne in vsebinsko bogate strani Optimizacija strani za iskalnike (SEO) Enega večjih oziroma resnejših izzivov pristopa ESA predstavlja dejstvo, da večina programov za indeksiranje spletnih strani ne zna poganjati in izvajati skriptnega jezika JavaScript. Posledično takšni programi ne znajo indeksirati notranjih strani oziroma celotne vsebine enostranske spletne aplikacije. Zato je pri razvoju tovrstnih aplikacij treba posebno pozornost posvečati priporočilom ponudnikov storitev, ki indeksirajo strani. Tu bi opozorili, da se sledi smernicam, ki jih postavlja Google, saj je le-ta vodilni in tem smernicam sledijo tudi drugi. Pri tem je prav tako pomembno, da strežnik prepozna 37

54 zahtevo in zna oceniti, ali je ta prišla iz strani uporabnika, ali pa je bila sprožena iz strani indeksirnega programa. Glede na to se pokaže primerna vsebina. Tak način prepoznavanja zahteve najpogosteje rešujemo z v nadaljevanju opisanima načinoma. Z uporabo znaka»#!«(ang. hash fragments): v tem primeru predvidevamo, da programi za indeksiranje v spletnem naslovu URL prepoznajo posebni znak, katerega pri klicu zamenjajo s parametrom»_escaped_fragment_=«. V tem primeru strežnik preveri, ali je parameter prisoten, na osnovi le-tega pa prikaže primerno vsebino. Slika 4.5: Indeksiranja spletne strani z uporabo parametrov»_escaped_fragment_=«[21] Naslednji način prepoznavanja zahteve je s preverjanjem podatkov»user-agent«: strežnik na podlagi podatkov»user-agent«prepozna, od kje je bila poslana zahteva. Temu primerno pa prikaže tudi vsebino. Pri tem načinu je treba zagotoviti, da strežnik prepozna vse različne vrste sistemov za indeksiranje. Zagotoviti je treba, da imamo za vsako podstran svoje stanje vezano na ustrezen spletni naslov URL, preko katerega se dostopa do nje. Pri tem načinu mora imeti spletna aplikacija ustrezni usmerjevalnik, ki omogoča nalaganje strani na podlagi parametrov. Prav tako je treba za strani, ki nimajo direktnih povezav v aplikaciji, podati nekakšen imenik teh strani s pomočjo datoteke Sitemap. Verjetno pa je že samoumevno, da moramo to datoteko redno ažurirati. Za implementacijo kateregakoli izmed zgornjih načinov indeksiranja je treba vložiti kar nekaj truda in lahko povzročata preglavice, ko enostranske spletne aplikacije začnejo pridobivati na velikosti in kompleksnosti. Obstaja tudi nekaj pasti pri optimizaciji za indeksiranje ESA, na katere moramo biti pozorni. Najpogostejši nevarnosti sta razlika med pregledom strani, ki je bila ustvarjena za programe za indeksiranje, in dejansko vsebino, kar posledično 38

55 prinese slabšo oceno, katero lahko dobimo tudi iz naslova počasnega delovanja strani na osnovi analize odzivnosti strani, ki jo strežnik posebej pripravi za indeksirne programe iskalnikov [2]. 39

56 5 PRIMER PRAKTIČNE REŠITVE V nadaljevanju bomo prikazali razvoj dela komponent enostranske spletne strani s pomočjo portalne platforme Liferay. Naša rešitev bo vsebovala komponente za prijavo uporabnika z ustrezno vlogo trenerja na portal, kjer mu bo omogočen pregled in izbor posameznih vnaprej definiranih vadb, le-te pa bo potem dodelil drugim uporabnikom z vlogo klienta, kateri bodo po prijavi le-te videli na svojem koledarju. Omogočali bomo osnovne akcije in zagotovili delovanje pozitivnega scenarija, prikazanega na diagramu poteka (Slika 5.1). Opis glavnih točk postopka. 1.) Uporabnik v vlogi trenerja se prijavi na portalno mesto s svojim računom. 2.) Trener izbere pregled vadb. 3.) Sistem trenerju prikaže vnaprej definirane in vnesene vadbe. 4.) Trener iz seznama poišče in izbere vadbo, ki jo želi uporabiti. 5.) Trener dodeli izbrano vadbo na koledar uporabnika v vlogi klienta, za katerega je zadolžen. Slika 5.1: Diagram poteka 5.1 Priprava in namestitev portala Liferay Pred samo postavitvijo portala moramo razmisliti in sprejeti nekaj pomembnih odločitev, vezanih na okolje, ki ga postavljamo. Delijo se v tri različne sklope, in sicer: namestitev in uporaba podatkovne baze, priprava inicialnih podatkov portala ter konfiguracija aplikacijskega strežnika. Na nivoju podatkovne baze se moramo odločiti za arhitekturo podatkovne baze. Imamo dve možnosti, in sicer da uporabimo generično Liferay podatkovno strukturo, ali pa se odločimo za lastno. Privzeta in priporočena je struktura, ki jo ponuja Liferay, saj ta zagotavlja najmanj zapletov pri namestitvi, vendar zaradi njenega širokega spektra 40

57 dobimo tudi nekaj odvečnega balasta. To je sicer iz stališča preprostosti namestitve najugodnejša pot, vendar ne najbolj optimalna. Običajno se za drugo opcijo odločajo bolj napredni razvijalci z jasno definirano rešitvijo, ki jo bodo implementirali. Za inicialno postavitev portala moramo določiti določene vloge za postavitev in konfiguracijo strežnika. Zagotoviti moramo veljaven elektronski poštni naslov, preko katerega bomo prejemali obvestila in se z njim tudi prijavili na portal. Pred namestitvijo strežnika moramo preveriti okolje, na katerem bo vse skupaj nameščeno. Glede na potrebe produkta ali naročnika imamo več možnosti. Običajno se odločamo, ali bomo namestili paket Liferay skupaj z lastnim aplikacijskim strežnikom ali pa na morebitni obstoječi aplikativni strežnik samo dodamo potrebne pakete, knjižnice in ustrezno datotečno strukturo. Programski paket Liferay vsebuje identično datotečno strukturo ne glede na aplikativni strežnik. Najvišji paket v tej datotečni strukturi je poimenovan po različici portala (primer: liferay-portal-6.2- ce-ga2). To mapo navadno poimenujemo kot korenski imenik Liferay. Slika 5.2 prikazuje notranjo strukturo map. Slika 5.2: Datotečna struktura znotraj korenskega imenika Liferay Vsaka izmed teh map služi svojemu namenu. V mapi data se nahaja vgrajeni programski paket za podatkovno bazo HSQL in njeno delovno okolje, prav tako vsebuje konfiguracijo in podatke ter zbirno okolje za vsebino Jackrabbit JSR-170. V mapo deploy prenesemo dodatke in elemente, ki jih želimo objaviti na ciljni aplikacijski strežnik. Navadno gre tu za datoteke s končnico *.war, ki vsebujejo spletne aplikacije, ki so pripravljene za objavo. Datoteka vsebuje JSP, HTML, JavaScript in druge datoteke, ki 41

58 so potrebne za razvoj spletnih aplikacij. Mapa license je namenjena izključno hranjenju posebnih pogojev in licenc, pod katerimi deluje trenutna programska oprema. V mapi logs se nahajajo datoteke, ki beležijo dogajanje s programskim paketom Liferay. Ime mape aplikativni strežnik je odvisno od različice paketa programske opreme, posledično samega aplikativnega strežnika. Mapa vsebuje instanco aplikativnega strežnika, na katerem teče portal Liferay. Prav tako so v njem že nameščeni privzeti paketi programske opreme. Vzpostavitev portala Liferay je torej najenostavnejše, če to storimo z namestitvijo zbirke programske opreme Liferay. Programsko zbirko Liferay prenesemo na strežnik, kjer bo tekel portal, in jo razpakiramo. Kopiramo jo na imenik, katerega smo določili kot domačega za platformo Liferay. Poskrbimo še za ustrezne gonilnike in konfiguracijo za dostop do podatkovne baze. Če predpostavljamo, da za aplikacijski strežnik uporabimo Tomcat, skopiramo gonilnike s končnico.jar v imenik Tomcat/ib/ext. Konfiguracijo za dostop do baze nastavimo v korenskem imeniku Tomcat, in sicer v mapi server.xml. Po tem koraku le še zaženemo aplikacijski strežnik, po uspešnem zagonu portala se odpre privzeti spletni brskalnik z url naslovom: tu pa je sedaj dosegljiv naš nov spletni portal. 5.2 Vzpostavitev okolja in prilagoditev platforme Liferay za ESA Spletna platforma Liferay, na kateri temelji naš portal, ni namenjena razvoju ESA. Liferay podpira samo razvoj portletov, to so spletne programske komponente. Edina podobnost med portletom in pogledom ESA je v predstavitvi, saj oba predstavljata le del prikazane strani. Za razvoj ESA je bilo treba portlete uporabiti drugače, kot so bili zamišljeni. Struktura našega projekta: src o portlet paket s portleti, ki jih uporablja aplikacija o services paket s servisi, ki jih uporabljajo portleti docroot 42

59 o css stili za poglede o html pogledi ESA o images slikovne datoteke o js moduli JavaScript WEB-INF o tags značke JSP, ki jih uporabljajo pogledi o tld preslikava Java funkcij Osnovo našega ogrodja predstavlja razred BasePortlet, ki lahko izvaja poljubne akcije v metodi serveresource in vrača odgovore v obliki HTML ali JSON. Glede na klic akcije se vrne ustrezna oblika odgovora, serializacija objektov v JSON pa poteka samodejno. Posamezen portlet lahko vsebuje več servisov in en SiteMap. Vsak servis ima lahko več metod, ki predstavljajo akcije. Posamezna akcija pred izvedbo v BaseService prebere svoje argumente in jih po potrebi dinamično vstavi. Znotraj akcije imamo tudi možnost pretvorbe zahtevka v določen objekt. SiteMap se uporablja za preslikavo pogleda ESA v konstante, ki jih potem uporabljamo na odjemalcu. Posamezen pogled je datoteka JSP (angl. JavaServer Pages), ki lahko vsebuje tudi značke JSP. Definiramo lahko tudi manjše dele strani in jih uporabimo kot predlogo za izris podatkov kar na strežniški strani s pomočjo EL (angl. Expression Language). Iz akcije v servisu imamo dostop do podatkovne baze preko razreda BaseDAO, ki poenostavlja delo z bazo in deluje nad bazenom povezav. Znotraj metode DAO lahko poljubno uporabimo tudi BaseFactory, ki zna iz rezultata bazne poizvedbe sestaviti objekt razreda BaseEntity (angl. ORM - Objectrelational mapping). Vsak dostop do baze pa je tudi časovno merjen zaradi hitrejšega odkrivanja ozkih grl. 43

60 Slika 5.3: Nivoji strežniškega ogrodja in osnovni razredi Naloge posameznih nivojev: pogled prikaz podatkov, kontroler delo s servisi in serializacija odgovorov, servis vstavljanje odvisnosti in izvedba akcij. podatkovni nivo delo s podatkovno bazo in tvorba objektov. Za odjemalčevo stran ogrodja skrbi Manager, to je modul JavaScript, ki skrbi za nalaganje pogledov in podatkov. Vsa komunikacija AJAX poteka preko njega, saj edini komunicira s strežnikom. V primeru, ko je odgovor tipa HTML, ga naloži ali pa prikaže v pojavnem oknu odvisno od akcije. Vsak pogled ima zapisano tudi konfiguracijo, ki jo Manager prebere in pokliče ustrezno metodo za inicializacijo. Omogoča tudi zapisovanje napak odjemalca na strežniško stran, da so vse napake zbrane na enem mestu. Skrbi tudi za vse dogodke pojavnih oken in menijskega gumba. Prav tako pa časovno meri vsako komunikacijo odjemalca s strežnikom. Funkcionalnosti posameznih pogledov so zapisane v ločenih modulih. [6] 44

61 Osnovne naloge modula Manager: nalaganje in prikaz pogledov, branje konfiguracije, nalaganje podatkov, beleženje napak, pridobivanje prevodov. 5.3 Implementacija enostranske spletne aplikacije za dodajanje opravil na koledar uporabnika Implementacija prijave uporabnika na spletni portal Preden sploh lahko uporabnik začne z delom na omenjenem portalu, je potrebna ustrezna prijava preko začetnega zaslona. Na osnovi uporabniškega imena in gesla identificiramo uporabnika, kjer najprej v bazi preverimo, ali zanj že obstaja aktivni račun, ter izvedemo avtorizacijo prijave. V kolikor uporabnik ne obstaja oziroma so prijavni podatki neustrezni, uporabnika na to opozorimo ter zavrnemo nadaljnje akcije. V primeru, ko ustrezen uporabniški račun že obstaja in je prijava uspešna, se preverijo tudi njegove vloge in dodeljene pravice ter se prikaže ustrezen pogled. Slika 5.4: Zaslonska slika prijave na portal 45

62 Slika 5.5: Del izvorne kode za izris obrazca za prijavo Slika 5.5 opisuje del kode v datoteki»view.jsp«, ki skrbi za izris ustreznega pogleda na strani odjemalca (Slika 5.4). Kot vidimo, imamo definirane osnovne tri elemente: dve vnosni polji (za uporabniško ime in geslo) in gumb za potrditev prijave ter proženje akcije na strežniški strani,»liferay-ui:message tag«pa je funkcionalnost večjezičnosti, ki jo zagotavlja že platforma Liferay, in sicer skrbi za ustrezen izpis prevodov besedil glede na izbrani jezik. Glede na zahtevan ključ portal izpiše ustrezen prevod glede na definiran jezik. Prevodi se navadno nahajajo v razširitvenem elementu (Liferay hook), ki zagotavlja, da se pri zagonu portala izvedejo poosebljene akcije, posodobitve portala, razširitve določenih *.jsp datotek itd. Slika 5.6: Metoda render, ki se izvede ob inicialnem nalaganju pogleda Slika 5.7: Del izvorne kode na strežniški strani, servisna akcija za prijavo 46

63 Slika 5.8: Primer klica AJAK akcije_dologin na strani odjemalca, ki vrača JSON Slika 5.8 prikazuje klic akcije za prijavo na strani odjemalca, kjer preko klica AJAX pošljemo podatke na strežnik in glede na prejete podatke izvedemo akcijo, ki je lahko uspešna ali neuspešna, ter posodobitev pogleda na brskalniku, ki je lahko uspešna ali neuspešna Implementacija izpisa seznama vadb, katerega uporabnik vidi Po uspešni prijavi se uporabniku prikaže seznam vadb (Slika 5.9), s katerimi lahko upravlja in jih dodeljuje klientom. Prikaže se skrčeni seznam vadb, ki so predhodno bile vnesene v podatkovno bazo. Prikazuje se tudi opis vadbene enote ter število vaj, ki so sestavni del te vadbene enote, ter tip vadbe. Slika 5.9: Zaslonska slika izpisa seznama vadb uporabniku iz podatkovne baze 47

64 Slika 5.10: Del kode view.jsp, ki skrbi za ustrezen prikaz strani na brskalniku Znotraj view.jsp (prikazuje slika 5.10) je definirana prirejena oznaka JSP, ki predstavlja del kode html. Uporabljena je na več mestih, zato je prestavljena v knjižnico oznak (angl. tags), kjer se nahaja skupek namensko definiranih oznak, ki omogočajo poosebljeni prikaz in obnašanje. Seveda je treba znotraj datoteke jsp s pomočjo direktive taglib deklarirati uporabo oznak. Navesti moramo mesto, kjer se nahaja knjižnica z oznakami in podatke, s katerimi identificiramo posamezno oznako. Te razširitve omogočajo vključevanje zunanjih oznak direktno v Java Server Page. Slika 5.11 prikazuje oznako»workout«. Ta omogoča poosebljen prikaz dela seznama vadb. Nadaljnje pa so prikazani še posamezni deli programske kode, ki omogoča izvedbo celotnega poteka dela, ki smo ga definirali. Na sliki 5.12 lahko vidimo definirano privzeto akcijo, ki jo izvede upravljalec pri nalaganju te strani. Slika 5.13 prikazuje del kode storitve oz. servisa na strežniški strani, kateri ima preko akcije dostop do podatkovnega nivoja, kjer s pomočjo metode DAO (Slika 5.14) pridobimo podatke iz podatkovne baze, katere zna sestaviti oz. preslikati v ustrezne razrede objektov, ki jih zahtevamo. 48

65 Slika 5.11: Uporaba jsp elementa/oznake»workout«, s pomočjo katerega prikažemo uporabniku seznam vadb Slika 5.12: Privzeta akcija na strani upravitelja za pogled Slika 5.13: Servis na strežniški strani za pridobitev podatkov iz baze 49

66 Slika 5.14: Pridobitev podatkov na podatkovnem nivoju in vrnitev rezultatov poizvedbe s pomočjo tovarne objektov Implementacija dodeljevanja vadbe na koledar določenega uporabnika Uporabnik lahko iz seznama izbere vadbo, ki jo želi dodeliti klientu. Ob izbiri posamezne vadbe se prikažejo podrobnejši podatki o tej vadbi (Slika 5.15). Prav tako se omogoči gumb»assign«, namenjen dodeljevanju vadb. Izbira tega gumba vodi do pojavnega okna s seznamom uporabnikov/klientov, ki jim lahko dodeljujemo vadbe (Slika 5.16). Izberemo lahko posamezne vadbe uporabnika in potrdimo dokončno dodelitev vadbe. V ozadju se preko JavaScript metode (Slika 5.17) proži storitev na strežniški strani (Slika 5.18), ki ima dostop do podatkovnega nivoja, ki izvede klic bazne rutine z ustrezno logiko za dodelitev te vadbe uporabniku (Slika 5.19). Slika 5.15: Podroben prikaz podatkov posamezne vadbe 50

67 Slika 5.16: Pojavno okno za izbiro uporabnika, ki mu želimo dodeliti vadbo Slika 5.17: Metoda na strani odjemalca pokliče servis za dodelitev vadbe uporabniku Slika 5.18: Storitev na strežniku za dostop do akcije na podatkovnem nivoju Slika 5.19: Klic bazne procedure za posodobitev ustreznih tabel Predstavljeni primeri so le del večje informacijske rešitve, imenovane 24alife Fitness. Po 51