Saa Tadi, dipl ing raunarske tehnike web site: http://sasatadic.net46.net/Crvanj e-mail: sasatadict@yahoo.com Podgorica

Struktura foldera JOOMLAU ovom tekstu emo se potruditi da prezentiramo naelnu organizaciju softvera koji se razvija pod JOOMLA sistemom. Struktura foldera neke hipotetine web prezentacije (npr myPortal) koju smo napravili u JOOMLA! je prikazana na sljedeoj slici. Kontrola rada aplikacije je podjeljena u 2 dijela: front end (korisniki dio) i back end (administratorski dio). Programske cjeline ekstenzije relevantne za back end su nalaze ispod foldera MyPortal/administrator. Svi ostali folderi ispod MyPortal su na neki nain vezani za front end dio aplikacije

Kada je rije o razvoju JOOMLA aplikacije, interesantni su nam: Template Components Modules Plugins Ako pogledamo prethodnu sliku, primjetiemo da u administrativnom folderu (za back end) imamo podfoldere za template, components i modules a u MyPortal folderu (za front end) imamo pored prethdno pobrojanih subfoldera backenda i podfolder za plugin-ove (koji nemaju ili ne moraju da imaju svoj administrativni podfolder). Ovo je naelna postavka. To znai da nije neophodno da bude tako i nije neophodno da savka front end komponenta i modul obavezno imaju back end - moemo napraviti npr komponentu koja prihvata komentare korisnika na na lanak na site-u a koju administrator sistema ne mora da pregleda kroz back end kroz neki svoj specifini modul

1

