Izdelava spletnega kataloga v orodju TYPO3 CMS

Transkripcija

1 FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO SMETANOVA ULICA MARIBOR, SLOVENIJA Uroš Žunko Izdelava spletnega kataloga v orodju TYPO3 CMS Diplomsko delo Maribor, marec 2016

2 Izdelava spletnega kataloga v orodju TYPO3 CMS Diplomsko delo Študent: Študijski program: Smer: Mentor: Lektor: Uroš Žunko Visokošolski strokovni študijski program prve stopnje Računalništvo in informatika Informatika red. prof. dr. Marjan Heričko Andreja Obrul, prof. slov. in soc.

3 ii

4 ZAHVALA Zahvaljujem se mentorju red. prof. dr. Marjanu Heričku za pomoč in vodenje pri opravljanju diplomskega dela. Posebna zahvala gre tudi moji mami in sestri za podporo med študijem. iii

5 Izdelava spletnega kataloga v orodju TYPO3 CMS Ključne besede: spletni katalog, informacijski sistemi, razširitev, PHP, Extbase, Fluid, REST UDK: (043.2) Povzetek V diplomskem delu bomo predstavili razvoj spletnega kataloga na osnovi orodja za upravljanje vsebin TYPO3 CMS. Namen spletnega kataloga je izdelava novih vrst vsebinskih elementov na TYPO3 CMS. Za načrtovanje sheme je bilo uporabljeno domensko usmerjeno načrtovanje. Razvoj temelji na ogrodju Extbase in generatorju predlog Fluid, ki uporabljata arhitekturni vzorec MVC. Izdelan spletni katalog omogoča objavo spletnih vsebin s pomočjo izdelave novih vrst vsebinskih elementov. Z vtičnikom REST (REpresentational State Transfer) API (Aplication Programme Interface) je omogočeno enostavno upravljanje spletnih vsebin. iv

6 Development of a product catalogue using TYPO3 CMS Key words: product catalogue, information systems, extension, PHP, Extbase, Fluid, REST UDK: (043.2) Abstract In the thesis, we have represented the development of a product catalogue using TYPO3 CMS. The purpose of a product catalogue is to create new content element types on TYPO3 CMS. Development was based on Domain Driven Design using MVC with Extbase framework and Fluid template engine. The produced catalogue uses content element types for publishing and REST API. v

7

8 Kazalo 1 Uvod Predstavitev orodja TYPO3 CMS Zgodovina Sistem za upravljanje vsebin (CMS) Ustvarjanje in strukturiranje vsebin Organizacija vsebin Objava Hranjene in arhiviranje Zakaj TYPO3 CMS Arhitektura Drevesna struktura in vsebina Razširitve Konfiguracijski jezik TypoScript Konfiguracija tabel TCA Arhitekturni vzorec MVC Zgodovina Uporaba Ogrodje Extbase Vzorec Edinec Vzorec Prototip Vzorec Injeciranje odvisnosti Domensko usmerjeno načrtovanje Generator predlog Fluid Predloge... 24

9 3.5.2 Postavitve Delne predloge Sekcije Arhitekturni stil REST Izdelava spletnega kataloga Obstoječe rešitve Okolje za izdelavo Izdelava razširitve spletnega kataloga Modeliranje Implementacija Izdelava vtičnika katalog REST API Uporaba spletnega kataloga Namestitev Prilagoditev Testni primer Sklep viii

10 Kazalo slik Slika 1: Drevesna struktura s korensko predlogo Slika 2: Različne vrste strani in različne vrste vsebinskih elementov Slika 3: Nova arhitektura TYPO3 CMS Slika 4: Prikaz podatkov iz podatkovne baze Slika 5: Prvi in drugi nivo menija Slika 6: Odločitveni stavek za preverjanje brskalnika Slika 7: Vključitev prednastavljene TypoScript konfiguracije Slika 8: Object Browser za pregled konfiguracije TypoScript Slika 9: Razširitev tabele tt_content z novim poljem podnaslov Slika 10: Predstavitev ideje za premostitev iz mentalnega v računalniški model Slika 11: Razred Edinec s posebno metodo primerka Slika 12: Injeciranje odvisnosti z metodo Slika 13: Injeciranje odvisnosti z anotacijo Slika 14: Nalaganje razrednih lastnosti z lazy loadingom Slika 15: DDD pri poteku programa aplikacije TYPO3 CMS/Extbase. [13] Slika 16: Zgradba in izvajanje Fluid Slika 17: Izdelava domenskega modela Content za obstoječo tabelo tt_content Slika 18: Mapiranje obstoječih lastnosti na domenski model Content Slika 19: Generirana izvorna koda razreda Content za domenski model Content Slika 20: Razultat domenske sheme spletnega kataloga Slika 21: Datotečna struktura spletnega kataloga Slika 22: Razširitvena točka za nastavitev konfiguracije TCA posamezne lastnosti Slika 23: Določanje vrste lastnosti in določitev relacije na drug podatkovni model Slika 24: Metoda v razredu Content za klic generičnih lastnosti Slika 25: Razred CatalogProperties in Manager za pridobivanje podatkov generičnih lastnosti Slika 26: Prikaz zavihkov za boljšo uporabniško izkušnjo Slika 27: Lastnosti na paleti v vrstičnem prikazu Slika 28: Konfiguracija TypoScript za manipulacijo vsebinskih elementov Slika 29: Razred CatalogProcessor za kreiranje Content objektov Slika 30: Krmilnik Rest s pripadajočimi metodami (dispatch, get, post, put, delete) Slika 31: Metodi tojson in toxml v razredu Content za delovanje Rest API Slika 32: Aktivacija razširitve catalog v EM ix

11 Slika 33: Namestitev razširitve catalog v EM z nalaganjem datoteke Slika 34: Vključitev statične predloge iz razširitve catalog na korensko predlogo Slika 35: Odločitveni stavek za vklop vtičnika REST API Slika 36: Konfiguracija realurl za mapiranje GET parametrov Slika 37: Nastavitev poti v TypoScript za uporabo različnih predlog Slika 38: Sprememba predlog na določeni strani ali veji Slika 39: Sprememba predloge za vrsto vsebinskega elementa s ključem novica Slika 40: Izdelava drevesne strukture za prikaz izdelkov Slika 41: Nove lastnosti na konfiguracijski strani Lastnosti Slika 42: Nove skupine izdelkov Slika 43: Sekcije posamezne vrste in pripadajoče lastnosti Slika 44: Dodajanje novih izdelkov Slika 45: Prikaz vnosnih polj glede na konfiguracijo nove vrste Monitor Slika 46: Oblikovanje Fluid predloge Monitor.html za prikaz v seznamu Slika 47: Seznam izdelkov Računalništvo in posamezen prikaz izdelka Monitor Slika 48: Seznam izdelkov Šport in prosti čas in posamezen prikaz Obutve Slika 49: Uporaba GET metode za dostop do vira Računalništvo v JSON formatu Slika 50: Vnos novega izdelka s ključem 102 z uporabo HTTP PUT metode Slika 51: Brisanje izdelka z uporabo HTTP DELETE metode s ključem x

12 Seznam uporabljenih kratic API CMS EM HTTP JSON MVC PHP REST TCA TER URI URL XML Application Program Interface Content Management System Extension Manager HyperText Transfer Protocol JavaScript Object Notation Model View Controller Hypertext Preprocessor REpresentational State Transfer Table Configuration Array TYPO3 Extension Repository Uniform Resource Identifier Uniform Resource Locator Extensible Markup Language

13 1 Uvod V današnji informacijski dobi je dejstvo, da si poslovanja brez interneta več ne predstavljamo. Internet je praktično dosegljiv povsod in z njim tudi dostop do globalnega poslovanja. Za večino podjetij predstavlja to že osnovno oziroma temeljno obliko poslovanja. Podjetja se zavedajo, da je internetni marketinški kanal obvezen. Temu primerno svoje izdelke in storitve reklamirajo, predstavljajo ter prodajajo na spletnih straneh in spletnih trgovinah. Izdelke in storitve na različne načine predstavljajo in oglašujejo ter objavljajo vsebino na družbenih omrežjih. Podjetja, ki imajo spletne strani, imajo za te potrebe že izdelana orodja. Administratorji ta orodja posodabljajo, prilagajajo, konfigurirajo, nadgrajujejo itd. Uredniki za objavo spletnih vsebin s pomočjo orodij predstavljajo podjetja, oglašujejo, obveščajo širšo javnost, prodajajo izdelke in storitve, ponujajo znanje ipd. Kadar želijo uredniki objaviti nove vrste spletnih vsebin, lahko administratorji naletijo na težavo, da obstoječe orodje tega ne omogoča. V takšnih primerih lahko administratorji izvedejo nadgradnjo, če le-ta ne presega omejitev obstoječega orodja. Ni pa nujno, da bo ta oblika nadgradnje podjetju zadostovala tudi v prihodnje. Takrat lahko administratorji posežejo po drugem orodju, ki zajema celovito rešitev glede na zahteve urednikov. Izbrano orodje pa je lahko iz vidika funkcionalnosti in namestitve velikokrat preobsežno. Pogosto predstavlja prevelik finančni zalogaj zaradi dodatnih stroškov, kot so nakup dodatne programske in strojne opreme, prilagoditve obstoječih orodij za povezovanje, selitev vsebin iz obstoječe v novo orodje, dodatna kadrovska izobraževanja itd. Od primera do primera je odvisno, ali se nadgradnja splača ali ne. Lahko, da podjetja enostavno niso pripravljena ali iz različnih razlogov preprosto ne morejo investirati vanjo. Pri spremembah spletnih aplikacij je namreč velikokrat pomembno, da so hitro izvedljive, ugodne in kakovostne. 1

14 UVOD 2 Namen diplomske naloge je izdelava spletnega kataloga v orodju TYPO3 CMS, ki brez nadgradnje omogoča izdelavo in objavo novih vrst vsebinskih elementov, kot so: različni izdelki, storitve, novice, dogodki, blogi itd. Predstavili bomo konkretni razvoj spletnega kataloga, ki bo administratorjem omogočal izdelavo novih vrst vsebinskih elementov. Le-te bodo uredniki uporabili pri objavi. Z uporabo spletnega kataloga bo mogoče prilagoditi vrste spletnih vsebin za potrebe urednikov ter se s tem izogniti morebitnim nadgradnjam in z njimi povezanim stroškom. V drugem poglavju bomo spoznali nastanek in razvoj orodja TYPO3 CMS (ang. Content Management System). Predstavljena bo uporaba sistemov za upravljanje spletnih vsebin CMS in njihov življenjski cikel. Pogledali si bomo, zakaj je bilo za izdelavo spletnega kataloga izbrano orodje TYPO3 CMS, in opisali njegovo arhitekturo, delovanje in posebnosti. V tretjem poglavju si bomo pogledali arhitekturni vzorec MVC (Model View Controller) in njegovo uporabo. Predstavili bomo ogrodje Extbase in generator predlog Fluid, na katerem je potekal razvoj spletnega kataloga. Razložili bomo tehniko domensko usmerjenega načrtovanja za pomoč pri izdelavi sheme spletnega kataloga. V četrtem poglavju bomo na kratko predstavili arhitekturni stil REST in metode HTTP za upravljanje virov na določenem URI naslovu. Peto poglavje bomo posvetili pripravi okolja za izdelavo spletnega kataloga in uporabi vtičnika REST (ang. REpresentational State Transfer) API (ang. Aplication Programming Interface). V šestem poglavju bomo razložili namestitev in prilagoditev spletnega kataloga ter na primeru prikazali konkretno izdelavo spletnega kataloga izdelkov z uporabo novih vrst vsebinskih elementov.

