A. Smijulj, A.

Metrovi: Izgradnja MVC modularnog radnog okvira

Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Adrian Smijulj 1 Struni rad

Ana Metrovi 2 UDK 004.415.2

IZGRADNJA MVC MODULARNOG

RADNOG OKVIRA3

SAETAK
Cilj je ovoga strunoga rada prikazati tehnologije i komponente vezane uz izradu radnog okvira te prikazati
implementaciju jednostavnog radnog okvira koji sadri najnunije komponente za brzi razvoj web-aplikacija.
Iznesena su teorijska razmatranja vezana uz primjenu radnog okvira u razvoju aplikacije. Predstavljene su i
analizirane potencijalne komponente radnog okvira. Nadalje, prikazana je implementacija radnog okvira uz
koritenje suvremenih tehnologija kao to su PHP, MySQL, HTML itd. Prikazani radni okvir cjelokupno je izgraen
primjenom objektno-orijentiranog pristupa. Koritena je Model-View-Controller arhitektura i alati poput ORM
suelja za automatizirani rad s entitetima i sustavom za upravljanje dogaajima. Prednost koritenja izraenog
radnog okvira je prestanak ulaganja programerova vremena na osmiljavanje arhitekture i izradu alata, ve
e se u potpunosti moi posvetiti zadacima projekta. Iako sadri samo temeljne komponente, radni okvir e
po svojoj modularnoj arhitekturi biti fleksibilan, to e omoguiti programeru da ga proiri prema vlastitim
potrebama i prilagodi prema zahtjevima aplikacije koju je potrebno izraditi. Zakljuak je rada kako je u razvoju
sloenih aplikacija poeljno uloiti vrijeme u izradu radnog okvira ili neke sline komponente koja e kasnije
omoguiti bri i pouzdaniji razvoj cjelokupne aplikacije.
Kljune rijei: radni okvir, Model-View-Controller arhitektura (MVC), programiranje pogonjeno dogaajima,
modularni sustavi , PHP

1. UVOD
Programiranje i razvoj aplikacija postaju sve zahtjevniji zadaci. Razvojem novih tehnologija,
mogunosti i nastajanjem sve kompleksnijih problema, potrebno je uloiti vie vremena
za izradu projekta. Programer ponekad mora razvijati svoja rjeenja na dvije, pa ak i vie
programskih platformi. Jedan od moguih pristupa koji moe olakati i ubrzati razvoj aplikacija
je koritenje radnih okvira (engl. frameworks). To su alati koji odrauju poslove koji mogu biti
vrlo esto repetitivni, trivijalni, ponekad kritini i openito poslovi kojima se programeri ne
bi trebali baviti prilikom rada na projektu jer uzimaju dodatno vrijeme za razvoj. Programeri
na projektu moraju razvijati zadani projekt, a ne probleme arhitekture kda, nedostatka
funkcionalnosti ili sigurnosti4.

1
Mag. edu. E-mail: adrian.1358@gmail.com
2
Dr. sc., docent, Odjel za informatiku, Sveuilite u Rijeci, Radmile Mateji 2, Rijeka, Hrvatska.
E-mail: amestrovic@inf.uniri.hr
3
Datum primitka rada: 27. 2. 2014.; datum prihvaanja rada: 5. 5. 2014.
4
SensioLabs, (2013)., The Book for Symfony 2.3, preuzeto 10. 8. 2013.
215
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

U ovome radu fokus je postavljen na izradu radnog okvira i to u jednom od najpoznatijih

skriptnih jezika u domeni web-tehnologija, a to je PHP. s ciljem poveanja uinkovitost
programera i samog kda, integrirano je nekoliko razliitih komponenti, odnosno modula,
a svaki je odgovoran za odraivanje jednog segmenta aplikacije koje e programeri-korisnici
koristiti po potrebi. Kreiranje ovog radnog okvira nastalo je temeljem razliitih iskustava s
drugim popularnim radnim okvirima, a istovremeno sa eljom da se iz svakoga uzmu dobre
ideje i pretvore u jedan novi alat. Korisno je napomenuti kako radni okvir nije produkt koji se
kreira jednokratno, stoga je logian nastavak ovoga rada usavravanje, odravanje i dodavanje
novih mogunosti, kako bi bio u skladu s novim tehnologijama i nadolazeim potrebama
programera.
U radu je posebno analizirana Model-View-Controller (MVC) arhitektura. MVC arhitektura
sedamdesetih je godina inicijalno uvedena u jezik Smalltalk-76, a potom implementirana
unutar biblioteka verzije Smallatlk-80 (Krasner, Pope, 1988). Nakon toga je MVC arhitektura
prihvaena kao openiti koncept.
U nastavku rada opisana je ideja radnog okvira i MVC arhitekture te koncepti bitni za njegovu
realizaciju: modularno programiranje, Object-Relational Mapping (ORM) koncept, te
programiranje pogonjeno dogaajima. U treem poglavlju opisan je postupak implementacije
modula za kreiranje korisnika i korisnikih grupa. U etvrtom poglavlju iznesena su zakljuna
razmatranja.

2. IZRADA RADNOG OKVIRA

U ovome poglavlju bit e prikazana izrada radnog okvira, i to tako da e prvo biti teorijski
obraene komponente, a nakon toga e biti prikazana implementacija. Bit e obraeno
nekoliko poznatijih i popularnijih termina iz podruja programiranja, i to poevi od
osnovne MVC arhitekture koja e biti koritena. Osim toga, bit e razmotrene i karakteristike
modularnog programiranja, ORM suelja i programiranja pogonjenog dogaajima, kao sloj
koji e dodatno podravati radni okvir.
Radni okvir je alat koji se sastoji od mnotva razliitih komponenti koje programeru mogu
olakati posao i ubrzati proces izrade aplikacije. Okviri su kolekcije razliitih pomonih
funkcija, klasa, knjinica i dr. koje pomau nudei ve gotova rjeenja za specifine i esto
koritene probleme. Programeri se mogu odluiti za koritenje ve popularnih gotovih
rjeenja, no ponekad mogu krenuti i u izradu vlastitog. Za ovaj korak prethodno treba utvrditi
potrebno vrijeme izrade i predvidjeti probleme koji se mogu pojaviti. Vlastita izrada moe biti
i tetna, jer esto ne postoji dovoljno znanja i iskustva kako bi se sve prepreke u potpunosti
rijeile. Ipak, esto je onima koji rade s vlastitim radnim okvirom kasnije lake rijeiti odreene
aplikacijske probleme jer poznaju arhitekturu koju su sami postavili pa lake mogu ponovno
iskoristiti isti kd na drugim projektima (Fowler, 2002).
Neki od primjera rjeenja koja nude razliiti radni okviri su sustav rada s korisnicima, MVC
arhitektura, klase za rad s kolaiima (engl. cookies) i sesijama (engl. sessions), formulari,
ORM suelje, klase za rad s rutama, datotekama itd. Koritenjem radnog okvira, sve navedene
216
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