Templates Svaki template koji se koristi u aplikaciji ispod template foldera ima svoj jedinstveni podfolder. I za back end i za front end konceptualni sadraj template foldera je identian i obuhvata nekoliko osnovnih fajlova: Index.php (glavni programski modul - stranica sa definicijom izgleda templatea) Templatedetail.xml (XML file u kojem je popis svih fajlova i foldera konkretnog template-a) template_thumbnail.png - sliica template-a koja se koristi prilikom dizajniranja GUI-a za instalaciju template-a Template-i imaju i nekoliko podfoldera: CSS - folder sa css file-ovima koji se koriste za definisanje stilova u konkretnom template-u IMAGES - folder sa slikama koji se koriste za izradu stranice template-a (ovdje se ne smjetaju slike koje koristi krajnji korisnik u raznim dokumentima na prezentaciji - koje se inae postavljaju u folder MyPortal/images ukoliko slikama rukuje ugradjena JOOMLA komponenta za multimediju HTML - opcionalno dodatna html dokumenta relevantna samo za template JS - opcionalno dodatni folder sa java scriptovima relevantni samo za template Komponente Na sljedeem UML sequence dijagramu je prikazan konceptualni tok poruka unutar aplikacije (neke konkretne komponente) realizovane u JOOMLA sistemu za web portal a koja podrava MWC arhitekturu

Kada pozovemo nau aplikaciju - neku konkretnu komponentu (u ovom sluaju book), Joomla e staviti u izvrenje book.php source. Book.php prihvata zahtjev i prosljedjuje ga svom kontroleru (controller.php). Kontroler ima funkciju upravljanja cjelokupnim tokom aplikacije. On e opsluivati podatke izvravanjem metode getModel i takodje odluivati o nainu na koji treba izvriti prezentaciju podataka - izvriti izbor templatea (pozivom GetView metode). Prezentacioni sloj (vew) e preuzeti podatke od modela (model layer) i vratiti ih na ekran krajnjem korisniku

2

I u front i u back end-u komponenta koja se pravi se smjeta u folder ije ime poinje sa "com_" (recimo com_test). Ispod ovog foldera sa treba nalaziti test.php file koji je ulazna taka za pokretanje aplikacije - komponente. Potujui Model-View-Controller (MWC) arhitekturu i front end i back end dio komponente treba da ima odvojene cjeline za model, za view i za controller dijelove Startni source program komponente (test.php) treba da poziva kontroler file koji se nalazi ili u com_ folderu pod imenom controller.php ili, ako je komponenta sloenija i ima nekoliko razliitih dijelova, tada ispod com_ foldera postoji sub folder controllers sa odvojenim php fajlovima za svaki od kontrolera - jedan kontroler kontrolie jednu podfunkcionalnost Back end dio JOOMLA ima folder tables i u njemu za svaku tabelu iz baze podataka koju koristi komponenta po jedan php file. U ovom fajlu je definisana klasa podataka tipa tabele u bazi podataka na koju se odnosi i u njoj su definisane privatne promjenljive koje odgovaraju atributima tabele kao i sve public funkcije za rada sa konkretnom tabelom u bazi podataka Za pristup podacima u tabeli baze podataka (koristei klasu definisanu u prethodnom paragrafu) i njihovo prosljeivanje prezentacionom djelu sistema je zaduen podsistem model. Za svaki specifian skup podataka (za svaki specifian select upit ili grupu select upita koji obezbjeuju prikaz podataka na GUI-u) se definie specifian php source file jedan model a svi oni se nalaze u folderu models koji je jedan od podfoldera COM_ foldera. Ovaj specifian select upit nema ekskluzivnu pripadnost nekom konkretnom kontroleru. Vie kontrolera mogu izabrati isti model i isti select upit. Na kraju, za prezentaciju podataka su zadueni sorce-vi koji se nalaze ispod views subfoldera u com_ folderu. U VIEWS podfolderu se nalazi onoliko novih podfoldera koliko smo imali model php fajlova. Ovi podfolderi bi trebali da imaju imena koja smo koristili porilikom definisanja model php fajlova. Svaki od ovako kreiranih podfoldera ima identian sadraj: jedan view.html.php file i jedan tmpl podfolder u kojem se nalazi form.php file. Form.php file je u stvari isti HTML fajl koji sadri tagove za prikaz na

3

ekranu dok view.html.php fajl obezbjeuje transformaciju podataka iz select upita koji su prosljeeni iz model dijala sistema u pojedinana polja koja e se prikazivati na GUI-u. Na kraju, da bi kroz meni sistem u back end-u imali pristup back end djelu komponente, slog sa podacima o naoj komponenti treba da bude upisan u tabelu ___components baze podataka u kojem se kao jedan atribut prosljedjuje vrijednost pozivajueg parametra komponente. U front end djelu aplikacije se komponenta najee vezuje uz menu item tako da se pokree aktiviranjem stavke menija. U back end-u u djelu za administraciju menija, konfiguracioni wizard dozvoljava da se uz stavku menija vee bilo koja aktivna komponenta koja je definisana u ____components. Modules Struktura foldera za JOOMLA module potuje filozofiju koja je postavljena i za komponente, mada je modul mnogo jednostavniji koncept od komponente tako da MVC paradigma nije razvijene do kraja. I u front i u back end-u modul koji se pravi se smjeta u folder ije ime poinje sa "mod_" (recimo mod_test). Ispod ovog foldera sa treba nalaziti test.php file koji je ulazna taka za pokretanje modula. U istom folderu se nalazi esto i mod_test.xml file koji sadri definicije svih fajlova koji se isporuuju uz modul kao i opciono vrijednosti za parametre (koji se, ako postoje mogu mjenjati kroz back end dio aplikacije) U istom folderu se nalazi helper.php fajl koji sadri helper klasu u kojoj su definisane sve funkcije koje su potrebne za realizaciju modula kao i svi eventualni upiti prema bazi podataka ukoliko su potrebni. Na taj nain se iz test.php fajla, za bilo koju funkcionalnost koja ne postoji u php i drugim sistemskim bibliotekama poziva funkcija koja se nalazi u helper.php datoteci. Na kraju, svaki modul, ukoliko je treba da prikazuje podatke u web brouser-u bi trebalo da ima tmpl sub folder sa fajlom pod imenom default.php koji procesira podatke iz helper.php file-a na GUI. Svaki modul je potrebno definisati u ___modules tabeli baze podataka. Time se kroz wizard back end-a otvara mogunost da se definie u kojoj sekciji template-a treba da se prikae modul i unutar kojih menija modul na front end-u treba da bude aktivan. PlugIn PlugIn-ovi sadre rutine koje su vezane za neke dogaaje u sistemu. Kada se desi neki dogaaj u sistemu, svi PlugIn-ovi koji su vezani za taj dogaaj se aktiviraju.

4

Struktura foldra PlugIna Joomla 1.5

Struktura foldra PlugIna Joomla 1.6 U Joomla folderu u kojem se nalaze PlugIn-ovi je formirano nekoliko podfoldera content, editors, search, user, system itd (pogledajte sliku). Svaki podfolder sadri grupu plugin-ova koji se odnose na neku grupu trigera: content, editors, search, user, system itd. Ispod ovih foldra nivoa grupa trigera se nalaze folderi (JOOMLa ver 1.6) sa konkretnim sorce kodom za plugin (svaki folder sadri tano jedan plugin). Folder sa plugin-om sadri najmanje 2 fajla - XML fajl sa opisom sadraja foldera i php file sa programskim kodom. I php i xml file imaju ime subfoldera u kojem su kreirani. Treba napomenuti da u verziji JOOMLA 1.5 ne postoje podfolderi za konkretan PlugIn ve su svig pluginovi koji pripadaju jednoj grupi u jednom folderu.

5

Arhitektura Joomla PlugIn-ova podrava koncept Observer ablona iz UML koncepta. Svi PlugIn-ovi se izvode iz definicije klase Jplugin. Prilikom kreiranja PlugIna obavezno je u PHP file-u u kojem se on kreira specificirati jimport( 'joomla.plugin.plugin' ); U nastavku PHP koda slijedi definicija klase plugin-a ije ime se formira (preporuka) od "plg" + imena foldra ispod plugin foldera (grupa trigera - user, content, editor...) + imena podfoldra (tj imena php filea). Tako bi ime klase - plugina moglo biti class plgContentVote . U prethodnom primjeru imena je Content grupa trigera a Vote podgrupa. Prava sintakstno korektna deklaracija imena bi bila: class plgContentVote extends Jplugin Jplugin klasa ima vei broj funkcija a kreiranjem konkretnog plugina se vri redefinicija jedne od njih. Funkcije imaju imena koja su u vezi sa imenom konkretnog trigera tako da se programski kod svodi na definiciju tjela funkcije - recimo u naoj klasi plgContentVote moemo imati funkciju: function onBeforeContentSave( param1 , param2) { ........ } Kada se u sistemu desi dogadjaj onBeforeContentSave, izvrsice se i ovaj plugin.

6