15 PREDSTAVITEV ORODJA TYPO3 CMS 3 2 Predstavitev orodja TYPO3 CMS TYPO3 CMS je odprtokodno orodje za upravljanje spletnih vsebin. Namenjeno je malim in srednje velikim podjetjem, ki potrebujejo prilagodljivo in razširljivo orodje za upravljanje spletnih vsebin. 2.1 Zgodovina Programer Kasper Skårhøj je na podlagi takratnih orodij za upravljanje spletnih vsebin ugotovil potrebo po drugačni vrsti orodja. Zato je začel leta 1997 v Kopenhagnu na Danskem s podjetjem Superfish razvijati novo orodje za upravljanje spletnih vsebin. Po dveh letih je podjetje zapustil, da bi se popolnoma posvetil svoji viziji; razvoju TYPO3. Začel je razvijati novo, močnejše in bolj fleksibilno jedro in avgusta 2000 izdal prvo beta verzijo TYPO3 [3], [1]. TYPO3 CMS je uspešno prestal testiranje in skupnost njegovih uporabnikov je začela naraščati. S širjenjem skupnosti so nastale nove ideje in funkcionalnosti, ki so pospešile razvoj. Poleti 2001 so bile izvedene še zadnje izboljšave izvorne kode, čiščenje jedra in definiran koncept razširitev TYPO3 [1]. Septembra 2001 je TYPO3 CMS postal odprtokoden (ang. open source). Do julija 2002, ko se je prvič sestala TYPO3 skupnost, je bil sistem v domeni razvoja enega človeka. Nato se je zasnoval upravitelj razširitev (ang. extension manager EM) sistema. Leta 2003 je izšla verzija TYPO3 3.5 s sistemskimi razširitvami (ang. system extensions). Predstavljen je bil tudi upravitelj razširitev drugih ponudnikov (ang. 3rd party extensions). S to verzijo TYPO3 postane modularen sistem. Od leta 2003 se konstanto objavljajo nove razširitve sistema, ki omogočajo nove funkcionalnosti, in uporaba sistema hitro narašča [1]. Od leta 2004 do danes so bile izdane različne verzije sistema TYPO3 [1]: maja 2004, verzija 3.6, ki predstavi standardni nabor vsebinskih elementov v skladu s XHTML standardom; septembra 2004, verzija 3.7 z izboljšanim, preprostim načinom prevajanja vsebin;

16 PREDSTAVITEV ORODJA TYPO3 CMS 4 maja 2005, verzija 3.8, ki predstavi nov način obdelave slik z zunanjim programom, imenovanim GraphicsMagick, in nov servis za avtentikacijo; aprila 2006, verzija 4.0, z izboljšano uporabniško izkušnjo in dodatnimi funkcionalnostmi (od te verzije naprej se uvršča v sistem za upravljanje vsebin za manjša in srednja podjetja ter za uporabo v bolj kompleksnih projektih); 2009, verzija 4.3, integrira programsko ogrodje Extbase in ogrodje za predloge Fluid (s to integracijo pridobi pomembno funkcionalnost, ki omogoča objektno orientirano programiranje razširitev); januarja 2011, verzija 4.5 LTS prva LTS verzija (ang. Long Term Support); novembra 2012, verzija 6.0, ki ima integriran nov datotečni abstraktni nivo FAL File Abstraction Layer (funkcionalnost zagotavlja hranjenje datotek na poljubnih lokacijah od lokalnega skladiščenja do skladiščenja v oblaku); marca 2014, verzija 6.2 LTS z izboljšano verzijo FAL 2.0 in funkcionalnostjo za gladek prehod iz verzije 4.5 LTS ter novembra 2015, verzija 7.6 LTS z novo»preobleko«in izboljšano hitrostjo delovanja. Do leta 2011 je bil življenjski cikel posamezne verzije vezan na obdobje 12 mesecev, od tega leta dalje pa se življenjski cikel poveča na obdobje 36 mesecev. Sistem TYPO3 se še danes konstantno razvija. Trenutno je v razvoju verzija 8.0 [1]. 2.2 Sistem za upravljanje vsebin (CMS) Sistemi za upravljanje spletnih vsebin ali na kratko sistemi za upravljanje vsebin zagotavljajo zbirko postopkov za uporabo upravljanja delovnega toka vsebin. Ti sistemi omogočajo enostavno in učinkovito ustvarjanje, urejanje, strukturiranje in objavljanje internetnih vsebin. Načeloma ga lahko bolj natančno definiramo, če CMS (Content Management Systems), preberemo nazaj System that ManagesContent (Sistem, ki upravlja vsebine)[4]. Pomembno osnovno načelo sistema za upravljanje vsebin je delitev vsebine od prikaza do postavitve vsebin na spletnem mestu. Uredniki spletnih vsebin zbirajo, ustvarjajo, urejajo in organizirajo vsebino. Na drugi strani pa lahko grafični oblikovalci in programerji učinkovito in neodvisno izdelujejo grafično predlogo ter pripravljajo postavitve za prikaz vsebin. Sistemi za

17 PREDSTAVITEV ORODJA TYPO3 CMS 5 upravljanje vsebin podpirajo upravljanje vsebin skozi celoten življenjski cikel: od ustvaritve, strukturiranja, urejanja, objave do arhiviranja [3], [6] Ustvarjanje in strukturiranje vsebin Ustvarjanje vsebin se začne z zbiranjem informacij. Bistvene informacije uredniki z uporabo urejevalnikov besedil enostavno vnašajo, spreminjajo in povezujejo. Te urejevalnike imenujemo urejevalniki RTE (ang. Rich Text Editor). Delujejo v načinu WYSIWYG (ang. What You See Is What You Get) in so zelo intuitivni. Tako lahko vsebino praktično urejamo povsod in na različnih napravah, brez dodatnega nameščanja programske opreme. Vse, kar potrebujemo je naprava, na kateri se izvaja spletni brskalnik. Vsebino je mogoče kategorizirati, klasificirati in medsebojno povezovati [6], [5] Organizacija vsebin Spletna vsebina je lahko omogočena samo določenim urednikom vsebin. Zato so za določen del vsebine odgovorni samo ustrezni uredniki. Glede na delovni tok so različni uredniki tako odgovorni za različne vsebine. Vsebina se v ozadju shranjuje v repozitorij. V večini primerov repozitoriji predstavljajo podatkovno bazo. Sistem preprečuje nepooblaščen dostop. Znotraj sistema se vodijo dogodki oz. spremembe, kdo, kdaj in na katerem mestu je izvajal spremembe. Tako se lahko v primeru napake povrne prejšnje stanje (ang. rollback) [6], [5] Objava Shranjeno vsebino je možno objavljati in distribuirati na različne načine. Lahko se pripravi vnaprej. Objavi pa se na določen dogodek ali določen čas. Lahko je spletna stran ali del spletne vsebine. Z orodji, ki jih vsebujejo sistemi za opravljanje spletnih vsebin, se lahko vsebina objavlja na različne dele spletnega mesta. Prav tako je mogoče vsebino distribuirati na oddaljene lokacije, kot so druga spletna mesta, socialna omrežja in podobno. Za posamezno objavo lahko uredniki vsebin nastavijo postavitev in videz vsebine, ki je že določena vnaprej [6], [5] Hranjene in arhiviranje Čez čas vsebine niso več aktualne, zato se preprosto umaknejo in tako niso več javno dostopne. S pomočjo vgrajenih orodij se lahko vsebina arhivira na različne načine. Umik vsebin je lahko samodejen glede na določen dogodek ali glede na prednastavljen čas poteka. Upravljavci vsebin lahko vsebino kadarkoli umaknejo in na zahtevo ponovno objavijo.

18 PREDSTAVITEV ORODJA TYPO3 CMS 6 Določene vsebine se lahko prestavijo na del strani, ki je manj aktualen ali viden, npr. iz vhodne strani na podstran. Vsebine se lahko tudi izbrišejo, z možnostjo povrnitve [6], [5]. 2.3 Zakaj TYPO3 CMS Za upravljanje spletnih vsebin obstaja veliko odprtokodnih sistemov. Med seboj so si zelo podobni, tako po funkcionalnosti kot tudi po uporabi. Veliko jih je prilagojenih za prikaz in streženje določeni vrsti spletnih vsebin, kot so spletne strani, blogi, časopisi, spletne trgovine itd. Vprašanje je torej, zakaj bi uporabili ravno TYPO3 CMS in ne kakšen drug CMS. Odgovor najdemo v modularni arhitekturi sistema. Odločitev, da v sklopu teme diplomskega dela uporabimo orodje TYPO3 CMS, je bila na podlagi izkušenj in poznavanju orodja Arhitektura Na podlagi zastavljene arhitekture se sistem lahko razširi v katerokoli smeri, brez da bi izgubil združljivost za nazaj. API (Application Program Interface) za razširitve zagotavlja enostavno dodajanje, odstranjevanje, nameščanje in razvoj razširitev. Upravitelj razširitev (ang. Extension Manager) ima pomembno vlogo pri lažji izmenjavi razširitev. Sistem je na podlagi tega preprosto nadgradljiv in razširljiv, čeprav navzven deluje kot celota. Na voljo je veliko funkcionalnosti, brez dodatnih razširitev ali konfiguracij [1]. Za potrebe novih funkcionalnostih je v TYPO3 Extension Repository (TER) na voljo več kot 1200 aktualnih dodatnih razširitev. V preteklosti jih je bilo več kot 6000, a so bile zaradi nezdružljivosti na novejših verzijah sistema iz repozitorija TER odstranjene. Razširitve so bile narejene s strani skupnosti TYPO3. V kolikor te ne zadoščajo ali ne ustrezajo našim kriterijem, enostavno napišemo lastno razširitev [1]. TYPO3 CMS v samem jedru izvorne kode omogoča razširjanje določenih funkcionalnosti. Za te namene so vgrajeni namenski deli kode, imenovani razširitvene točke (ang. hook). Razširitvene točke so vnaprej definirani programski deli kode, ki se izvajajo ob določenih dogodkih. Imajo to prednost, da se v primeru nadgradnje jedra sistema, ne spreminjajo in ostanejo enaki. Slabost je v tem, da se izvajajo samo na v naprej definiranih mestih in dogodkih. Tako ne moremo izvajati programske kode, kjer koli bi želeli [1]. TYPO3 CMS vsebuje funkcionalnost XCLASS, ki omogoča izvajanje programske kode tudi izven razširitvenih točk. Posamezen razred lahko razširimo in dosežemo, da se lastna programska koda izvaja skoraj povsod. Slabost XCLASS je pri posodobitvah jedra sistema. V