probleme programer preskae, ime se moe odmah baviti stvarnim problemom, odnosno
poslovnom logikom. Osim navedenog, postoji jo niz prednosti:
sigurnost,
nema cijene (open source),
podrka od strane proizvoaa i zajednice.
Postoje i mane, npr.:
ponekad programer pasivno ui rad u radnom okviru, a ne u jeziku,
ogranienja od strane radnog okvira,
kd radnog okvira je otvorenog tipa, to znai da napredniji programeri mogu znati
kako aplikacija interno funkcionira i mogu iskoristiti slabosti.
Trenutno postoji mnogo dostupnih gotovih radnih okvira, a neki od poznatijih su zasigurno
Symfony, CakePHP, CodeIgniter, ZendFramework, Laravel, Yii (McArthur, 2008). Specifinost
rada s navedenim radnim okvirima jest njihov neidentian rad. Stoga, promjenom radnog
okvira s jednog na drugi, programer mora detaljno prouiti strukturu, konvencije i njegove
specifinosti.
Ukupno gledajui, postoje dobri razlozi za koritenje gotovog radnog okvira. No, izraujui
vlastiti, mogue je u potpunosti prilagoditi kompletnu arhitekturu vlastitim potrebama i
eljama, odnosno dodavati samo ono potrebno za odreeni projekt, te kasnije napraviti
izmjene ili nadogradnje sustava. S druge strane, tijekom izrade ovakvih sustava nije potrebno
apsolutni svaki dio samostalno izraditi jer postoje ve dobra modularna rjeenja, pa e tako za
sustav upravljanja predlocima u radnom okviru biti integriran popularan Smarty Templating
Engine (Hayder, & Gheorghe, 2006), ime e se utedjeti vrijeme potrebno za izradu radnog
okvira.
2.1 ModelViewController arhitektura
MVC je kdna arhitektura koja je, iako originalno razvijana za desktop platforme, danas
popularna na suvremenim web-platformama. Glavne ideje ovoga modela su razdvajanje kda
u zasebne cjeline, odnosno dosljedna struktura i mogunost ponovnog koritenja istog kda
(engl. code reusability). Sama ideja je prvi put javno prezentirana ve 1988. godine (Krasner,
Pope, 1988), a do dananjeg dana doivjela je nekoliko iteracija pa je stvoreno nekoliko inaica
originalne ideje (HMVC, MVA, MVP, MVVM, itd.).
MVC arhitektura sastoji se od odreenih komponenti u kojima je svaka zaduena za obavljanje
specifinih funkcija. To je puno bolje u odnosu na prethodne inaice u kojima se sve nalazilo
na jednom mjestu, a to je pak dovodilo do oteanog itanja kda, oteanog pronalaenja i
ispravljanja pogreaka, ali i do znatno manje funkcionalnosti i fleksibilnosti.
Cijela arhitektura se sastoji od triju specifinih i meusobno zavisnih komponenti: model, view
(pogled, prezentacija) i controller (kontroler, upravlja). Na slici 1 prikazan je openit princip
rada MVC arhitekture u web-okruenju:
217
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Slika 1. Openit princip rada MVC arhitekture u web-okruenju

Izvor: (Hayder, Gheorghe, 2006)

Cijeli proces zapoinje korisnikovim zahtjevom (u trenutku kada korisnik unese web-adresu
u svom pregledniku) kojeg najprije analizira kontroler, a koji sadrava skup prethodno
definiranih slijedova operacija, odnosno funkcija koje je potrebno izvriti. U tom procesu vri
se i komunikacija s preostale dvije komponente modelom i prezentacijom, tako da potrebne
parametre prosljeuje svakoj komponenti te, ovisno o rezultatu, kontrolira daljnji slijed
izvravanja cjelokupnog procesa. Uloga modela je rad s podacima, odnosno komunikacija s
bazom podataka, dodatna obrada dobivenih podataka, ukoliko je potrebno, te u konanici
vraanje rezultata prema kontroleru. Dobiveni podaci e, po potrebi, biti poslani drugim
procesima i biti opet naknadno obraivani. Ipak, u veini sluajeva kontroler e zavriti proces
pozivajui prezentacijsku komponentu, koja e pak generirati zadani predloak po kojemu e
se dobiveni podaci i prezentirati. Tako dobiveni predloak, odnosno generirani HTML kd,
kontroler e poslati prema korisniku, odnosno korisnikovom pregledniku.
MVC arhitektura se neko vrijeme razvija unapreivanjem prethodnih verzija pa je razvijeno vie
razliitih verzija MVC arhitekture. Arhitekture su uglavnom sline, s manjim razlikama u logici
odvijanja procesa i nazivlju komponenata. Jedna verzija MVC arhitekture je MVA, odnosno Model-
View-Adapter i zanimljivo je da se danas sve vie koristi u kontekstu web-tehnologija, naroito na
klijentskoj strani aplikacije (npr. u skriptnom jeziku JavaScript). U ovom konceptu postoji posebna
komponenta adapter koja se nalazi izmeu komponenti model i prezentacija i ona regulira procese
tako to prati rad i procese temeljem odgovora koje dobiva od okolnih susjednih komponenti.
Npr. prezentacijska komponenta alje signal da je u tekstualno polje u formularu upisano ime,
adapter prima tu informaciju i tada alje zahtjev modelu za auriranjem podataka koji e se kasnije
koristiti za spremanje, npr. u bazu podataka. Obrnuti proces je takoer mogu, ukoliko se podaci
u modelu promijene, model komponenta e poslati signal adapteru koji e na isti nain reagirati
prema prezentacijskooj komponenti, odnosno sadraj formulara e se takoer aurirati. Danas se
primjena ovakvog nain rada moe vidjeti npr. u JavaScript radnim okvirima kao to su Backbone.js,
Angular.js, Kendo UI (Adams, 2013) itd., a koji omoguuju izvravanje MVC arhitekture djelomino
na klijentskoj strani, za razliku od klasinog pristupa u kojem se arhitektura primjenjivala samo na
posluitelju.