19 PREDSTAVITEV ORODJA TYPO3 CMS 7 določenih primerih se lahko spremeni del izvorne kode ali se ta odstrani. Takrat moramo prilagoditi lastno izvorno kodo [1] Drevesna struktura in vsebina Vgrajeno drevo je osnova za funkcionalnost sistema. Za delovanje potrebuje drevesno strukturo, ki jo lahko izvajamo na več načinov: vleci in spusti (ang. Drag'n drop), s funkcijo ustvari več strani (create multiple pages), s kontekstnim menijem na posameznem listu (left mouse clik on page) ali iz seznama za ustvarjanje zapisov (list view). Spletna stran mora vsebovati vsaj eno stran. Na korensko stran namestimo korensko predlogo, ki označuje vstopno točko za generiranje spletne strani in navigacije. Korenska predloga je predloga TypoScript, označena kot koren (ang. Rootlevel) in jo prikazuje spodnja slika. Slika 1: Drevesna struktura s korensko predlogo. Posamezna stran je lahko različne vrste: splošna stran za prikaz spletnih vsebin (ang. Standard), zaledna stran je na voljo samo v zaledju sistema (ang. Backend),

20 PREDSTAVITEV ORODJA TYPO3 CMS 8 bližnjica za ustvarjanje prevezav (ang. Shortcut), simbolična povezava (ang. Mount point), zunanja povezava (ang. External URL), imenik za vnos poljubnih zapisov (ang. Records), koš za odlaganje smeti (ang. Recycle) in razdelivec menijev za ločevanje v navigaciji in strukturi (ang. Menu separator). Slika 2: Različne vrste strani in različne vrste vsebinskih elementov. Drevesna struktura je za prikaz spletnih vsebin ključnega pomena. Posamezen list v drevesu po navadi predstavlja posamezno področje in nivo spletne strani. Listi so lahko nosilci vsebinskih elementov ali poljubnih zapisov, iz različnih podatkovnih tabel. Vsebinski elementi so vgrajeni v sistem in se na podlagi konfiguracije TypoScript in generatorja predlog Fluid prikazujejo na spletnih straneh. Ostali zapisi se na spletnih straneh prikazujejo na podlagi vtičnikov ali na podlagi konfiguracije TypoScript. Vsebinski elementi različnih vrst se shranjujejo v isto podatkovno tabelo. V kolikor želimo dodati novo vrsto vsebinskega elementa, je potrebno izdelati razširitev. Na voljo so vgrajeni vsebinski elementi (slika 2): naslov (ang. header), besedilo in mediji (ang. text & media), seznam (ang. bullet list),

21 PREDSTAVITEV ORODJA TYPO3 CMS 9 tabela (ang. table), datoteke (ang. file links), meniji (ang. special menus), povezava na zapis (ang. records), vtičnik (ang. plugin), razdelivec (ang. divider), HTML element (HTML), obrazec (ang. form) ali prijavni obrazec (ang. login) Razširitve Jedro sistema je bilo od sistemskih razširitev prvič ločeno v verziji TYPO3 CMS 3.5. V tej verziji se tudi prvič pojavi upravitelj razširitev, ki postane notranji center za upravljanje nove temeljne strukture. Slika 3: Nova arhitektura TYPO3 CMS. Delitev je pokazatelj prihodnje rasti TYPO3, ker omogoča [1]:

22 PREDSTAVITEV ORODJA TYPO3 CMS 10 Enostavno deljenje razširitev: Razširitve je zelo enostavno deliti, saj jih je mogoče z enim klikom prenesti s spleta na splet, jih namestiti ter poganjati na drugih spletnih mestih. Enostavne posodobitve: Z eno akcijo lahko naredimo posodobitve in namestitev. Jedro je ločeno od razširitev, zato ga je enostavno nadgraditi. Hiter razvoj: Z vizualnim orodjem je razširitve enostavno izdelati. Njihova zgradba omogoča, da so datoteke znotraj enega imenika, kar dodatno olajša uporabo, upravljanje in namestitev. Visoko kvaliteto: Razširitve bodo najverjetneje visoke kakovosti zaradi: uporabe API, jasnih smernic kodiranja, dobro definiranih imenskih prostorov (ang. namespaces) in omogočanja ocenjevanja ter komentiranja s strani skupnosti. Dokumentiranje: Zaradi močnega in fleksibilnega zapisovalnika dokumentov OpenOffice lahko razširitve enostavno dokumentiramo. Neomejeno uporabo: Razširitve se lahko integrirajo v skoraj vsak del jedra in s tem omogočajo njihovo neomejeno uporabo. Odgovornost razvijalcev: Modularost omogoča razvijalcu boljšo organizacijo in preglednost posameznih delov TYPO3. Podporo: Uporabnikom nudijo potrebno in enostavno podporo Konfiguracijski jezik TypoScript TypoScript je sintaksa za določanje podatkov z ASCII znaki v hierarhični strukturi. Je konfiguracijski jezik, s katerim ne moremo programirati. Vsebuje samo informacije, kako in v kakšnem zaporedju se izvaja določena vnaprej programirana funkcionalnost. Te informacije se posredujejo programu, ki je zasnovan, da deluje v skladu z informacijami TypoScript podatkovne strukture. Iz programskega vidika bi lahko opisali delovanje TypoScript kot vhodni parametri v programsko funkcijo, katere izhod je definiran s samo funkcijo [1], [2], [3]. Jedro TYPO3 CMS ima na voljo veliko različnih funkcij, ki jih po potrebi lahko poljubno dodajamo ali nadgrajujemo. Na ta način lahko veliko funkcionalnosti dosežemo kar s konfiguracijo TypoScript. Tako lahko na preprost način prikazujemo informacije iz podatkovne baze, izdelujemo kazala, prikazujemo različne menije, izvajamo odločitvene

23 PREDSTAVITEV ORODJA TYPO3 CMS 11 stavke, izvajamo različne prikaze glede na uporabnika, izvajamo različne načine prikaza glede na podatkovno strukturo itd. [1], [2], [3]. 10 = TEXT 10.data = DB:ime_tabele:233:naziv 10.wrap = <h3> </h3> Slika 4: Prikaz podatkov iz podatkovne baze. lib.meni = HMENU lib.meni { 1 = TMENU 1.NO = 1 1.NO.allWrap = <li> </li> 1.ACT = 1 1.ACT.wrapItemAndSub = <li class="aktiven"> </li> 1.wrap = <ul class="nivo1"> </ul> 2 <.1 2.wrap = <ul class="nivo2"> </ul> Slika 5: Prvi in drugi nivo menija. [browser = opera] [browser = firefox] 1 = TEXT 1.value = Opera oz. firefox [else] 1 = TEXT 1.value = Ostali [end] Slika 6: Odločitveni stavek za preverjanje brskalnika. Typoscript je prisoten že od prve verzije TYPO3 CMS in se postopoma nadgrajuje. Neuporabne funkcije se z novejšimi verzijami odstranijo ali nadomestijo z drugimi. Uporaben je samo v TYPO3 CMS in TYPO3 Neos. Brez konkretne konfiguracije prikaz na spletni strani ni izvedljiv. Konfiguracija se shranjuje v posebne vrste zapisov, imenovane predloge (ang. template). Ti zapisi se lahko namestijo na poljubno mesto v drevesni strukturi. Predloge delimo na vrhnjo predlogo (ang. rootlevel template) in razširitveno predlogo (ang.

24 PREDSTAVITEV ORODJA TYPO3 CMS 12 extension template). Vrhnje predloge določajo vstopno točko spletnega mesta, medtem ko razširitvene predloge vrhnje predloge dopolnjujejo. Za prikaz vsebinskih elementov ima TYPO3 CMS že prednastavljeno konfiguracijo, ki jo vključimo v predlogo. Slika 7: Vključitev prednastavljene TypoScript konfiguracije. Vsaka predloga vsebuje konstante (ang. constants) in nastavitve (ang. setup). Sintaksa je v obeh primerih enaka. Konstante se uporabljajo samo za uporabo v nastavitvah. Posamezno konstanto vključimo v področje nastavitev s {$ime.konstante. TypoScript omogoča operatorje za: prirejanje (=), kopiranje (<), brisanje (>), referenco na objekt (=<), izvajanje odločitvenih stavkov ([]). Konfiguracijo lahko na istem ali nižjem nivoju drevesne strukture zmeraj spreminjamo. Konstante in nastavitve lahko zapisujemo tudi v datoteke, ki jih potem z ukaznim stavkom <INCLUDE_TYPOSCRIPT: source="file:datoteka_konfiguracije.txt"> vključimo v predlogo. Na ta način lahko izdelamo majhne konfiguracije (ang. snippets), ki jih neposredno in preprosto sestavljamo in uporabljamo na posameznih vejah drevesne strukture. Snippete lahko po želji vključimo in jih tudi spreminjamo ali celo prepišemo z drugo konfiguracijo [1], [2], [3]. TypoScript lahko pišemo v poljubnem tekstovnem urejevalniku. TYPO3 CMS ima na voljo orodje t3editor, ki omogoča barvanje kode in vsebuje funkcionalnost, ki kodo dokonča (ang. code complete). Ker je TypoScript konfiguracijski jezik in ne programski, je temu primerno napake težje iskati. Za te namene je vgrajeno orodje za analiziranje predloge (ang. template analyzer). Analizator predlog omogoča indikacijo napak in zazna, v kateri predlogi in kateri vrstici se

25 PREDSTAVITEV ORODJA TYPO3 CMS 13 napaka nahaja. Omogoča pregled, na katerih straneh v drevesni strukturi se predloge nahajajo, in pregled števila predlog. TYPO3 CMS vsebuje tudi orodje za lažji pregled konfiguracije, imenovan pregledovalnik objektov oz. gradnikov TypoScript (ang. TypoScript Object Browser). Deluje preprosto, kot brskanje po drevesni strukturi gradnikov. Slika 8: Object Browser za pregled konfiguracije TypoScript Konfiguracija tabel TCA Za definicijo tabel in zapisov se uporablja posebna globalna konfiguracija tabel TCA (Table Configuration Array). TCA je PHP polje, ki zagotavlja pogled in urejanje podatkovnih tabel v zaledju sistema. Podatkovne tabele, ki ne vsebujejo TCA konfiguracije, so v zaledju sistema nevidne. TCA deluje kot konfiguracijska shema med aplikacijo in podatkovno bazo in zagotavlja [1], [2], [3]: relacije med tovrstno tabelo in drugimi podatkovnimi tabelami, prikaz in postavitev podatkovnih polj v zaledju sistema, validacijo podatkovnih polj, informacije za ogrodje Extbase na Frontend (prikaz, kot ga vidijo končni uporabniki). TCA lahko razširjamo na različne načine. Podatkovna polja lahko dodajamo na že obstoječe podatkovne tabele ali ustvarjamo nove podatkovne tabele. V jedru TYPO3 CMS je TCA za določene podatkovne tabele, kot so pages, be_users, tt_content, fe_users, sys_template itd. že na voljo.

26 ARHITEKTURNI VZOREC MVC 14 V razširitvi konfiguracijo za nove podatkovne tabele dodamo v imenik Configuration/TCA/ime_tabele.php. Obstoječe tabele razširimo tako, da v datoteko Configuration/TCA/Overrides/tt_content.php dodamo nova podatkovna polja (slika 9). <?php \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTCAcolumns('tt_content',arr ay( 'podnaslov' => array( 'exclude' => 1, 'label' => 'Dodatno polje podnaslov', 'config' => array( 'type' => 'input', 'size' => '60', 'eval' => 'required' ) ) ));?> Slika 9: Razširitev tabele tt_content z novim poljem podnaslov. Na ta način dosežemo razširljivost obstoječih podatkovnih tabel in zagotovimo, da se ob nadgradnji samega jedra funkcionalnost ne povozi. 3 Arhitekturni vzorec MVC Arhitekturni vzorec MVC je bil zasnovan kot splošna rešitev problema uporabnikov za nadzor velike količine in kompleksnega nabora podatkov. Ideja, ki jo predstavlja slika 3.1, je bila premostiti vrzel med digitalnim in človeškim duševnim modelom, ki obstaja v računalniku [7].

27 ARHITEKTURNI VZOREC MVC 15 Slika 10: Predstavitev ideje za premostitev iz mentalnega v računalniški model. 3.1 Zgodovina Prve zapiske je leta 1978 napisal Trygve M. H. Reenskaug. Zapiski so definirali štiri termine: model (ang. model), pogled (ang. view), krmilnik (ang. controller) in urednik (ang. editor). Urednik je kratkotrajna komponenta, ki ustvarja pogled na zahtevo. Je vmesnik med pogledom in vhodno napravo, kot na primer miška in tipkovnica. Za različne arhitekturne komponente so se najprej oblikovala imena Model-View-Editor. Leta 1979 so dobile ime Thing-Model-View-Editor [7]. Posamezne komponente pomenijo [7]: Stvar Nekaj, kar je v interesu uporabnika. Lahko je stvarno, kot npr. beton, hiša, avtomobil, ali abstraktno, kot nova ideja ali neko mnenje. Lahko pa je tudi zaključena celota, kot je npr. računalnik ali pralni stroj in podobno. Model Je aktivna predstavitev abstrakcije v obliki podatkov v računalniški sistem. Pogled Ponazarja eno ali več različnih predstavitev modela. Za vsak model obstaja eden ali več pogledov. Na pogledu je mogoče izvajati različne predstavitve modela, ki so razumno povezane s tem pogledom. Urednik Je vmesnik med uporabnikom in enim ali več pogledov. Uporabniku omogoča ustrezen ukazni sistem, pogledom pa zagotavlja potrebno usklajevanje in ukazna sporočila. Kasneje istega leta, 1979, so se Thing-Model-View-Editor preoblikoval v Models-Views- Controllers na kratko MVC.

28 ARHITEKTURNI VZOREC MVC 16 Posamezne komponente pomenijo [7]: Modeli So lahko predmet ali struktura več predmetov in predstavljajo znanje. So preslikava sveta, kakršno imajo lastniki modela. Pogledi So predstavitveni nivo modela. Pogledi običajno izpostavijo določene lastnosti modela in zatirajo druge. Delujejo kot predstavitveni filter. Pogled je vezan na njegov model ali del njegovega modela. Na podlagi zahtevkov pridobiva od modela potrebne podatke za predstavitev. S pošiljanjem ustreznih sporočil lahko model posodobijo. Ti zahtevki in sporočila morajo biti del terminologije modela. Zato morajo pogledi poznati semantiko lastnosti modela. Krmilniki So povezava med uporabnikom in sistemom. Uporabniku, glede na vnose, omogočajo ustrezne poglede na primernih mestih. Prejemajo uporabniške vnose in jih prevedejo v ustrezna sporočila, ki jih posredujejo na enega ali več pogledov. 3.2 Uporaba MVC je bil prvič uporabljen v jeziku Smalltalk-80 leta Od nastanka do danes se je predstavitveni nivo spremenil in s tem tudi definicija njegovega vzorca. Sčasoma so se razvili tudi drugi vidiki MVC, ki so izpeljanka originalnega vzorca MVC [8]. Vzorec MVC je iz različnih vidikov dobro uveljavljen pristop k izgradnji programske opreme. Glavna prednost je ločevanje skrbi (angl. separation of concerns). Ločitev na tri komponente omogoča ponovno uporabo poslovne logike v vseh aplikacijah, boljšo organizacijo in razvoj več uporabniških vmesnikov ter pogledov. Podvajanje kode se omeji zaradi ločene podatkovne in poslovne logike od pogleda. Model vrača neoblikovane podatke, zato lahko iste komponente uporabimo s katerimkoli vmesnikom. Zaradi svoje kompleksnosti je zapleten za izvedbo in ni primeren za majhne projekte, pri načrtovanju programske opreme pa zahteva dodaten napor [8]. Vzorec MVC, ki je bil predstavljen v sedemdesetih letih je bil zasnovan na podlagi namiznih in osebnih aplikacij. MVC krmilniki naj bi prevajali vnose uporabnikov v ukaze za pogled in model: klik z miško, pritisk tipke, dotiki, kretnje in drugo. Pogledi naj bi bili neposredno sposobni reagirati na vnos uporabnika in tudi reagirati na spremembe v modelu. Zato ta klasični model, na strani strežnika, ne odraža načina delovanja spletnih aplikacij [8].

29 ARHITEKTURNI VZOREC MVC 17 Z obdelavo zahtevkov HTTP (ang. Hypertext Transfer Protocol) preko strežnikih komponent spletne aplikacije omogočajo prikaz dinamičnih vsebin na spletnih straneh. Zaradi same narave protokola HTTP spletne aplikacije spadajo v "stateless" arhitekturo. Za njih obstaja samo vhod preko HTTP zahtevka, zato je stanje odvisno samo od vhodnih parametrov [9]. Pogledi se ob vsakem zahtevku generirajo vedno na novo. Zaradi tega klasični vzorec MVC ne odraža natančnega delovanja spletnih aplikacij in je za razvoj teh pogosto prilagojen. Pogledi v spletnih aplikacijah vsebujejo več kot samo predstavitev modela. Krmilniki so zadolženi za upravljanje zahtevkov. Med zahtevkom uporabnika in stranjo, ki jo uporabnik prejme kot rezultat, ni neposredne sklopitve. Pogledi pridobijo podatke s strani krmilnikov, ki delujejo kot posrednik med modelom in pogledi. Posledično pogledi nimajo neposrednega dostopa do podatkov. Za razvoj spletnih aplikacij so se razvila tudi ogrodja za spletne aplikacije (ang. web application frameworks). Ogrodja za spletne aplikacije so zbirke predhodno oblikovanih razredov in funkcij. Njihov namen in cilj je fokusiranje razvijalcev in oblikovalcev na posamezne funkcionalnosti projektov, brez ponovnega razvijanja že obstoječih zadev. Večina teh ogrodij že uporablja vzorec MVC in tudi druge načrtovalske vzorce kot so: prototip (ang. prototype), tovarna (ang. factory), edinec (ang. singleton), injiciranje odvisnosti (ang. dependency injection) itd. Različni vzorci so nastali z razlogom, da bi odpravili določene specifične izzive, saj so rešitve le-teh pogosto zelo podobne. S tem ogrodja uveljavljajo dobro razvojno prakso in še dodatno pripomorejo k reševanju izzivov in boljši kodi. V praktično vsakem programskem jeziku obstaja veliko različnih ogrodij [11], [12]. Prednosti ogrodij za spletne aplikacije [12]: odprtokodnost (Večina ogrodij je odprtokodnih in s tem prostih za uporabo.) dokumentacija in podpora (Čeprav je odvisno od popularnosti posameznega programskega jezika, obstaja velika možnost, da ima dobro podporo in dokumentacijo. Včasih je potrebno za podporo tudi plačati.) učinkovitost (Gre za glavni argument, zakaj sploh obstajajo in zakaj jih uporabiti. Odpravljajo potrebo po pisanju ponavljajoče programske kode, ki se uporabljajo v različnih aplikacijah.) varnost (Ogrodja razvija več razvijalcev in je zato zelo verjetno, da so varnostna tveganja na preizkušnji že v času razvoja. Nova varnostna tveganja so tako tudi hitro obravnavana in odpravljena.)

30 ARHITEKTURNI VZOREC MVC 18 integracija (V večini spletnih aplikacij se v ozadju za shranjevanje uporabljajo podatkovne baze. Ogrodja tako omogočajo lažje povezovanje in komunikacijo za dostop do podatkov.) Slabosti ogrodij za spletne aplikacije [12]: omejitve (V primeru omejitev, izvorne kode samega jedra ne moremo spreminjati, zato smo prisiljeni uporabljati delovanje, kot je predvideno.) zmogljivost (V osnovi se ogrodja počasneje izvajajo in nalagajo.) učenje (Učimo se uporabo samega ogrodja in ne programskega jezika. Včasih se ga je težko naučiti in še težje obvladati.) cena (Zahtevajo več strokovnega znanja in izkušenj za razvoj, kar lahko zaradi dolgotrajnega procesa učenja poveča stroške razvoja.) 3.3 Ogrodje Extbase Jochen Rau je za TYPO3 CMS razvil razširitev Extbase, v katerega je implementiral funkcionalnosti spletnega aplikacijskega ogrodja TYPO3 Flow. Extbase je sistemska razširitev TYPO3 CMS, ki temelji na domensko usmerjenem načrtovanju (glej 3.4). Ogrodje zagotavlja delovanje in nov način izdelave vtičnikov. Extbase je eksplicitno vezan na jedro TYPO3 CMS, medtem ko je TYPO3 Flow samostojno ogrodje za izdelavo aplikacij [13]. Razvijalci TYPO3 Flowa so z veliko pozornostjo izbrali funkcije, tehnologije in metodologije, ki jih z veliko pozornostjo združujejo. To ogrodje tako združuje številna načela načrtovanja programske opreme in bistveno pospešuje proces razvoja [13]: Domensko usmerjeno načrtovanje (Domain Driven Design DDD), Vzorec Model Pogled Krmilnik (Model View Controller MVC), Aspektno orientirano programiranje (Aspect Oriented Programming AOP), Injeciranje odvisnosti (Dependency Injection DI). Iz TYPO3 Flowa so bile v Exbase prilagojene le najvažnejše funkcionalnosti, kot so: MVC ogrodje, osnovne metode Domensko usmerjenega načrtovanja in Fluid za izdelovanje predlog.

31 ARHITEKTURNI VZOREC MVC 19 V ogrodju Extbase se uporablja UpperCammelCase in lowercammelcase sintaksa za imenovanje razredov in razrednih lastnosti. Za ločevanje istoimenskih razredov pa imenski prostori (ang. namespaces). Vse razredne lastnosti, razen posameznih notranjih izjem, so zaščitene (ang. protected) in večina metod je javnih (ang. public). Upravljajo se preko metode get in set. Najpogostejši programski vzorci, ki se uporabljajo v ogrodju Extbase [13]: Edinec (Singleton), Prototip (Prototype) in Injeciranje odvisnosti (Dependency Injection) Vzorec Edinec Med razvijanjem objektno orientirane programske opreme (OOP) imamo opravka z veliko razredi. Idealno je, da razrede načrtujemo za uporabo več aktivnih primerkov hkrati. Včasih je potrebno, da je aktiven samo en primerek razreda hkrati. Za te namene se uporablja programski vzorec edinec, ki vzdržuje en primerek samega sebe v notranji statični lastnosti. Njegov primerek se ne more ustvariti ali klonirati, kot se lahko običajni razredi. Edinci vsebujejo posebno metodo primerka, kot jo prikazuje slika 11, in vrnejo ali ustvarijo nov notranji primerek [14]. Slika 11: Razred Edinec s posebno metodo primerka. Programski vzorec edinec se v ogrodju Extbase uporablja z vključitvijo vmesnika (ang. Interface) SingletonInterface na posamezen razred Vzorec Prototip Prototip je ravno nasprotno od edinca in zagotavlja, da je ustvarjen vedno nov primerek, kadar je to potrebno. Razredi v ogrodju Extbase so privzeto obravnavani kot prototip [13].

32 ARHITEKTURNI VZOREC MVC Vzorec Injeciranje odvisnosti Injeciranje odvisnosti je programsko načrtovalski vzorec, ki poenostavlja reševanje odvisnosti od objektov. Uporablja se za obratni nadzor sprostitve objekta od nepotrebnih povezav, ki so potrebne za reševanje svoje odvisnosti. Odgovornost za reševanje odvisnosti se z objekta prenese na ogrodje. V ogrodju Extbase se uporablja način injeciranje odvisnosti z metodo in način injeciranje odvisnosti z anotacijo [13]. <?php class Content extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity { /** * Content repository * \UZ\Catalog\Domain\Repository\ContentRepository */ protected $contentrepository = NULL; public function injectcontentrepository(\uz\catalog\domain\repository\contentrepository $contentrepository) { $this->contentrepository = $contentrepository;?> Slika 12: Injeciranje odvisnosti z metodo. <?php class Content extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity {?> /** * Content repository * \UZ\Catalog\Domain\Repository\ContentRepository */ protected $contentrepository = NULL; Slika 13: Injeciranje odvisnosti z anotacijo. Ogrodje Extbase uporablja posebne anotacije (ang. annotations), ki predstavljajo metapodatke za uporabo pri metodah, lastnostih in razredih. Anotacije v programski kodi uporabljajo svojo sintakso, ki se preko posebnega programskega vmesnika Reflection API, prevajajo v novo izvajalno kodo. Anotacije so komentar v izvorni kodi, ki se vedno začnejo z /**. Posamezna anotacija je označena z in kodi dodaja dodatno funkcionalnost [13]. Ogrodje omogoča nalaganje odvisnih objektov z odlogom (ang. lazy loading). Privzeto se ti vedno naložijo (ang. eager loading). Z nalaganjem objektov z odlogom dosežemo, da se med

33 ARHITEKTURNI VZOREC MVC 21 izvajanjem objekti naložijo le takrat, ko so dejansko zahtevani. Posamezno lastnost modela v ogrodju označimo z anotacijo»lazy«. <?php class Content extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity {?> /** * Media elements * \UZ\Catalog\Domain\Model\Media */ protected $media = NULL; Slika 14: Nalaganje razrednih lastnosti z lazy loadingom. Za obdelavo domenskih modelov ogrodje Extbase uporablja repozitorije. Domenski repozitoriji za uporabo dedujejo repozitorij \TYPO3\CMS\Extbase\Persistence\Repository. S tem pridobijo določene obstoječe metode [13]. Metode za pisanje: add($objekt), za dodajanje novih objektov, remove($objekt), za brisanje obstoječih objektov, removeall(), za brisanje vseh objektov in update($objekt), za posodobitev obstoječih objektov. Metode za branje: findall(), pridobivanje vseh objektov, countall(), prešteje objekte, findbyuid($uid), iskanje objektov po ključu in findby ImeLastnosti ($lastnost), iskanje objektov po lastnostih. Kadar obstoječe metode ne zadostujejo, lahko dodamo lastne metode ali razširimo že obstoječe. Na podlagi povpraševalnega (ang. Query) objekta lahko sestavimo povpraševanje na poljuben način. Objekt Query omogoča določanje naslednjih kriterijev (ang. Constraints) [13]:

34 ARHITEKTURNI VZOREC MVC 22 equals($imelastnosti, $operand) vrne objekte, katere vrednost lastnosti se ujema z operandom. in($imelastnosti, $operand) vrne objekte, katere vrednost lastnosti je vsebovana v večvrednostnem operandu. contains($imelastnosti, $operand) vrne objekte, katere vrednosti lastnosti so vsebovane v operandu. like($imelastnosti, $operand) na podlagi lastnosti vrne objekte, ki vsebujejo operand. lessthan($imelastnosti, $operand) vrne objekte, katere vrednost lastnosti je manjša od operanda. lessthanorequal($imelastnosti, $operand) vrne objekte, katere vrednost lastnosti je manjša ali se ujema z operandom. greaterthan($imelastnosti, $operand) vrne objekte, katere vrednost lastnosti je večja od operanda. greaterthanorequal($imelastnosti, $operand) vrne objekte, katere vrednost lastnosti je večja ali se ujema z operandom. Objekt Query omogoča logične operatorje [13]: logicaland($kriterij) omogoča logično operacijo in med posameznimi kriteriji logicalor($kriterij) omogoča logično operacijo ali med posameznimi kriteriji logicalnot($kriterij) omogoča logično operacijo ne med posameznimi kriteriji 3.4 Domensko usmerjeno načrtovanje Zasnova in razvoj programske opreme je vedno ustvarjalni proces, kjer se iščejo pametne rešitve za reševanje izzivov. Za popolno razumevanje poslovnih procesov in aktivnosti je pri programski zasnovi potrebno tesno sodelovanje z naročnikom. Tako je domena naročnika v središču programske zasnove. Izraz domensko usmerjeno načrtovanje (ang. Domain Driven Design) je v svoji knjigi skoval Eric Evans "Domain Driven Design: Tackling Complexity in the Heart of Software" [13].

35 ARHITEKTURNI VZOREC MVC 23 Najbolj izpostavljene zadeve pri DDD so [15]: DDD je razvojna filozofija, ki je namenjena za upravljanje vzpostavitev in vzdrževanje programske opreme pri kompleksnih problemskih področjih. DDD je zbirka vzorcev, načel in praks, ki se lahko uporabljajo za načrtovanje programske opreme za upravljanje kompleksnosti. DDD ima dve vrsti vzorcev. Strateški vzorci oblikujejo rešitev, medtem ko se taktični vzorci uporabljajo za izvajanje bogatega domenskega modela. Strateški vzorci so lahko koristni za katerokoli aplikacijo, taktični vzorci pa le v primeru, da je model dovolj bogat z domensko logiko. Ločevanje velikih problemov domene na poddomene lahko razkrije jedro domene, kar je največja vrednost. Vsi deli sistema ne bodo dobro zasnovani. Več časa zato vložimo v zasnovo osrednjih poddomen. Za reševanje problemov domen je za vsako poddomeno ustvarjen abstraktni model. Učenje in ustvarjanje jezika za komunikacijo problemskega področja je proces DDD, ki se uporablja za sodelovanje razvojne ekipe in strokovnjakov pri oblikovanju modela. Model je za ohranjanje integritete opredeljen v ograjenem kontekstu. Zaradi ločitve tehničnih zapletenosti od poslovnih zapletenosti je izoliran od infrastrukturnih skrbi. Če v terminologiji za model obstaja dvoumnost, se lahko razdeli in opredeli na manjše vezane kontekste. DDD za razvoj ne narekuje posebnega arhitekturnega sloga, temveč le zagotavlja, da je model izoliran od tehničnih podrobnosti in se tako lahko osredotoči na skrbi domenske logike. DDD vrednoti: osredotočenje na jedro domene, sodelovanje in raziskovanje s strokovnjaki za posamezna področja, poskuse za doseganje bolj uporabnega modela. DDD je filozofija sodelovanja z osredotočanjem na dostavo oz. dobavo z osrednjo komunikacijsko vlogo. DDD je domensko usmerjen jezik k razvoju programske opreme.

36 ARHITEKTURNI VZOREC MVC 24 Osrednja zahteva DDD narekuje, da se načrtovanje programske opreme izvaja skozi model. Model je poenostavljen opis realnosti, usmerjen v posebne namene. Predstavlja odnose med predmeti in njihovimi lastnostmi. DDD zahteva večplastno arhitekturo, ki se v Extbase izvaja v okviru vzorca MVC [13]. Slika 15: DDD pri poteku programa aplikacije TYPO3 CMS/Extbase. [13] 3.5 Generator predlog Fluid Fluid je generator predlog, ki zagotavlja prilagodljiv koncept za doseganje različnih postavitev posameznih modelov. S Fluidom zlahka dosežemo ločevanje pogledov od drugih delov aplikacije. Uporablja se pri generiranju predlog posameznih razširitev TYPO3 CMS, generiranju postavitev vsebinskih elementov ali kot samostojna uporaba. Pri generiranju postavitev generator predlog Fluid uporablja tri osnovne gradnike [1], [13] Predloge Predloge (ang. templates) so datoteke HTML, ki so izhodiščna točka pri izdelavi posameznih pogledov. S pomočjo Extbase ogrodja se glede na krmilnik in izvajanje akcije, predloge samodejno naložijo. Pri izvajanju akcije list krmilnik Catalog samodejno naloži datoteko.../resources/private/templates/catalog/list.html. Datoteke so lahko v odvisnosti od konteksta tudi drugačnega formata. Tako lahko za predloge uporabimo poljubne končnice datotek [13]. Glavna prednost Fluid je v izdelavi lastnih pomočniki pogledov (ang. ViewHelper). Privzeto Fluid vsebuje že veliko ViewHelper-jev. Glavni gradniki so: postavitve, delne predloge in sekcije. ViewHelper-ji se začnejo z značko <f:imeviewhelperja> in končajo z

37 ARHITEKTURNI VZOREC MVC 25 značko </f:imeviewhelperja>. Slika 16: Zgradba in izvajanje Fluid prikazuje, kako se določeni gradniki v Fluidu izvajajo. Slika 16: Zgradba in izvajanje Fluid. Fluid uporablja tudi inline ViewHelper notacijo, ki pride v poštev pri kompleksnejši uporabi, kot je: <f:translate key="datum" arguments="{0: '{f:format.date(date: data.crdate, format: \'d.m.y H:i:s\')'" /> Postavitve Postavitve (ang. layouts) se uporabljajo za globalno oblikovanje in za postavitev celotne aplikacije. Postavitev se določi z značko <f:layout name= ImePostavitve /> Delne predloge Delne predloge (ang. partials) so majhne enote predlog, ki se uporabljajo za izpolnjevanje ponavljajočih se nalog. Delujejo na podoben način kot programske funkcije. Uporabljajo se lahko po celotni aplikaciji ali spletišču in omogočajo vključitev vsebin iz enega vira na več mestih. Z značko <f:render partial="delnapredloga" arguments="{naziv:"klic delne predloge", tip:3" /> pokličemo poljubno delno predlogo, v katero pošljemo poljubne argumente za prikaz [1], [13] Sekcije Sekcije se uporabljajo za lokalno izvajanje v glavnih gradnikih. Delujejo na podoben način kot delne predloge. Z značko <f:render section="sekcija" arguments="{naziv:"lokalna sekcija"" /> izvajamo klic na posamezno sekcijo [1], [13].

38 ARHITEKTURNI STIL REST 26 4 Arhitekturni stil REST Arhitekturni stil REST (ang. REpresentational State Transfer) je preprost način za organizacijo interakcij med neodvisnimi sistemi. Zagotavlja prilagodljiv, odporen in enostavno razširljiv sistem. Osnovni koncepti REST so stari toliko, kot je star sam internet. Izraz REST je leta 2000 v doktorski dizertaciji "Network based software architectures" [18] prvi uvedel Roy Fielding. REST omogoča komunikacijo med računalniki, za ljudi pa hkrati omogoča lažje razumevanje za podatke, ki se prenašajo. Principi arhitekturnega stila REST so [10]: Identifikacija virov Na internetu so podatki predstavljeni v obliki spletnih strani, slik, videov, datotek itd. Pri REST je zato pomembno, da o teh podatkih razmišljamo v smislu virov, ki za identifikacijo na spletu uporabljajo enoten koncept URI (Uniform Resource Identifier). Povezovanje virov Jedro povezovanja virov je hipermedija kot pogon stanja aplikacije (HATEOAS Hypertext As The Engine Of Application State). Hipermedija je že poznan princip s HTML in omogoča povezovanje virov na drugem strežniku ali z druge aplikacije na določenem URI. To povezovanje omogoča odjemalcu, da se s sledenjem povezav premika po aplikaciji iz enega stanja v drugo. Uporaba standardnih metod Za odjemalce je zagotovljen nabor akcij, ki se lahko izvajajo za upravljanje virov. Za te namene se uporablja protokol HTTP, ki privzeto vsebuje standardne metode GET, POST, PUT, PATCH, DELETE. Predstavitev virov Za predstavitev virov se pri REST za različne potrebe uporabljajo različni predstavitveni formati kot so HTML, XML, JSON, VCard itd. Tako se lahko odjemalci odločijo, katero predstavitev uporabijo. Komunikacija brez stanj Strežnik za posamezne odjemalce ne hrani stanja virov, ampak se le-ti hranijo na strani odjemalca ali pa so lahko predstavljeni v obliki vira. Komunikacija brez stanj odjemalce izolira od sprememb na strežniku, saj dva zaporedna zahtevka na isti strežnik med seboj nista odvisna. Ključna načela REST vključujejo ločevanje API v logične vire in zagotavljajo strategije za ravnanje akcij CRUD (Create Read Update Delete) z uporabo HTTP protokola. Za lažje

39 IZDELAVA SPLETNEGA KATALOGA 27 razumevanje API odjemalcev za vire po navadi uporabljamo samostalnike. Vire upravljamo na podlagi HTTP z metodami [17], [19]: GET Metoda je najpreprostejša vrsta metode HTTP zahtevka. Spletni brskalniki jo vsakič uporabljajo, ko kliknemo povezavo ali vnesemo URL v naslovno vrstico. Metoda za prenos podatkov odjemalcu da strežniku navodilo. Na podlagi metode GET se na strani strežnika podatki nikoli ne bi smeli nikoli manipulirati. V tem smislu se ti zahtevki uporabljajo samo za branje [19]. POST Metoda se na strežniku uporablja za ponavljanje istih procesov. Večinoma se uporablja za ustvarjanje virov, redko pa za posodabljanje. Podatki se vedno pošiljajo v telesu zahtevka [20]. PUT Metoda se uporablja pri ustvarjanju ali posodobljanju vira na določenem URLju. Podatki za ustvarjanje ali posodobitev se pošiljajo v telesu zahtevka [19], [20]. PATCH Metoda se lahko uporablja za posodabljanje določenega dela virov. Za primere, ko je potrebno posodobiti samo določen del vira. S tem tudi zagotavljamo manjšo pasovno širino pri pošiljanju podatkov [20]. DELETE Metoda ima nasproten pomen od metode PUT. Uporablja se za brisanje virov identificiranih na določenem URL-ju [19]. 5 Izdelava spletnega kataloga Ideja za izdelavo spletnega kataloga je nastala predvsem zaradi omejitve vgrajenih vsebinskih elementov. Pri izdelavi razširitve je bilo razširjeno delovanje jedra TYPO3 CMS. Razvoj je najprej potekal na verziji TYPO3 6.2 LTS in se je tekom razvoja zaradi posodobitve jedra nadaljeval na verziji TYPO3 CMS 7.6 LTS. Zaradi sprememb izvajanja izvorne kode v novejši verziji je bila na razširitvi tekom razvoja potrebna korenita sprememba izvorne kode. Razširitev razširja delovanje vgrajenih vrst vsebinskih elementov. Deluje kot celota in jo je možno namestiti na poljubno instanco TYPO3 CMS verzije 7.6 LTS.

40 IZDELAVA SPLETNEGA KATALOGA Obstoječe rešitve V TYPO3 TER obstaja razširitev Dynamic Content Elements (DCE), ki omogoča izdelavo lastnih vsebinskih elementov z dodajanjem novih lastnosti in uporabo obstoječih [21]. Omogoča veliko funkcionalnosti, ki so tudi bile razvite v spletnem katalogu. Največja težava pri obstoječi rešitvi je v zaledju delovanja. Pri nastajanju novih lastnosti se podatki teh lastnosti za posamezen vsebinski element shranjujejo v eno veliko XML polje. Na ta način težje pridobivamo podatke iz podatkovne baze. Obstoječa rešitev prav tako ne omogoča dodajanje novih skupin vsebinskih elementov in ne vsebuje REST API. Razširitev DCE pa je bila inspiracija pri izdelavi razširitve spletni katalog. 5.2 Okolje za izdelavo Pri izdelavi je bila uporabljena razširitev Extension Builder. Izvorna koda je napisana v razvojnem orodju Eclipse za PHP razvijalce, verzija Mars. Eclipse razvijalcem omogoča pomoč pri pisanju kode, tako da poudarja in označuje sintakso za lažje branje in prepoznavanje posameznih odsekov in kategorij. Dodaja možnost končanje kode (ang. code completion) in pomaga pri upravljanju datotek in strukturi izvorne kode. Za upravljanje podatkovne baze je bilo uporabljeno orodje Navicat. Za izdelavo razširitev TYPO3 CMS je bilo potrebno zagotoviti ustrezno okolje. Zaradi same arhitekture sistemov za upravljanje spletnih vsebin je bilo potrebno najprej namestiti spletni strežnik. Za delovanje TYPO3 CMS se lahko uporabljajo spletni strežniki Apache, IIS ali NGINX, ki se namestijo na operacijske sisteme Unix, Windows ali Mac. Za streženje zahtevkov se je na aplikacijskem nivoju uporabljal skriptni jezik PHP (Hypertext Preprocessor). Na persistentnem nivoju se je za hranjenje podatkov uporabljala podatkovna baza MySQL. Privzeto TYPO3 CMS uporablja podatkovno bazo MySQL. Z namestitvijo razširitve DBAL (Database Abstraction Layer) razširimo nabor podatkovne baze na: PostgreSQL, Oracle, Firebird in MSSQL [1]. Pri izdelavi spletnega kataloga je bil zaradi priporočil TYPO3 [1] nameščen spletni strežnik Apache, verzija , na operacijskem sistemu Mac OS. Uporabljeni sta bili verzija PHP in podatkovna baza MySQL, verzija Delo s TYPO3 CMS je potekalo v spletnem brskalniku Chrome in Safari. Pri testiranju REST API je bil uporabljen Chrome vtičnik ARC (Advanced REST Client).

41 IZDELAVA SPLETNEGA KATALOGA Izdelava razširitve spletnega kataloga Naša razširitev spletnega kataloga temelji na ogrodju Extbase, zato je bila potrebna predhodna namestitev TYPO3 CMS. Zaradi lažjega razvoja in odpravljanja napak je v času razvoja TYPO3 CMS deloval v načinu debug Modeliranje Razširitev Extension builder omogoča izdelavo razširitev z domenskim modeliranjem in poskrbi za: skelet razširitve oz. potrebno strukturo datotek in imenikov, kreiranje osnovnih razredov domenskih modelov, kreiranje podatkovnih tabel in TCA domenskih modelov, kreiranje jezikovnih datotek, konfiguracijo vtičnikov in kreiranje CRUD (Create, Read, Update, Delete) akcij za korenske modele. Pri izdelavi razširitve je bilo potrebno določiti ime, ki določa prepoznavnost razširitve in proizvajalca (ang. vendor) ter služi pri generiranju imenskih prostorov domenskih razredov. Potrebna je bila tudi definicija ključa (ang. key) za določanje unikatnega imena razširitve in zagotavljanje unikatnosti na posamezni namestitvi TYPO3 CMS. Za spletni katalog je bil izbran ključ catalog. Razširitvi smo dodali vtičnik za prikaz na spletni strani. Vtičniku smo določili ključ catalog, ki mora biti znotraj razširitve edinstven. Za vtičnik smo določili, katere akcije se lahko na krmilniku izvajajo. Za potrebe razširitve so nastali krmilnik catalog ter akciji list in show (Content => list, show). Akcija list omogoča prikaz seznama izdelkov. Akcija show pa omogoča prikaz posameznega izdelka. V grafičnem načinu za modeliranje domene smo izdelali shemo. Posameznemu domenskemu modelu smo z notacijo UpperCamelCase določili edinstven naziv. Domenskemu modelu smo določili vrsto entiteta ali vrsto vrednostni objekt. Za izdelavo spletnega kataloga smo uporabili korenski domenski model Content. Domenski model Content je bil nosilec vseh domenskih modelov. Vsak posamezen korensko domenski model je bil označen z Is aggregate root, na podlagi katerega je bil ustvarjen repozitorij. Pri

42 IZDELAVA SPLETNEGA KATALOGA 30 izdelavi sheme smo na domenskem modelu Content označili v naprej definirana podatkovna polja: omogoči razvrščanje (zapisi se v backendu razvrščajo glede na razvrstitveno polje), dodaj podatkovno polje izbrisano (kadar izbrišemo določen zapis, ga je možno povrniti), dodaj podatkovno polje skrito (doda možnost za začasno skrivanje zapisov), dodaj podatkovno polje datum objave in datum veljavnosti (za manipulacijo objave) in omogoči kategorizacijo (kategorizacija na podlagi vgrajenih sistemskih kategorij). Za uporabo podatkovnih tabel, ki v sistemu že obstajajo, je bilo potrebno izvesti mapiranje. V posebej predvideno polje Map to existing table smo vnesli ime tabele, ki se je uporabljal za domenski model. Ker je bil Content nosilen domenski objekt in se je uporabljal za razširitev vsebinskih elementov, je bila uporabljena podatkovna tabela tt_content. Za primere obstoječih domenskih modelov, je bilo izvedeno enako kot v primeru podatkovnih tabel. Slika 17: Izdelava domenskega modela Content za obstoječo tabelo tt_content. Posameznemu modelu smo dodajali lastnosti in relacije. Lastnosti so morale imeti edinstven naziv. Vsebovale so lahko samo alfanumerične znake v lowercamelcase notaciji. Lastnosti smo določili vrsto (slika 17), na podlagi katere se je ustrezno generiral TCA. Možnosti vrst lastnosti so bile: niz, besedilo, besedilo z urejevalnikom, geslo, celoštevilčna vrednost, decimalna vrednost, logočna vrednost itd. Pri relacijah je veljalo enako pravilo kot pri lastnostih. Relacije se povezave na drug ali isti domenski model. Ustvarili smo jih z načinom povleci in spusti iz enega na drug ali isti model.

43 IZDELAVA SPLETNEGA KATALOGA 31 Posamezni relaciji smo določili kardinalnost 1 : 1, 1 : n, n : 1, m : n (slika 17). Posamezni relaciji smo določili tudi način nalaganja objektov. Za odloženo nalaganje smo označili Lazy loading (slika 17). Za lastnosti, ki so že obstajale, je bilo potrebno navesti pravilen naziv (lowercamelcase). Za uporabo lastnosti v domenskem razredu smo izvedli mapiranje s konfiguracijo TypoScript: config.tx_extbase.persistence.classes{ UZ\Catalog\Domain\Model\Content { mapping { tablename = tt_content columns { crdate.maponproperty = crdate tstamp.maponproperty = tstamp // Mapping ostalih vgrajenih lastnosti Slika 18: Mapiranje obstoječih lastnosti na domenski model Content. Posamezen domenski model se je v ozadju pretvoril v PHP razred. Pri razširitvi catalog se je za domenski model Content generiral PHP razred Content.php. Za posamezno lastnost in relacijo se je generirala ustrezna get in set metoda. <?php namespace UZ\Catalog\Domain\Model; /** * Content */ class Content extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity { /** * crdate * \DateTime */ protected $crdate = NULL; /** * Returns the crdate * \DateTime $crdate */ public function getcrdate() { return $this->crdate;?> /** * Sets the crdate * $crdate void */ public function setcrdate($crdate) { $this->crdate = $crdate; Slika 19: Generirana izvorna koda razreda Content za domenski model Content.

44 IZDELAVA SPLETNEGA KATALOGA 32 Na domenskem modelu smo določili akcije, ki so bile navedene pri vtičniku Catalog. S tem smo ustrezno ustvari krmilnik. Določene akcije, ki so bile na voljo, smo označili in poljubno dodali (slika 17). Pri domenskem modeliranju spletnega kataloga so nastali naslednji domenski modeli (slika 20): Content je korenski model, ki razširja obstoječe vsebinske elemente na podlagi obstoječe podatkovne tabele tt_content. Vse vrste vsebinskih elementov uporabljajo ta model kot osnovo za prikazovanje. ContentGroup je model za novo podatkovno tabelo za dodajanje novih skupin in ločevanje posameznih vrst vsebinskih elementov ter za boljšo uporabniško izkušnjo v zaledju sistema. ContentType je model za novo podatkovno tabelo za dodajanje in konfiguracijo novih vrst vsebinskih elementov. ContentSection je model za novo podatkovno tabelo, ki se uporablja pri grupiranju skupnih ali podobnih lastnosti na posamezni vrsti vsebinskega elementa. ContentColumnPalette je model za novo podatkovno tabelo, ki se uporablja za grupiranje posameznih lastnosti znotraj sekcij. ContentProperty je model novo podatkovno tabelo za dodajanje novih lastnosti vsebinskim elementom. ContentColumn je model za novo podatkovno tabelo za uporabo pri vnosnem polju v backnedu za prijaznejši prikaz in boljšo uporabniško izkušnjo. StringProperty je model za novo podatkovno tabelo za hranjenje nizov posameznih vrst vsebinskih elementov. TextProperty je model za novo podatkovno tabelo za hranjenje besedila posameznih vrst vsebinskih elementov. RteProperty je model za novo podatkovno tabelo za hranjenje oblikovanega besedila posameznih vrst vsebinskih elementov. IntegerProperty je model za novo podatkovno tabelo za hranjenje numeričnih vrednosti posameznih vrst vsebinskih elementov.

45 IZDELAVA SPLETNEGA KATALOGA 33 FloatProperty je model za novo podatkovno tabelo za hranjenje decimalnih vrednosti posameznih vrst vsebinskih elementov. BooleanProperty je model za novo podatkovno tabelo za hranjenje logičnih vrednosti posameznih vrst vsebinskih elementov. EntityProperty je model za novo podatkovno tabelo za hranjenje relacij posameznih vrst vsebinskih elementov. Category, Page in Group so modeli obstoječih podatkovnih tabel (sys_category, pages, fe_groups) in se uporabljajo kot pomožni razredi in za uporabo v prihodnje. Slika 20: Razultat domenske sheme spletnega kataloga. Na podlagi domenske sheme je nastala datotečna struktura z datotekami (slika 21): Domenski razredi v typo3conf/ext/catalog/classes/domain/model, Repozitoriji v typo3conf/ext/catalog/classes/domain/repository, Krmilniki v typo3conf/ext/catalog/classes/controllers, Konfiguracija TCA v typo3conf/ext/catalog/configuration/tca, Predloge v typo3conf/ext/catalog/resources/private/,

46 IZDELAVA SPLETNEGA KATALOGA 34 Sql za generiranje podatkovnih tabel v typo3conf/ext/catalog/ext_tables.sql, TypoScript konfiguracija v typo3conf/ext/catalog/ext_typoscript_setup.txt, Podatki o razširitvi za namestitev v typo3conf/ext/catalog/ext_emconf.txt, Konfiguracija za prikaz tabel v backend v typo3conf/ext/catalog/ext_tables.php, Konfiguracija za vtičnike v typo3conf/ext/catalog/ext_localconf.php. Slika 21: Datotečna struktura spletnega kataloga Implementacija V jedru TYPO3 CMS ni predvidene razširitvene točke za novo dodajanje skupin vsebinskih elementov. Za namen razširitve jedra smo uporabili XCLASS funkcionalnost. Izvorno kodo $TYPO3_CONF_VARS['SYS']['Objects']['TYPO3\\CMS\\Backend\\Configuration\\TsConfig Parser'] = array('classname' => 'UZ\\Catalog\\Backend\\Configuration\\TsConfigParser') za izvajanje XCLASS smo namestili v razširitveno datoteko ext_localconf.php. S tem smo zagotovili prikaz novih skupin za dodajanje novih vrst vsebinskih elementov. Pri generiranju vnosnih obrazcev vsebinskih elementov se kot osnova uporablja konfiguracija TCA. Za posamezen domenski model so lastnosti vedno enake in je temu primerno enaka tudi konfiguracija TCA. V spletnem katalogu lahko nove lastnosti generično dodajamo, zato se je na zahtevo moral prilagoditi tudi TCA. Z dodajanjem novih vrst je bilo za posamezno vrsto potrebno prilagoditi nalaganje TCA. Konfiguracijo TCA je bilo potrebno generirati še pred izvedbo generiranja obrazca za vnos vsebinskih elementov. Pri izvajanju se izvorna koda najprej izvede v razširitveni datoteki ext_tables.php. V to datoteko smo namestili programsko kodo za inicializacijo novih vrst vsebinskih elementov. S klicem statične metode \UZ\Catalog\Utility\CatalogTypes::init() se v TCA ustrezno naložile nove vrste. Te so bile v

47 IZDELAVA SPLETNEGA KATALOGA 35 času izvajanja programske kode za generiranje obrazca vsebinskega elementa potem tudi na voljo. Vsako vnosno polje za lastnost vsebuje v konfiguraciji TCA shemo za prikaz. Zagotovili smo ustrezno konfiguracijo TCA pred prikazom posamezne lastnosti. Za izvedbo smo uporabili razširitveno točko $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_ tcemain.php']['processdatamapclass'][$_extkey] = 'UZ\\Catalog\\Hooks\\Datamap'. Za prikaz generičnih lastnosti se je v času izvajanja na podlagi metode processdatamap_preprocessfieldarray v razširitveni točki za posamezno lastnost primerno generirala konfiguracija TCA. <?php /** * Datamap Hook */ class Datamap{ public function processdatamap_preprocessfieldarray(array &$fieldsvalues, $tablename, $uid, \TYPO3\CMS\Core\DataHandling\DataHandler $datahandler) { if (\UZ\Catalog\Utility\CatalogProperties::isContentProperty($tableName)) { //Set TCA for specific property \UZ\Catalog\Utility\CatalogProperties::setTcaConfig($GLOBALS['TCA']['tt_cont ent']['columns'][$fieldsvalues['property']]['config']['property']);?> Slika 22: Razširitvena točka za nastavitev konfiguracije TCA posamezne lastnosti. Spletni katalog omogoča uporabo obstoječih lastnosti in dodajanje novih lastnosti na nove vrste vsebinskih elementov. Za lastnosti je bilo z modelom ContentColumn zagotovljeno, da lahko za posamezno vrsto vsebujejo različen naziv. Za nove lastnosti smo z modelom ContentProperty definirali naziv, ključ in vrsto (slika 23). V odvisnosti od vrste lastnosti je bilo potrebno zagotoviti prikaz vnosnih polj, ki jih je za posamezno vrsto potrebno izpolniti: minimalna vrednost, maksimalna vrednost, obvezno polje, relacija na tabelo, repozitorij itd.

48 IZDELAVA SPLETNEGA KATALOGA 36 Slika 23: Določanje vrste lastnosti in določitev relacije na drug podatkovni model. Pri lastnostih, ki so relacije na druge podatkovne modele, je bilo pomembno zagotoviti pridobivanje podatkov glede na relacije. Za te namene je bilo dodano polje za vnos repozitorija, ki se potem na podlagi metode repozitorija findbyidentifier uporablja za pridobivanje relacijskih objektov. Zato je pri teh vrstah relacij pomembno, da administratorji določijo polno ime razreda za repozitorij (ang. FQC - Fully\Qualified\Classname), ki se uporablja za pridobivanje vrednosti v obliki objektov. Na ta način lahko kasneje dodajamo poljubne razširitve in jih uporabljamo kot povezave na lastnosti. Za dostop posameznih lastnosti pri prikazu je bilo potrebno zagotoviti unikatne ključe. Za te namene je bila uporabljena vgrajena konfiguracija TCA 'eval' => 'unique'. Preko ključa lastnosti smo lahko v generatorju predlog Fluid dostopali do podatkov. V času izvajanja je bilo poskrbljeno, da se nad trenutnim objektom izvajajo get metode na način get + ključ lastnosti v lowercamelcase notaciji. Get metode za generične lastnosti v primerih uporabe na objektu v izvorni kodi niso obstajale. Zato se je posledično v PHP izvorni kodi izvedel klic magične metode call [16]. Na podlagi izvajanja te metode smo lahko dostopali do generičnih lastnosti.

49 IZDELAVA SPLETNEGA KATALOGA 37 <?php namespace UZ\Catalog\Domain\Model; /** * Content */ class Content extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity { /** * Magic method call * string $methodname array $arguments */ public function call($methodname, $arguments = NULL) { if(substr($methodname,0,3) == 'get') { $methodname = lcfirst(substr($methodname,3)); if($this->checkifpropertyexists($methodname)) { return $this->getproperty($methodname); else { throw new \Exception('Property "'. lcfirst($methodname). '" does not exist!');?> Slika 24: Metoda v razredu Content za klic generičnih lastnosti. Generične lastnosti so lahko nosilci različnih podatkov. Od preprostih numeričnih vrednosti do kompleksnih objektov. Glede na vrsto lastnosti smo zagotovili, da se posamezni podatki shranjujejo v različne podatkovne tabele. Vsaka vrsta lastnosti je imela vnaprej ustrezno določen repozitorij, v katerega shranjuje podatke. Za pomoč pri dobivanju teh podatkov je bil uporabljen poseben razred CatalogProperties in Manager. <?php namespace UZ\Catalog; /** * CatalogProperties */ class CatalogProperties implements \TYPO3\CMS\Core\SingletonInterface { /* implementacija razreda */?> <?php namespace UZ\Catalog; /** * Manager */ class Manager implements \TYPO3\CMS\Core\SingletonInterface { /* implementacija razreda */?> Slika 25: Razred CatalogProperties in Manager za pridobivanje podatkov generičnih lastnosti.

50 IZDELAVA SPLETNEGA KATALOGA 38 Z metodama Manager::getContentPropertyTypeValues($content, $propertyname) in CatalogProperties::getRepositoryClassName($propertyType) smo omogočili pridobivanje podatkov na podlagi določenega repozitorija na lastnosti. Za izboljšanje uporabniške izkušnje in lažjega urednikovanja smo za urednike zagotoviti pregleden prikaz. Za ta namen smo uporabili sekcije (model ContentSection), ki uredniku na način zavihkov prikazujejo posamezno skupino lastnosti (slika 26). Slika 26: Prikaz zavihkov za boljšo uporabniško izkušnjo. Na posamezni sekciji smo s paletami (model ContentColumnPalette) zagotovili tudi nadaljnjo grupiranje lastnosti. Lastnosti so se znotraj posamezne palete prikazovale vrstično (slika 27). Slika 27: Lastnosti na paleti v vrstičnem prikazu. Za prikaz vsebinskih elementov TYPO3 CMS 7.6 LTS uporablja generator predlog Fluid s prednastavljeno konfiguracijo TypoScript. V tej konfiguraciji je na voljo FLUIDTEMPLATE lib.fluidtemplate objekt TypoScript. Ta omogoča dataprocessing, s katerim smo določili procesor za manipulacijo vsebinskih elementov. Na podlagi TypoScript konfiguracije smo določili procesor. (slika 28). lib.fluidtemplate{ default { dataprocessing { 10 = UZ\Catalog\DataProcessing\CatalogProcessor Slika 28: Konfiguracija TypoScript za manipulacijo vsebinskih elementov. Za spletni katalog je bil uporabljen procesor CatalogProcessor, ki se je izvajal nad generičnimi vsebinskimi elementi in generiral Content objekte.

51 IZDELAVA SPLETNEGA KATALOGA 39 <?php /** * CatalogProcessor */ class CatalogProcessor implements \TYPO3\CMS\Frontend\ContentObject\DataProcessorInterface { /** \TYPO3\CMS\Extbase\Object\ObjectManager */ protected $objectmanager; /** \UZ\Catalog\Extbase\Persistence\Generic\Mapper\DataMapper */ protected $datamapper; public function construct() { $this->objectmanager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\Object\Obj ectmanager::class); $this->datamapper = $this->objectmanager- >get(\uz\catalog\extbase\persistence\generic\mapper\datamapper::class); /** * Process data of a record to generate Content object * */ public function process(\typo3\cms\frontend\contentobject\contentobjectrenderer $cobj, array $contentobjectconfiguration, array $processorconfiguration, array $processeddata) { $processeddata['data'] = $this->datamapper- >mapsingle(\uz\catalog\domain\model\content::class, $processeddata['data']); return $processeddata;?> Slika 29: Razred CatalogProcessor za kreiranje Content objektov. Na podlagi procesorja CatalogProcessor so se podatki v obliki objekta Content ustrezno pripravili in posredovali generatorju predlog Fluid. Posamezne lastnosti objekta so bile dostopne z lowercamelcase notacijo.

52 IZDELAVA SPLETNEGA KATALOGA Izdelava vtičnika katalog REST API Izdelava vtičnika REST API je temeljila na razširitvi catalog. Razširitvi je bil dodan krmilnik Rest. Krmilniku Rest so bile dodane akcije dispatch, get, post, put in delete. Vsi zahtevki pri uporabi API so se izvajali preko akcijo dispatch. Glede na metodo HTTP so se zahtevki v krmilniku Rest z metodo dispatch posredovali na ustrezno akcijo. Za manipulacijo virov so bile uporabljene metode HTTP GET, POST, PUT in DELETE. <?php /** * RestController */ class RestController extends \TYPO3\CMS\Extbase\Mvc\Controller\ActionController { /** * action dispatch * \UZ\Catalog\Domain\Model\Content $content void */ public function dispatchaction(\uz\catalog\domain\model\content $content = NULL){ /* implementcaija metode */ /** * action get * \UZ\Catalog\Domain\Model\Content $content void */ public function getaction(\uz\catalog\domain\model\content $content = NULL){ /* implementcaija metode */ /** * action post * void */ public function postaction(){ /* implementcaija metode */ { /** * action put * \UZ\Catalog\Domain\Model\Content $content void */ public function putaction(\uz\catalog\domain\model\content $content = NULL) /* implementcaija metode */ /** * action delete * \UZ\Catalog\Domain\Model\Content $content void */ public function deleteaction(\uz\catalog\domain\model\content $content) { /* implementcaija metode */?> Slika 30: Krmilnik Rest s pripadajočimi metodami (dispatch, get, post, put, delete). Za branje virov so v REST API z metodo GET bili privzeto podprti formati HTML, XML, JSON, RSS. Format prikaza virov je bil odvisen od Content-Type HTTP zahtevka v glavi: Content-Type: text/xml prikaže vire v XML formatu. Content-Type: application/json prikaže vire v JSON formatu.

53 IZDELAVA SPLETNEGA KATALOGA 41 Content-Type: application/rss+xml prikaže vire v RSS formatu. Content-Type: poljubno prikaže vire v HTML formatu. Željen format smo fiksno določili na podlagi URL parametra format. Privzeto so se viri na določenem URL naslovu vedno prikazovali v obliki seznama. Tako smo z zahtevkom GET /api/ime-vira/ dobili seznam. Za pridobitev posameznega vira smo uporabili URL parameter id. Z zahtevkom GET /api/ime-vira/id/kljuc/ smo kot rezultat dobili vir z istoimenskim ključem. Za pomoč pri prikazu XML in JSON formata sta bili za potrebe REST API v razredu Content dodani dve metodi, tojson in toxml (slika 31), ki sta pretvorili Content objekte določenega vira v ustrezen format. <?php /** * Content */ class Content extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity implements \UZ\Catalog\Transformation\CatalogTransformationInterface {?> /** * Returns the content object as JSON string * string $json */ public function tojson() { /* implementacija metode */ /** * Returns the content object as XML string * string $xml */ public function toxml() { /* implementacija metode */ Slika 31: Metodi tojson in toxml v razredu Content za delovanje Rest API. Za vnos novih virov se je v REST API uporabljala POST metoda. Z zahtevkom POST api/ime-vira/ je REST API na podlagi poslanih podatkov ustvaril nove vire. Za vnos in posodobitev virov se je v REST API ustrezno uporabljala PUT metoda. Z zahtevkom PUT api/ime-vira/id/kljuc/ je REST API spletnega kataloga najprej preveril, ali vir s tem ključem že obstaja. V kolikor ni obstajal, se je izvedel vnos in v nasprotnem primeru posodobitev na podlagi ključa. Brisanje virov je bilo narejeno v REST API na HTTP metodi DELETE. Z zahtevkom DELETE /api/ime-vira/id/kljuc/ je bil izbrisan vir na podlagi ključa. Pri ponovitvi istega zahtevka je REST API vrnil napako HTTP 404, saj vir s tem ključem ni več obstajal.

54 UPORABA SPLETNEGA KATALOGA 42 Vtičnik REST API je bil prednastavljen tako, da smo lahko na podlagi predpone api v URL manipulirali vire na način: GET /api/ + vir + / POST /api/ + vir + / GET, PUT, DELETE /api/+ vir + /id/ + ključ GET /api/+ vir + /format/ + (xml,rss,json) GET /api/+ vir + /id/ + ključ + /format/ + (xml,rss,json) 6 Uporaba spletnega kataloga Spletni katalog se uporablja za izdelavo novih vrst vsebinskih elementov v TYPO3 CMS in objavo spletnih vsebin, ki na teh vrstah temeljijo. Za nove vrste lahko enostavno izdelamo nove poglede in na podlagi REST API omogočimo njihovo distribuiranje. 6.1 Namestitev Namestitev razširitve catalog je zelo enostavna. Namestimo jo lahko na več načinov: Izvorna koda se nahaja znotraj enega imenika catalog. Zato ta imenik preprosto prenesemo na strežniški imenik typo3conf/ext/ in razširitev v EM namestimo. Slika 32: Aktivacija razširitve catalog v EM. Razširitev lahko na strežnik naložimo preko EM kot.zip ali.t3x datoteko. S pritiskom na Upload Extension.t3x /.zip jo izberemo in prenesemo. Po prenosu na strežnik se razširitev tudi samodejno aktivira.

55 UPORABA SPLETNEGA KATALOGA 43 Slika 33: Namestitev razširitve catalog v EM z nalaganjem datoteke. Razširitev lahko naložimo v TYPO3 TER ali v lasten repozitorij. V EM jo pod rubriko Get Extensions po ključu catalog poiščemo in jo s klikom import and install namestimo. Ob prenosu iz repozitorija se tudi samodejno aktivira. Za prikaz generičnih vrst na spletnih straneh je potrebno vključiti prednastavljeno konfiguracijo razširitve. Na korensko TypoScript predlogo dodamo razširitveno statično predlogo Catalog (catalog). Slika 34: Vključitev statične predloge iz razširitve catalog na korensko predlogo. Vtičnik REST API ob namestitvi razširitve ne deluje samodejno. Na podlagi URL parametra tx_catalog_rest[api] izvedemo delovanje. V TypoScript predlogo v področje setup namestimo konfiguracijo (Slika 35: Odločitveni stavek za vklop vtičnika REST APIslika 35). [globalvar = GP:tx_catalog_rest api = 1] page{ config { disableallheadercode = 1 disablecharsetheader = 1 xhtml_cleaning = 0 admpanel = 0 debug = 0 10 < lib.catalogrestapi [global] Slika 35: Odločitveni stavek za vklop vtičnika REST API.

56 UPORABA SPLETNEGA KATALOGA 44 S tem zagotovimo, da se ob klicu tega URL parametra na spletni strani izvaja REST API. Zaradi prijaznejše izkušnje želimo doseči delovanje prijaznih URL-jev. To za delovanje pomeni, da se mora URL parameter tx_catalog_rest[api]=1 spremeniti v api. Za generiranje ustreznih URL-jev poskrbi razširitev realurl, ki jo namestimo v EM. Za mapiranje URL parametra v razširitveno konfiguracijo namestimo posebno PHP kodo s ključem prevars (Slika 36: Konfiguracija realurl za mapiranje GET parametrov): <?php 'prevars' => array( '0' => array( 'GETvar' => 'tx_catalog_rest[api]', 'valuemap' => array( 'api' => 1 ), 'nomatch' => 'bypass' ) ), 'postvarsets' => array( '_DEFAULT' => array( 'id' => array( array( 'GETvar' => 'tx_catalog_rest[content]' ) ), 'format' => array( array( 'GETvar' => 'tx_catalog_rest[format]' ) ) ) )?> Slika 36: Konfiguracija realurl za mapiranje GET parametrov. Sedaj lahko uporabljamo klic REST API s predpono /api/ v URL. Tako poskrbimo tudi za prikaz posameznih virov in izbire formata prikaza. Za te namene namestimo še v realurl konfiguracijo s ključem postvarsets (slika 36). 6.2 Prilagoditev Ker je spletni katalog izdelan na ogrodju Extbase, je fleksibilen in zaradi MVC zagotavlja različne poglede modela. Privzeto spletni katalog že omogoča nekaj prednastavljenih formatov (HTML, XML, JSON, RSS) prikazov za posamezni model. Teh prikazov je lahko poljubno veliko in jih je enostavno dodajati. Za nov prikaz enostavno izdelamo nove predloge z istoimensko končnico formata. V odvisnosti od konteksta se na spletnih straneh uporablja ustrezen format predlog. S TypoScript lib.fluidtemplate lahko nastavimo poti do predlog (slika 37). lib.fluidcontent.templaterootpaths.10 = glavne_predloge/ lib.fluidcontent.partialrootpaths.10 = delne_predloge/ lib.fluidcontent.layoutrootpaths.10 = postavitve/ Slika 37: Nastavitev poti v TypoScript za uporabo različnih predlog.

57 UPORABA SPLETNEGA KATALOGA 45 V konfiguraciji TypoScript lahko v določeni veji drevesne strukture ali na določeni strani tudi spremenimo poti za uporabo predlog, kot je prikazano na spodnji sliki. [PIDinRootline = 4] [globalvar = TSFE:id = 12] lib.fluidcontent.templaterootpaths.10 = glavne_predloge/druga_veja/ lib.fluidcontent.partialrootpaths.10 = delne_predloge/druga_veja/ lib.fluidcontent.layoutrootpaths.10 = postavitve/druga_veja/ [end] Slika 38: Sprememba predlog na določeni strani ali veji. Uporabo predlog lahko spreminjamo tudi za posamezno vrsto vsebinskih elementov (gl. sliko 39). Privzeto se vedno uporablja predloga, glede na ključ vrste. tt_content{ novica { templatename = novapredloga Slika 39: Sprememba predloge za vrsto vsebinskega elementa s ključem novica. 6.3 Testni primer Katalog izdelkov je sestavljen iz različnih novih vrst vsebinskih elementov, ki v osnovi niso vgrajeni v TYPO3 CMS. Te nove vrste v spletnem katalogu predstavljajo izdelke. Za testni primer spletnega kataloga smo za urednike ustvarili nove vrste vsebinskih elementov, ki predstavljajo posamezne izdelke. Izdelane so bile nove skupine izdelkov z novimi pripadajočimi vrstami izdelkov: Šport in prosti čas: Kolo, Obutev, Merilec utripa; Računalništvo: Monitor, Ohišje, Procesor, Pomnilnik, Grafična kartica; Avdio video: TV, Slušalke, Diktafon in Bela tehnika: Pralni stroj, Štedilnik, Hladilnik. Za posamezno skupino izdelkov so bile dodane strani, ki predstavljajo shrambo in prikaz izdelkov. Konfiguracija za nove skupine, nove vrste in nove lastnosti je bila shranjena na posebne strani Skupine, Vrste in Lastnosti (Slika 40: Izdelava drevesne strukture 40).

58 UPORABA SPLETNEGA KATALOGA 46 Slika 40: Izdelava drevesne strukture za prikaz izdelkov. Za nove izdelke so bile definirane lastnosti, ki so bile dodane na konfiguracijsko stran Lastnosti (slika 41). Razporejene so bile v skupine Splošno, Mediji, Cena, Pakiranje in Povezani izdelki, ki za posamezno vrsto izdelka predstavljajo sekcije. Slika 41: Nove lastnosti na konfiguracijski strani Lastnosti. Za boljšo uredniško izkušnjo so bile na stran Skupine dodane nove skupine izdelkov Šport in prosti čas, Računalništvo, Avdio video in Bela tehnika (slika 42).

59 UPORABA SPLETNEGA KATALOGA 47 Slika 42: Nove skupine izdelkov. Na posamezno novo vrsto izdelka pa razvrščene lastnosti po sekcijah, kot na sliki 43. Vsi izdelki vsebujejo enake sekcije. Slika 43: Sekcije posamezne vrste in pripadajoče lastnosti. Dodane so bile nove skupine, izdelki in strani za prikaz posameznih izdelkov. S tem smo urednikom zagotovili vstavljanje novih izdelkov (slika 44).

60 UPORABA SPLETNEGA KATALOGA 48 Slika 44: Dodajanje novih izdelkov. Pri nalaganju obrazca za vnos izdelka se izvede postavitev glede na konfiguracijo nove vrste izdelka (slika 45). Slika 45: Prikaz vnosnih polj glede na konfiguracijo nove vrste Monitor. Za prikaz izdelkov so bile ustvarjene ustrezne HTML predloge (slika 46). Izdelki se po straneh prikazujejo v seznamih. S klikom na izdelek dobimo prikaz posameznega izdelka (slika 47).

61 UPORABA SPLETNEGA KATALOGA 49 <div class="col-md-4 item"> <h2><f:link.action class="bottom-align-text" pageuid="1" extensionname="catalog" pluginname="content" controller="content" arguments="{content:data.uid">{data.header<span class="more pullright">»</span></f:link.action></h2> <p><b>monitor:</b> {data.znamkatv</p> <f:if condition="{data.image -> f:count()"><f:image image="{data.image.0" treatidasreference="1" height="70" class="pull-left image-list" /></f:if> <f:render section="cena" arguments="{_all" /> </div> <f:section name="cena"> <f:if condition="{data.cena"> <f:then> Redna cena: <strike class="blog-post-meta"><f:format.currency currencysign=" " decimalseparator="," thousandsseparator="." prependcurrency="false" separatecurrency="false" decimals="2">{data.cena</f:format.currency></strike> <br /> <span class="price"></>s popustom: <b><f:format.currency currencysign=" " decimalseparator="," thousandsseparator="." prependcurrency="false" separatecurrency="false" decimals="2">{data.cenaspopustom</f:format.currency></b></span> </f:then> <f:else> Cena ni na voljo </f:else> </f:if> </f:section> Slika 46: Oblikovanje Fluid predloge Monitor.html za prikaz v seznamu. Slika 47: Seznam izdelkov Računalništvo in posamezen prikaz izdelka Monitor.

62 UPORABA SPLETNEGA KATALOGA 50 Slika 48: Seznam izdelkov Šport in prosti čas in posamezen prikaz Obutve. Posamezna stran za prikaz skupine izdelkov predstavlja hkrati tudi vir za REST API. Na podlagi URL klica /api/racunalnistvo/ z GET zahtevkom Content-Type: application/json smo kot dobili JSON format seznama izdelkov iz skupine Računalništvo (slika 49). S klicem HTTP metode PUT na URL /api/racunalnistvo/id/102/ in s pošiljanjem podatkov v odvisnosti od formata smo ustvarili nov izdelek s ključem 102 (slika 50). Za brisanje izdelka s ključem 102 smo uporabili klic HTTP metode DELETE na URL /api/racunalnistvo/id/102/ (slika 51).