218
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Slian princip koristi i three-tier-pattern arhitekura (Eckerson, 1995), u kojoj se kao i u MVC
arhitekturi, cjelina nastoji razdvojiti u tri razine, a to su prezentacijska, logika i podatkovna
razina. Zanimljivo je da se ove razine izvravaju na razliitim platformama, pa se tako
prezentacijska razina moe nalaziti u desktop aplikaciji u obliku korisnikog suelja, dok se
logika i podatkovna razina mogu nalaziti na razliitim posluiteljima u izoliranoj okolini. Iz
ovoga nastaje, takoer interesantna, prednost: razine ne ovise meusobno, i to u smislu da je
na razliitim razinama mogue kompletno zamijeniti okruenje (npr. u prezentacijskoj razini
izmijeniti operativni sustav ili aplikaciju) i sve dok specifine razine odrauju svoju funkciju,
cijela arhitektura e ispravno funkcionirati. U odnosu na MVC arhitekturu, osim ove razlike,
ovdje takoer ne postoji mogunost komunikacije prve i zadnje razine, ve cijeli proces uvijek
zapoinje prezentacijskom, a zavrava podatkovnom razinom, to u odreenim situacijama
moe biti i mana.
2.2 Modularno programiranje
Modularno programiranje je tehnika dizajniranja softvera koja naglaava razdvajanje kda
u neovisne cjeline koje se u svakom trenutku mogu ukljuiti ili iskljuiti i to bez utjecaja
na ostatak sustava (ribar, Motik, 2010; Matkovi, 2006). Ovo se znatno razlikuje od tzv.
monolitinih aplikacija u kojima je i najmanji dio kda zapravo neizostavni dio cjeline, to
je gotovo uvijek nepoeljan faktor u procesu izrade softvera. Uobiajeni primjeri modularnih
sustava su integrirani informacijski sustavi za podrku poslovanju (ERP sustavi, engl. Enterprise
Resource Planning Sastems) ili sustavi za elektroniko poslovanje koji se mogu sastojati takoer
od vie modula. Primjer modularnog sustava za elektroniko poslovanje prikazan je na slici 2.

Slika 2. Primjer modularnog aplikacijskog sustava za elektroniko poslovanje

Izvor: Obrada autora

U navedenim primjerima vidimo kako se kompleksni sustavi mogu sastojati od svojih manjih
zasebnih cjelina. Tako npr. ERP sustav moe sadravati modul za upravljanje odnosima s korisnicima
(engl. Customer Relationship Management, CRM), ali i ne mora, ukoliko za to ne postoji zahtjev, dok
e sustav i dalje funkcionirati uredno. S druge strane, sustav za elektroniko poslovanje moe, ali i
ne mora, sadravati modul za izradu popusta na cijenu proizvoda.
Bitno je napomenuti kako moduli kao takvi ne komuniciraju meusobno u sustavu, osim u smislu
koritenja drugog modula kako bi prvi mogao ispuniti svoju namjenu (npr. modul koji bi mogao
sluiti za ispisivanje izvjea moe funkcionirati jedino ako prethodno u sustavu postoji i modul
koji kreira izvjea).
219
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Osim to omoguuje bolju strukturiranost i neovisnost kda, ova tehnika ima jo neke prednosti:
kd je smjeten u razliitim datotekama koje se kasnije ukljuuju u cjelinu,
u isto vrijeme nekoliko programera moe raditi na razliitim dijelovima sustava,
osnovu sustava je lake odravati (popravci i unaprijeivanje kda) uteda na
vremenu a time i novcu,
kod isporuke proizvoda, mogue je definirati ukupnu cijenu na temelju modula koji su
ukljueni u paketu.
2.3 ORM suelje
Openito, pri kreiranju programskih aplikacija, programer e se gotovo uvijek susresti s razliitim
postupcima manipuliranja podacima, odnosno bazom podataka. Kod takvih operacija, programer
pie razliite upite nad bazom podataka (SQL upiti) i time kreira, ita, mijenja ili brie postojee
podatke. No, upiti esto mogu biti slini ili ak isti za razliite dijelove aplikacije. U praksi kd se
kopira, a u konanici ga je i vrlo teko odravati jer se promjene ne izvode samo na jednom mjestu,
nego na cijelom sustavu (automatski postoji mogunost pogreke u kdu na svakoj kopiji).
Object relational mapping je nain organizacije kda odgovornog za izvravanje upita prema bazi
podataka. To je tehnika kojom je omoguena komunikacija i konverzija podataka izmeu dva
zapravo nekompatibilna sustava objektno orijentiranog jezika i baze podataka. Konkretnije, ova
tehnika omoguuje programerima da u kdu gotovo u cijelosti iskljue pisanje SQL upita jer to
za njih odrauje ORM suelje, dok se njihov kd svodi na rad s objektima. Na slici 3 je generalno
prikazan nain rada ORM suelja.
Slika 3. Uloga i nain rada ORM suelja

Izvor: https://code.google.com/p/quickdb/

U praksi, koritenjem ORM-a, programer radi s objektima razliitih klasa koje predstavljaju
neke tipove entiteta koji imaju implementirane razliite metode za rad s bazom podataka (npr.
razliite metode za itanje ili spremanje podataka). Sama logika je enkapsulirana i ona se brine o

220
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

tonom izvoenju SQL upita umjesto programera. Moemo rei da ORM zapravo stvara virtualnu
reprezentaciju objektne baze podataka, jer u kdu zapravo virtualno spremamo objekt u bazu,
odnosno itamo ili dohvaamo objekt iz baze. No, to u stvarnosti nije tako (za razliku od objektnih
baza podataka), jer se u konanici podaci zapisuju u obliku retka u tablici u bazi podataka. Danas
postoje ve nekoliko gotovih ORM rjeenja (gotovo da se mogu i nazvati radni okviri zbog svoje
kompleksnosti i mogunosti), kao npr. Doctrine Project5, Active Record6 itd., a nerijetko se piu
i razna manja rjeenja zbog bolje prilagodbe postojeoj strukturi podataka. Neka od rjeenja
nude i mogunost rada s razliitim platformama kao to su MySQL, PostgreSQL, SQLite, itd. U
sljedeem primjeru kda prikazan je primjer rada s poznatim ORM sueljem Doctrine Project.
1 // Primjer pretraivanje lanaka
2 $article = $entityManager->find(CMS\Article, 1234);
3 $article->setHeadline(Hello World!);
4 $article2 = $entityManager->find(CMS\Article, 1234);
5 echo $article2->getHeadline();
6 // Svi korisnici koji imaju 20 godina i prezivaju se Miller
7 $users = $em->getRepository(MyProject\Domain\User)->findBy(array(age => 20, surname => Miller));

Velika prednost koritenja ove tehnike oituje se u tome to programeri ne moraju pisati SQL
upite, a osim toga, kd izgleda preglednije jer se sve svodi na rad s objektima te pozivanje njihovih
metoda. Meutim, vrlo je teko kreirati ORM suelje koje moe pokriti sve nae zahtjeve. Drugim
rijeima, kompleksniji SQL upiti se moraju i dalje runo pisati. Uz ovo, pokazalo se da programeri
ponekad nesvjesno kreiraju loe dizajnirane tablice jer ih automatski prilagoavaju ORM suelju
koje koriste.
U izgradnji radnog okvira bit e implementirano i ORM suelje. Pri razvoju ove komponente,
nastojalo se to vie pojednostaviti upotrebu, ime e se poveati produktivnost programera i
smanjiti ukupna koliina potrebnog kda.
2.4 Izrada MVC arhitekture
U ovome poglavlju e biti prikazana izrada MVC arhitekture radnog okvira u skriptnom jeziku PHP,
koja ini osnovu modularnog radnog okvira. Na slici 4 dan je prikaz UML dijagram7 s kojim e se
moi zornije prikazati cjelokupna struktura radnog okvira.
Radni okvir sastojat e se od nekoliko temeljnih klasa koje e sadravati sve to je potrebno
kako bi se sustav pravilno inicijalizirao, to e se izvoditi na svakom zahtjevu klijenta prema
odreenoj aplikaciji na posluitelju. Sve zapoinje s klasom Application, izvravanjem metoda
kao to init() ili getModuleConfig(), nakon ega e se na kraju instancirati jedan objekt klase
Controller. Ovdje e se vrlo esto instancirati razliiti objekti klase Entity, koja zbog dodatnih
potrebnih metoda proiruje klasu Model, koja pak, u konanici, proiruje klasu DB_Resource
i koristi klasu DB, to omoguuje rad s bazom podataka. Jedino je u ponekim sluajevima
mogue izravno koritenje klase DB_Resource, i to kada se eli zaobii klasa Entity, odnosno
5
http://www.doctrine-project.org/, preuzeto 10. 8. 2013.
6
http://www.phpactiverecord.org/, preuzeto 10. 8. 2013.
7
UML dijagram - Ujedinjeni jezik za modeliranje (eng. Unified Modelling Language, krae: UML) je normirani jezik
ope namjene koji se koristi za modeliranje raunalnih sustava temeljenih na objektno-orijentiranoj paradigmi.
221
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

kada ona, zbog okolnih faktora, programeru jednostavno nije potrebna. Iza ovog dijela
nalazi se klasa View koja e takoer instancirati objekt klase Smarty. On e nam koristiti za
generiranje HTML sadraja, a koji e se u konanici prikazati krajnjem korisniku.
Klase, atributi i metode su razvrstane logiki prema svojoj namjeni. Struktura nije strogo
definirana, stoga ju je mogue, prema eventualnim potreba klase, dodatno proiriti vlastitim
metodama ili umetnuti dodatnu klasu izmeu nekih postojeih, ukoliko je to potrebno.
Radni okvir e biti modularan, to znai da e podravati proizvoljno ukljuivanje i iskljuivanje
modula iz sustava. Nadalje, svaki modul koji e se pisati radit e prema MVC ahitekturi -
drugim rijeima, svaki modul e imati svoje kontrolere (moe ih biti i vie, ovisno o potrebi) te
e sustav, prema definiranom algoritmu, prepoznati u kojem se modulu, kontroleru i akciji radi
i to iz HTTP zahtjeva korisnika, odnosno pomou upisane adrese. Za ovo e biti odgovoran
usmjeriva, tzv. ruter i njegovo procesiranje e se u pravilu uvijek izvravati prije bilo kojeg
kontrolera (ponekad se ovaj kontroler naziva i prednji kontroler).
Slika 4. UML dijagram radnog okvira

Izvor: Obrada autora

222
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Nakon prepoznavanja, nastavak procesa je jednostavan - sustav e instancirati objekt zadanog

kontrolera, izvriti metodu na njemu i ispisati rezultat korisniku. Ovaj proces je prikazan na slici 5.
Slika 5. Usmjeriva i ostali procesi radnog okvira

Izvor: Obrada autora

Iako su u dosadanjim primjerima akcije vraale rezultat, odnosno generirani HTML (engl. output),
to ne mora biti uvijek tako. Npr., akcije ponekad mogu samo odraditi spremanje ili brisanje
podataka u bazi, vriti preusmjeravanje itd.
Kontroleri i njihove akcije se zapravo logiki grupiraju u cjeline, pa tako moe postojati sljedea
podjela tri modula i klase kontrolera koje sadre tipine akcije (slika 6):
Slika 6. Jednostavni primjeri kontrolera

Izvor: Obrada autora

U prvom sluaju definiran je kontroler Stranice istoimenog modula, koji je odgovoran za prikaz
statikih stranica. Prve tri akcije pocetna(), onama() i kontakt() mogu posluiti za dohvaanje
predloka u kojima se nalaze potrebne informacije, dok etvrta metoda moe spremati podatke
iz formulara koji je korisnik dobio prethodno ispunjavajui formular dobiven pomou akcije
kontakt(). Organizacija je slina i u druga dva kontrolera, definirane su akcije koje e vraati
formulare za unos podataka (npr. dodavanje() i prijava()) i akcije koje e procesuirati podatke
(npr. spremanje(), odjava()).

223
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

U ovom poglavlju analiziran je nain rada spomenutog usmjerivaa i elementi potrebni za

njegovo pravilno funkcioniranje. Preciznije, analiziran je nain na koji sustav bira potrebnu
klasu i njezinu metodu, odnosno akciju kojom korisnik alje zahtjev za odreenom
stranicom na posluitelj. Da bi se ovo postiglo, potrebno je definirati sustav koji e za dani
zahtjev znati koji se objekt mora instancirati i koja metoda se mora izvriti. Ovo se postie
tako da se najprije u postavkama posluitelja svi zahtjevi preusmjere na jednu datoteku u
kojoj e cijeli sustav, i u konanici usmjeriva, biti definiran. Navedena datoteka e u imati
naziv index.php a preusmjeravanje e se ostvariti pomou datoteke .htaccess.
2.5 Programiranje pogonjeno dogaajima
Kao to je poznato, pri pokretanju klasinih programa, kompletan kd se izvrava u
odreenom redoslijedu kojega je definirao programer. Dakle, nakon izvrene naredbe,
izvrit e se sljedea i tako sve do posljednje, odnosno do kraja programa. Iako postoji
mogunost da odreeni dijelovi kda nikada ni ne budu izvreni (npr. kod grananja),
nikada se nee dogoditi da se kasnija naredba izvri prije nego to treba. Ovakva struktura
moe biti pogodna u okolinama gdje program korisniku ispisuje poruku, zatim eka njegov
odgovor te na temelju toga postupa dalje prema svojem kdu. S druge strane, razvojem
softvera i korisnikih suelja, nastala je potreba za osmiljavanjem drugaije kodne
arhitekture. Npr. u Windows operativnom sustavu, u prozoru koji nudi vie od samo jedne
mogunosti, takav program ne bi imao mogunost otkriti koji gumb (naredbu) je korisnik
kliknuo. Drugim rijeima, nastaje potreba za osmiljavanjem sustava koji e moi pratiti
akcije koje je korisnik napravio i temeljem njih reagirati na potreban nain.
Programiranje pogonjeno dogaajima (engl. event-driven programming) je pristup
koji se znatno razlikuje od klasinog proceduralnog programiranja, jer se dijelovi koda
odvijaju pri aktivaciji dogaaja. To moe biti npr., klik na gumb, fokusiranje elementa,
pritisak tipke na tipkovnici, prijelaz preko odreene povrine na suelju, itd. Sve ovo su
razliite vrste dogaaja koje je mogue pratiti, a to programeru omoguuje da odrauje
ba onu funkcionalnost koja je potrebna. To mogu biti npr., prikaz, skrivanje ili pomicanje
elemenata na suelju, prikaz ili spremanje podataka u bazu, zatvaranje programa, itd.
Ovakav nain rada je zapravo najprisutniji u dananjem programiranju jer su aplikacije i
suelja jednostavno dizajnirana tako da je njihovo funkcioniranje mogue ostvariti jedino
putem ovog koncepta.
No, na koji nain programsko okruenje doznaje za neki dogaaj? Radi se, zapravo, o
konstantom ispitivanju okruenja u kojemu se korisnik nalazi. Iako to korisniku nije vidljivo,
u pozadinskom dijelu svakog programa pogonjenog dogaajima nalazi se petlja (engl.
event-loop, naziv koji se takoer koristi je i event-listener) koja provjerava sve elemente
na kojima se moe ostvariti dogaaj (poput klika, fokusiranja i sl.). Ukoliko se stanje
promijenilo, takva petlja e odmah izvriti funkciju na istom elementu koja e odraditi
ono to je programer specificirao. Funkcije koje se izvravaju nakon odreenog dogaaja
nazivaju se callback ili handler funkcijama. Ova generalna ideja je prikazana na sljedeoj
slici (slika 7):

224
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Slika 7. Koncept detektiranja dogaaja

Izvor: Obrada autora

Osim velike fleksibilnosti koju ovaj kocenpt prua, postoji i jo nekoliko prednosti kao to su:
strukturiranost i kontrola (razdvojen kd),
omoguava izradu boljih suelja,
kompleksnije kdne strukture i vee mogunosti (neovisan kd).
Pored opisane primjene, slian koncept se primjenjuje i u objektno-orijentiranom kontekstu, a koji
e detaljnije biti analizirati u sljedeem odlomku.
2.5.1 Klase za praenje stanja objekta
U uvodnom dijelu ovog poglavlja, u kojem su prikazani kljuni elementi programiranja pogonjenog
dogaajima, govorilo se uglavnom o primjeni koncepta pri izradi suelja i definiranju interakcije
s korisnikom. U nastavku slijedi malo drugaija implementacija pristupa koji ima elemente
programiranja pogonjenog dogaajima te neke vlastite specifine zahtjeve i karakteristike, a sluit
e za praenje stanja objekata te izvoenju adekvatnih callback funkcija.
Cilj izrade klasa za praenje stanja objekta (klasa Observer) je takoer postojanje veza izmeu
elemenata u zajednikom okruenju koje e omoguiti praenje njihova stanja, no, konkretno, ovog
puta navedeni elementi su zapravo objekti. Npr., za promjenu stanja jednog objekta, ostali ovisni
objekti e moi saznati za tu promjenu te reagirati po potrebi. Fleksibilnost, definirana na ovaj nain,
moe omoguiti bolju kontrolu objekata te olakati dodavanje novih funkcionalnosti u postojei kd.
Tok ovog koncepta je vrlo jednostavan, a sastoji se od etiri elementa (ovoga puta koristit emo
englesku terminologiju radi lakeg razumijevanja):
1. Klasa Observable (pratljiva klasa) je zapravo apstraktna klasa ili suelje, koje e svaki
konkretni objekt morati implementirati, a sadravat e potrebne metode za rad s centralnom
klasom Observer (prikljuenje ili iskljuenje Observera, praenje stanja ostalih objekata itd.).
2. Klasa ConcreteObservable (konkretna klasa) koja implementira navedeno suelje, a
predstavlja objekt koji moe mijenjati stanja, pri kojima e doi do obavjetavanja
ostalih objekata klase ConcreteObservable.
3. Klasa Observer (promatra), takoer apstraktna klasa ili suelje, koje mora
implementirati konkretna klasa Observer.
4. Klasa ConcreteObserver konkretna Observer klasa po kojoj e se instancirati svi
Observer objekti, prati i obavjetava objekte o promjenama stanja.

225
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Prvo to je potrebno napraviti jest instanciranje konkretnih pratljivih objekata klase

ConcreteObservable, koji e, naravno, implementrati suelje Observable, ime e biti
obavezni definirati potrebne metode za rad s klasom ConcreteObserver. Nakon toga,
prethodno instancirani navedeni objekti klase ConcreteObserver, moraju se povezati s
pratljivim objektima. Pri prijelazu u nova stanja, ConcreteObserver e obavjetavati
ostale povezane objekte koji e reagirati na odreeni nain, odnosno izvravati odreeni
kd, sami mijenjati stanja itd.
Za primjer, mogue je pretpostaviti da postoji objekt klase Osoba, koja, recimo, predstavlja
oca. Uz navedenu, pretpostavimo prisutnost jo dva objekta, ovoga puta klase Dijete, a
koji predstavljaju djecu prve osobe. Ovim konceptom mogue je izvesti da se, automatski,
pri brisanju prvog objekta (oca), briu i objekti djece. Za ovo bi, naravno, bio odgovoran
spomenuti ConcreteObserver, koji bi o promjeni stanja obavijestio preostala dva objekta,
a koji bi onda reagirali na isti nain. Navedena logika za odreene situacije u kojima djeca
nisu od velike vanosti sasvim je korektna, a i pritom automatizirana.
Mogue je uvidjeti da i ovdje postoje, na neki nain, dogaaji koji mogu izazvati promjene
u drugim dijelovima koda, odnosno u drugim objektima. Ovaj koncept je poznat ve due
vrijeme i primjenjuje se upravo zbog fleksibilnosti i automatizacije koju je mogue postii.
Osim toga, takoer smanjuje mogunost pogreaka, odnosno mogunost da se objekti ne
nau u nekom od neloginih stanja.
2.5.2 Programiranje pogonjeno dogaajima u PHP-u
U ovom poglavlju bit e prikazana primjena programiranja pogonjenog dogaajima u
PHP-u, tako to e se pokuati emulirati originalna ideja. Ono to e zapravo biti uinjeno
jest interakcija izmeu odreenih dijelova kda, gdje e jedan dio pozivati jedan ili vie
drugih dijelova i to putem emitiranja dogaaja. Nakon toga, funkcije koje su se prethodno
registirale kao callback funkcija za navedeni dogaaj e se izvriti (funkcija, dakako, moe
biti vie od samo jedne). Potrebno je uzeti obzir da e i ti pozvani dijelovi takoer imati
mogunost emitiranja dogaaja, odnosno poziva drugih dijelova kda, pa ak i onog iz
kojega je poziv izvorno stigao, stoga je ponekad potrebno pripaziti da program ne ue u
beskonanu petlju (mogue je, dakako, i implementirati provjeru koja e osigurati da ne
doe do ovakvih pogreaka).
Implementacija programiranja pogonjenog dogaajima u radni okvir zapravo nije
sloen korak. Prije analize kda, slijedi okvirni prikaz na koji nain e se ostvariti eljena
funkcionalnost (slika 8). Prije svega, prvo to je potrebno napraviti jest registrirati callback
funkcije za odreene dogaaje (toka 1). Drugim rijeima, upisat e se imena metoda
koje se moraju izvriti pri odreenom dogaaju. Nakon toga, pri svakoj inicijalizaciji
sustava, sve metode e se prikupiti (toka 2) i pohraniti u internu varijablu kako bi bile
stalno dostupne ostatku sustava. I sada se dolazi, zapravo, do konkretnog sluaja (toka
3) u kojemu se nalazi emitiranje dogaaja (engl. firing an event) gdje e sustav potraiti
ima li registirirane callback funkcije za dobiveni dogaaj. Ako one postoje, sustav e ih
jednostavno izvriti (toka 4)., a u protivnom se nita nee dogoditi.

226
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Slika 8. Nain implementacije naina rada pogonjenog dogaajima

Izvor: Obrada autora

Registriranje callback funkcija je vrlo jednostavno, sve potrebne parametre potrebno je unijeti
u XML datoteku events.xml. Radi bolje preglednosti, programer moe za svaki modul kreirati
zasebnu datoteku i u njoj upisivati callback funkcije. Sadraj jedne datoteke events.xml prikazan je
u sljedeem isjeku kda:

1 <events>
2 <event>
3 <type>beforeController</type>
4 <callback>Pages|updatePageStats</callback>
5 </event>
6 <event>
7 <type>afterController</type>
8 <callback>Pages|test</callback>
9 </event>
10 </events>

U primjeru se zapravno nalaze dvije registrirane callback funkcije koje e se pozivati

na dogaajima beforeController i afterController. Mogue je uvidjeti da su ovo zapravo
dogaaji koje izvrava sam sustav pri svojoj inicijalizaciji. Ovo je ugraeno s ciljem
da se programeru pruaju dodatne mogunosti izvravanja dodatnih operacija prije
uitavanja kontrolera i poslije. Naravno, ovdje su mogli biti dogaaji koje je definirao
sam programer, a mogue je i dodati dodatne dogaaje sustava, kao npr., prije same
inicijalizacije i na kraju. Poslije type parametra slijedi definiranje callback funkcije koja
e se pozvati. Sustav podrazumijeva da e se definicije tih funkcija nalaziti u poznatim
datotekama kontrolera, stoga je u parametru potrebno upisati samo ime kontrolera i
njegovu metodu, to se odvaja znakom |.
Nakon toga, sve to preostaje je izvravanje dogaaja u kontroleru, a to e biti uinjeno
pomou posebne metode koja je prethodno ugraena u radni okvir. Ova metoda
e proi kroz internu varijablu u kojoj su spremljene sve callback funkcije i provjeriti
postoje li one koje su definirane za dani dogaaj. to se tie poretka izvravanja,
odnosno prioriteta, ovo je takoer jednostavno izvedeno, i to tako da se u events.xml
callback funkcije upisuju u eljenom poretku. Ako je potrebno promijeniti prioritet
227
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

izvravanja, dovoljno je samo zamijeniti mjesta registriranja funkcija u datoteci i sustav

e izvravati funkcije po novom poretku.

3. Implementacija modula za upravljanje korisnicima

i korisnikim grupama
U ovom poglavlju bit e prikazan postupak izrade pojednostavljenog modula za kreiranje korisnika
te korisnikih grupa. Navedenim primjerom e se pokazati koliko je jednostavno i brzo mogue
kreirati dijelove aplikacija ovim radnim okvirom, odnosno njegovim ugraenim komponentama.
Za poetak, potrebno je definirati konani cilj ostvariv izradom ovog modula. Korisnik e imati
sljedee mogunosti:
1. pregledavati trenutno unesene korisnike iz tablice,
2. dodavati, brisati, mijenjati korisnike spremljene u bazi podataka,
3. pregledavati trenutno unesene korisnike grupe iz tablice,
4. dodavati, brisati, mijenjati korisnike grupe spremljene u bazi podataka.
3.1 Tipovi entiteta i baza podataka
Kako e u sustavu biti potrebni korisnici i korisnike grupe, kreirat e se dva tipa entiteta i to User i
Usergroup. Potrebno je napraviti dvije klase i kreirati tablicu u bazi podataka, a sustav e znati kako
stupce tretirati i na koji nain ih spremati. Za svaki entitet je potrebno napraviti nekoliko tablica u
bazi, i to prema sljedem SQL kdu:
1 CREATETABLE`user`(
2 `id`BIGINT(10)NOTNULLAUTO_INCREMENT,
3 `username`VARCHAR(20)NULLDEFAULTCOLLATEutf8_bin,
4 `usergroup_id`BIGINT(20)NULLDEFAULT0,
5 `password`VARCHAR(20)NULLDEFAULTCOLLATEutf8_bin,
6 `first_name`VARCHAR(30)NULLDEFAULTCOLLATEutf8_bin,
7 `last_name`VARCHAR(30)NULLDEFAULTCOLLATEutf8_bin,
8 `age`INT(10)NULLDEFAULTNULL,
9 PRIMARYKEY(`id`)
10 )
11 COLLATE=utf8_bin
12 ENGINE=InnoDB

Navedenim SQL kdom kreirat e se tablica u bazi po imenu user i to s gore navedenim
stupcima, od kojih e svaki sadravati konkretan podatak osim usergroup_id, koji predstavlja
vanjski klju korisnike grupe za koju e korisnik biti vezan. Vanjski kljuevi, kao to je i navedeno
u prethodnim poglavljima, moraju sadravati sufiks _id zbog ORM suelja koje e pri uitavanju
podataka prepoznati da se ovdje radi o drugom entitetu, odnosno o korisnikoj grupi. Nakon
ovoga, potrebna je i, naravno, tablica korisnikih grupa koja je prikazana u narednom odsjeku
kda. Ovdje postoji prostor za dodavanje jo nekih podataka, no zbog ovog primjera nastojalo
se maksimalno pojednostaviti strukturu. Nakon pripreme entiteta i baze podataka, slijedi izrada
kontrolera koji e upravljati aplikacijom.

228
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

1 CREATETABLE`usergroup`(
2 `id`INT(10)NOTNULLAUTO_INCREMENT,
3 `name`VARCHAR(50)NULLDEFAULTCOLLATEutf8_bin,
4 PRIMARYKEY(`id`)
5 )
6 COLLATE=utf8_bin
7 ENGINE=InnoDB

3.2 Izrada kontrolera i predloaka

Kako postoje dvije sekcije aplikacije, odnosno korisnici i korisnike grupe, tako e
biti potrebno kreirati i dva kontrolera, te na taj nain odvojiti logiku. U aplikaciji je
definiran dio kda odgovoran za upravljanje korisnicima. Koristi se metoda index() koja
je odgovorna je za prikazivanje poetne stranice, odnosno popisa svih korisnika zbog
ega je i koritena metoda get(), ime se dohvaaju svi korisnici. Osim toga, specijalno
za ovu aplikaciju razvijena je i Grid klasa koja e automatski generirati potreban HTML
kd za kreiranje tablice koju e ujedno i popuniti s podacima. Klikom na gumb Add
user korisnik dolazi na drugu stranicu, iji tok kontrolira metoda action() (iz prethodno
prikazanog kda). Potrebno je napomenuti da e ova ista metoda biti odgovorna za
kreiranja novog korisnika, ali i za auriranje postojeih. Ovo se moglo izvesti pisanjem dvije
razliite metode, no ponekad je kd zgodnije smanjiti, pogotovo kada je mogue postii
vie razliitih funkcionalnosti. Kd metode action() zapravo na samom poetku provjeva
jesu li poslani podaci iz formulara koritenjem metode $_POST. Ukoliko jesu, to znai da
je korisnik popunio obrazac, te je upisane podatke potrebno spremiti. U suprotnome,
uitava korisnika prema dobivenom ID-ju iz URL-a. Ako je validan, entitet User e se
uspjeno popuniti potrebnim podacima koji e se zatim prenijeti i u predloak koji e se
koristiti za prikaz formulara. U suprotnome, entitet se nee popuniti podacima, te e se
korisniku prikazati prazan formular. Kako je pri kreiranju korisnika potrebno odrediti kojoj
e korisnikoj grupi pripasti, tako su i uitane sve korisnike grupe.
1 class User extends Controller{
2 public function index() {
3 $e = new Entity();
4 $users = $e->get(User);
5 $columns = array(username => Username, first_name => First name, last_name => Last name,
6 usergroup|name => Usergroup);
7 $grid = new Grid(datatable, users);
8 $grid->setColumns($columns)->setData($users);
9 $this->grid = $grid->render(); }
10 public function action(){
11 $user = new UserEntity();
12 if (_getParam(id)) {
13 $user->load(_getParam(id));
14 }
15 if (isset($_POST) && count($_POST) > 0) {
16 $user->populate($_POST)->save();}
17 $e = new Entity();
18 $this->usergroups = $e->get(Usergroup);
19 $this->user = $user->load(_getParam(id));}

229
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

3.3 Auriranje statistike stranica

U poglavlju koje je bilo posveeno implementaciji kda pogonjenog dogaajima, spomenuto je
da se prije i poslije instanciranja svakog kontrolera emitiraju sustavni dogaaji beforeController
i afterController. U ovom primjeru e se ovi dogaaji iskoristiti kako bi se zapisao broj posjeta
odreenoj stranici. Ukratko, registrirat e se funkcija na beforeController dogaaju, a koja e
dobivenoj stranici poveati broj posjeta.
Za poetak, pogledajmo datoteku events.xml pomou koje e se odraditi registracija dogaaja i
callback funkcije:
1 <event>
2 <type>beforeController</type>
3 <callback>Pages|updatePageStats</callback>
4 </event>
Ovih nekoliko poprilino jednostavnih linija kda omoguit e, prije svake inicijalizacije
kontrolera (na beforeController dogaaju), izvrenje funkcije updatePageStats(). Navedena
funkcija je prikazana u sljedeem isjeku kda:

1 public function updatePageStats() {

2 $model = new Page_Stats();
3 $model->updatePageStats(Application::$action);
4 Application::fireEvent(korisnik_dod);
5 }

Navedena funkcija e samo instancirati objekt klase Page_Stats te na njemu pozvati metodu
updatePageStats(), a kao parametar proslijediti naziv trenutne akcije. Navedena metoda zapravo
samo izvrava SQL upit koji e aurirati statistiku tako to e za trenutnu stranicu, ukoliko nije
upisana u tablici, u tablici page_stats kreirati redak s poetnom vrijednosti statistike koja iznosi 1.
Ukoliko doe do ponovnog uitavanja iste stranice, u tablici se nee ponovno kreirati isti redak za
trenutnu stranicu, ve e se isti poveati za 1, to je postignuto s ON DUPLICATE KEY UPDATE
komandom (pri upitu na MySQL).
Ovo je bio jednostavan primjer na kojem moemo iskoristiti ugraeni mehanizam pogonjen
dogaajima u naem radnom okviru. Osim to imamo veliku fleksibilnost, ovom metodom
omoguili smo suradnju razliitih dijelova sustava te istovremeno njihovu potpunu neovisnost.
Gore navedena funkcija se, naravno, moe proiriti, a programer ima i mogunosti dodavati
funkcije za svaku situaciju u kojoj je potrebno koristiti callback funkciju. Neki od primjera dogaaja
na koje moemo registrirati funkcije su uspjena autorizacija korisnika, kreiranje stranice, kreiranje
ili brisanje korisnika, upload datoteke, itd.

4. ZAKLJUAK
Zbog sve sloenijih i zahtjevnih aplikacija, programeri moraju traiti sve bolja sredstva rada.
Repetitivne radnje se moraju svesti na minimum. U prvom planu mora biti razvoj same aplikacije,
a ne rjeavanje problema programskog jezika (ili ponekad ak radnog okvira) koji je u uporabi.

230
 A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Ovim radom nastojalo se barem djelomino prikazati to se moe postii pisanjem vlastitog
radnog okvira. Na temelju vlastitog iskustva s drugim radnim okvirima i tehnologijama, nastojalo
se uiniti programiranje to prirodnijim i jednostavnijim procesom, to je vrlo esto problem u
drugim razvojnim okruenjima. esto koritenje klasa neintuitivnih imena, ponekad nejasne logike
i strukture, te sama teina radnog okvira, odnosno njegova dodatna procesiranja, mogu uiniti
cijeli radni okvir manje efikasnim i nezgodnim za koritenje.
Iako je za potpunu funkcionalnost potrebno osmisliti vei broj komponenata, najvaniji je,
zapravo, pravilan rad cijeloga sustava kao cjeline te omoguavanje lakog pristupa programeru
komponentama sustava. Osim to programer ovime dobiva skup alata koji e mu omoguiti bri i
efikasniji rad, radni okvir svojim ugraenim konvencijama e takoer forsirati skladnu i dosljednu
strukturu, to e pasivno omoguiti organiziranije pisanje kda te dodavanje dodatnih komponenti
po potrebi.
Radni okvir koji je ovdje izraen ipak predstavlja samo temeljne i najnunije alate, zbog ega bi bilo
zgodno uvesti jo neke dodatne komponente, kao to su sustav za autorizaciju i autentifikaciju
korisnika, integracija dodatnih cache mehanizama, mogunost koritenja kratkih ruta, izrada
CMS rjeenja, komponenti za viejezine aplikacije, slanje elektronike pote, itd. No, s jasnom
strukturom i pravilima, ovaj posao bi se trebao olakati, a s podranom modularnom strukturom,
pisanje posebnih modula specifinih za pojedini projekt mogue je ponovno iskoristiti i, po potrebi,
prilagoditi na drugim aplikacijama.
Nakon izrade navedenih komponenti, slijedi odravanje radnog okvira, s obzirom da nove
tehnologije konstantno donose nove mogunosti. Zbog velike koliina posla u ovome segmentu,
ipak bi bilo poeljno okupiti tim programera koji bi zajedno mogli suraivati i doprinositi radnom
okviru. Na ovaj nain, budui posao razvoja aplikacija bit e jo bri, a samim time i produktivniji.

LITERATURA
Adams, J. (2013) Learning Kendo UI Web Development, Packt Publishing Ltd.
Ahsanul B., Anupom S., (2008) Cake PHP Application Development, Birmingham: Packg Publishing Ltd.
Eckerson, W. W. (1995) Three tier client/server architectures: achieving scalability, performance, and efficiency in client/
server applications, Open Information Systems, 3(20), p. 46-50
Fowler P. et al. (2002) Patterns of Enterprise Application Architecture, Addison Wesley
Hayder, H., Gheorghe, L. (2006) Smarty PHP Template Programming And Applications. Packt Publishing Ltd.
Krasner, G. E.; Pope, S. T. (1988) A cookbook for using the modelview controller user interface paradigm in Smalltalk-80.
Journal of Object-Oriented Programming, 1(3) p. 26-49
Matkovi S. et al. (2006) Osnove programiranja u okruenju grafikih operativnih sistema: Programski jezik C#, Beograd:
RG i CET
McArthur, K. (2008) Pro PHP: Patterns, Frameworks, Testing and More. Apress.
Sarode, P. (2001) Writing a reusable implementation of the MVC design pattern, JAVA REPORT, Volume: 6, Issue: 7
SensioLabs, (2013) The Book for Symfony 2.3 (10. 8. 2013.)
ribar J., Motik B. (2010) Demistificirani C++, Zagreb: Element

231
A. Smijulj, A. Metrovi: Izgradnja MVC modularnog radnog okvira
Zbornik Veleuilita u Rijeci, Vol. 2 (2014), No. 1, pp. 215-232

Adrian Smijulj 1 Professional paper

Ana Metrovi 2 UDC 004.415.2

MVC MODULAR FRAMEWORK BUILDING3

ABSTRACT
The objective of this paper was to provide an overview of the existing technologies and components related
to framework creation and to show implementation of a simple framework that contains the most essential
components for rapid development of web applications. In the first part of the paper, the theoretical considerations
related to the implementation of the framework in developing applications are presented. Potential components
of the framework are presented and analyzed on the theoretical level. The second part shows the implementation
of the framework using modern technologies like PHP, MySQL, HTML etc. The presented framework is built using
the object-oriented approach. The MVC architecture and ORM tools such as automated interface are used to
work with the entities and for event management system. The advantage of the presented approach is that the
programmer will not have to invest time in architecture design and tool development any more, but will be fully
able to focus on project tasks. Although it contains only the core components, the framework will be flexible
thanks to its modular architecture, allowing the developer to extend it to suit ones specific needs and to adapt
it to the requirements of the application to be developed. To conclude, while developing complex applications it
is advisable to invest time in making a framework or similar component that will later enable faster and more
reliable development of the application.

Key words: model-view-controller architecture (MVC), framework, event driven programming, modular
systems, PHP

1
B. Ed. E-mail: adrian.1358@gmail.com
2
PhD, Assistant professor, Department of informatics University of Rijeka, Radmile Mateji 2, Rijeka, Croatia.
E-mail: amestrovic@inf.uniri.hr
3
Received: 27. 2. 2014.; accepted: 5. 5. 2014.

232