Strahinja Lazetic Razvoj Generatora Spring Aplikacija Primenom Freemarker Sablona i Hibernate Okvira

7/21/2019 Strahinja Lazetic Razvoj Generatora Spring Aplikacija Primenom Freemarker Sablona i Hibernate Okvira

1/131

UNIVERZITET U BEOGRADU

FAKULTET ORGANIZACIONIH NAUKA

ZAVRNI (MASTER) RAD

Razvoj generatora Spring aplikacija primenom

Freemarker ablona i Hibernate okvira

Strahinja Laeti

BeogradNovembar, 2010


2/131


3/131

i

UNIVERZITET U BEOGRADU

FAKULTET ORGANIZACIONIH NAUKAOdsek za informacione sisteme i tehnologije

ZAVRNI (MASTER) RADRazvoj generatora Spring aplikacija primenom

Freemarker ablona i Hibernate okvira

Mentor: Kandidat:dr Sinia Vlaji, doc. Strahinja Laeti5/2008

BeogradNovembar, 2010


4/131

ii

Komisija koja je pregledala rad

kandidata LAETI(NEBOJA) STRAHINJE

pod naslovom RAZVOJ GENERATORA SPRING APLIKACIJA PRIMENOMFREEMARKER ABLONA I HIBERNATE OKVIRA i odobrila odbranu:

Mentor: dr Sinia Vlaji, docent

_________________________________________

lan: dr Saa Lazarevi, docent

_________________________________________

lan: dr Dragana Beejski Vujaklija, vanredni profesor

_________________________________________


5/131

iii

Abstrakt:

U ovom radu e biti predstavljen razvoj generatora web aplikacija realizovanih u Spring

tehnologiji. Generator e biti projektovan korienjem Freemarker ablona i Hibernate okvira.

Pored prikaza ovih tehnologija bie opisane i koristi i nedostaci korienja generatora kao

metode razvoja softvera. Na kraju e detaljno biti prikazan ceo proces razvoja sopstvenog

generatora aplikacija.

Kljune rei: Generator web aplikacija, Spring, Freemarker, Hibernate

Abstract:

This paper will present development of Spring based web applications generator. The

generator will be designed using Freemarker template and Hibernate framework. In addition,

there will be described advantages and disadvantages of generator using as a software

development method. In the final chapter the whole process of generator design will be

presented in details.

Keywords: Web applications generator, Spring, Freemarker, Hibernate


6/131

iv

Curriculum Vitae

Osnovni podaci

Ime: Strahinja Laeti Datum i mesto roenja: 28.06.1984, Beograd, Srbija Kuna adresa: Borivoja Stevanovia 37, 11050 Beograd, Srbija

Telefon: 063/852-8621 E-mail: [email protected]

Obrazovanje

2008 - Fakultet organizacionih nauka, Odsek za informacione sisteme i tehnologije,Univerzitet u Beogradu, Diplomske (Master) studije

2003 - 2008: Fakultet organizacionih nauka, Odsek za informacione sisteme i tehnologije,Univerzitet u Beogradu, diplomirao sa srednjom ocenom 9.23. Diplomski rad: Uporednipregled platformi za Data Mining, ocena 10

1999 - 2003: III Beogradska gimnazija, prirodno-matematiki smer

Radno iskustvo

Decembar 2008 -

Firma: Comtrade ITSSPozicija: Software developer

Opis posla: Razvoj web aplikacija korienjem JavaEE, JBoss Seam i Hibernate tehnologija

Jul 2007-Septembar 2007

Firma: Politehniki Univerzitet Hong Kong (IASTE studentska praksa)Pozicija: Student pomonikOpis posla: Razvoj web aplikacija za potrebe Univerziteta korienjem MySQL, PHP iJavaScript tehnologija

Sertifikati

IBM InfoSphere Information Server Technical Professional

TOEFL sertifikat (iBT 100/120)

Tehnika znanja

Programski i skript jezici : Java2SE, JEE, PHP, Freemarker, HTML, JavaScript, CSS

Softverski okviri: JSF, RichFaces, Facelets, Hibernate, JBoss Seam, Spring

Aplikacioni i web serveri: Apache web server, Tomcat, JBoss, GlassFish

SUBP: Oracle, SQLServer, MySQL, PostgreSQL

Razvojna okruenja: Eclipse IDE, NetBeans Operativni sistemi: Windows (XP, 7), Linux (Ubuntu)

Ostali alati: Maven 2, SVN, Apache Ant, JasperReports, iReport, Pentaho Data Integration,IBM WebSphere Integration Developer, SPSS Clementine, Dreamweaver, MathLab

Profesionalna interesovanja

Projektovanje web aplikacija Dizajn baza podataka

Analiza poslovnih procesa

Data Mining

Strani jezici

Engleski (napredni nivo)

Nemaki (poetninivo)

Line osobine

Ambiciozan, odgovoran, sistematian, komunikativan

Ostale vetine i interesovanja

Vozaka dozvola B kategorije, aktivan voza Atletika (prethodno profesionalno, dravni prvak 2005. godine), plivanje, klasina gitara,

putovanja


7/131

v

SADRAJ:

1. UVOD ................................................................................................................... 1

2. GENERATORI APLIKACIJA ............................................................................... 3

2.1. Osnovni elementi generatora .................................................................................................... 3

2.2. Opravdanost pravljenja generatora .......................................................................................... 4

3. SPRING WEB MVC .............................................................................................. 7

3.1. Konfigurisanje i pokretanje kontejnera .................................................................................... 9

3.2. MVC uzor ...................................................................................................................................10

3.2.1. Klasa DispatcherServlet .....................................................................................................123.2.2. Kontroler .............................................................................................................................14

3.2.3. Model i View .......................................................................................................................15

3.2.4. Spring web MVC forme ......................................................................................................16

4. FREEMARKER ABLON .................................................................................. 20

4.1. ablon stranica .........................................................................................................................214.1.1. Oznake za umetanje ...........................................................................................................21

4.1.2. FTL oznake .........................................................................................................................22

4.1.3. Korisniki definisane direktive ............................................................................................25

4.1.4. Funkcije ..............................................................................................................................264.1.5. Promenljive u Freemarker ablonu ....................................................................................274.1.6. Izrazi ...................................................................................................................................27

4.1.6.1. Pristupanje promenljivim ............................................................................................27

4.1.6.2. Operacije nad promenljivim ........................................................................................28

4.1.6.3. Ugraene operacije....................................................................................................28

4.2. Model podataka ........................................................................................................................30

4.2.1. Tipovi promenljivih u modelu podataka ..............................................................................31

4.3. Pokretanje Freemarker procesora ..........................................................................................32

5. HIBERNATE OKVIR........................................................................................... 34

5.1. Perzistencija..............................................................................................................................34

5.2. ORM alati ...................................................................................................................................34

5.3. Hibernate ORM ..........................................................................................................................35

5.3.1. Arhitektura okvira ................................................................................................................35

5.3.2. Konfiguracija okvira ............................................................................................................37

5.4. Hibernate arhitektura generisanja proizvoda ........................................................................40

5.4.1. Hibernate meta model ........................................................................................................40

5.4.1.1. Konfiguracije ...............................................................................................................42


8/131

vi

5.4.2. Pokretanje Hibernate generatorabiblioteka hibernate-tool.............................................425.4.3. Ant ......................................................................................................................................43

5.4.3.1. Datoteka za izgradnju .................................................................................................43

5.4.3.2. Pokretanje Anta ..........................................................................................................46

5.4.4. Ant zadatak ..............................................................................................46

6. RAZVOJ SOPSTVENOG GENERATORA ......................................................... 49

6.1. Razvoj Freemarker ablon stranica ........................................................................................506.1.1. Korisniki zahtevi ................................................................................................................50

6.1.1.1. Sluajevi korienja ....................................................................................................506.1.1.2. Opis sluajeva korienja ...........................................................................................51

6.1.2. Analiza ................................................................................................................................53

6.1.2.1. Ponaanje sistema.....................................................................................................536.1.2.2. Struktura sistema ........................................................................................................57

6.1.3. Projektovanje ......................................................................................................................59

6.1.3.1. Arhitektura softverskog sistema .................................................................................59

6.1.3.2. Projektovanje strukture softverskog sistemaDomenske klase ...............................606.1.3.3. Projektovanje poslovne logikesistemske operacije ................................................656.1.3.4. Projektovanje sloja za pristup podacimaDao klase ................................................726.1.3.5. Projektovanje kontrolera korisnikog interfejsa..........................................................826.1.3.6. Projektovanje korisnikog interfejsa ekranske forme ..............................................906.1.3.7. Projektovanje konfiguracionih datoteka ....................................................................107

6.1.4. Implementacija .................................................................................................................115

6.2. Razvoj generatora meta modela ...........................................................................................115

6.3. Pokretanje generatora ...........................................................................................................117

7. ZAKLJUAK.................................................................................................... 119

LITERATURA ......................................................................................................... 121


9/131

vii

Lista slika:

Slika 1: Opti model generatora aplikacija........................................................................................ 3Slika 2: Ulazi i izlazi iz generatora aplikacija ..................................................................................... 4

Slika 3: Spring moduli [2]...................................................................................................................... 8

Slika 4: JSP Model 2...........................................................................................................................11

Slika 5: Prikaz procesa rada komponenti u Spring web MVC [6].................................................12

Slika 6: Princip rada Freemarker ablona.......................................................................................20

Slika 7: Arhitektura Hibernate okvira [9]...........................................................................................36

Slika 8: Konfigurisanje Hibernate okvira..........................................................................................38

Slika 9: Hibernate meta model [8].....................................................................................................40

Slika 10: Dijagram zavisnosti u build.xml datoteci..........................................................................45

Slika 11: Dijagram generikih sluajeva korienja poslovnih aplikacija....................................51Slika 12: Apstraktni domenski objekat i njegove veze...................................................................58

Slika 13: Tronivojska arhitektura softverskog sistema...................................................................59

Slika 14: ema baze podataka worldcup .........................................................................................60

Slika 15: Arhitektura sloja poslovne logike......................................................................................68

Slika 16: Struktura Dao uzora u generikoj aplikaciji.....................................................................73

Slika 17: Funckionalnosti Spring kontrolera....................................................................................83

Slika 18: Prikaz generike strukture jsp strana u Spring web aplikacijama...............................90

Slika 19: Struktura i funkcije dispatcher-servlet.xml datoteke....................................................107

Slika 20: Dijagram komponenti Spring aplikacije.........................................................................114

Slika 21: Pikaz strukture direktorijuma za izvorne datoteke.......................................................118

Slika 22: Pikaz strukture direktorijuma za pakovanje u war datoteku.......................................118

Lista tabela:

Tabela 1: Opis Sping oznaka za rad sa formama..........................................................................17

Tabela 2: Atributi za definisanje kontroler bean-a..........................................................................19

Tabela 3: Predefinisane direktive u Freemarker ablonu..............................................................24Tabela 4: Mapiranja veza u bazi podataka u veze u domenskim objektima ..............................62

Tabela 5: Mapiranja tipova atributa i veza u HTML elemente......................................................91

Tabela 6: Karakteristini atributi za tipove bean komponenti.....................................................108


10/131

Razvoj generatora Spring aplikacija primenom Freemarker ablona i Hibernate okvira Strahinja Laeti

1

1. Uvod

U vreme kada informacione tehnologije predstavljaju jednu od oblasti poslovanja koje se

razvijaju velikom brzinom, postoji veliki broj firmi koje se bave razvojem softvera i koje sa

istim kvalitetom mogu ispuniti zahteve klijenata. Presudan fakor za dobijanje posla postaje

vreme (i cena koja opet zavisi od vremena) koje je potrebno da se projekat realizuje.

Postavlja se pitanje kako vreme za izradu softvera skratiti, poveati produktivnost i tako biti

ispred konkurencije.

Na naem tritu softvera, veinu aplikacija koje se prave po porudbini klijenta ine

poslovne aplikacije. Poslovne aplikacije predstavljaju informacioni sistem odreene firme, koji

sadri poslovne podatke i operacije za manipulisanje tim podacima. Poslovni podaci su

smeteni u nekoj od baza podataka i gotovo uvek postoji potreba za pregled, unos i izmenu

tih podataka. Ove operacije nad podacima predstavlljaju osnovu za druge, sloenije

operacije. Odatle se vemoe zakljuiti da su poslovne aplikacije donekle standardizovane i

pojavljuje se tenjada se njihov razvoj automatizuje na odreeni nain.

Ovaj rad e se fokusiratina razvoj softverske komponente koja e standardizovane operacije

pregleda, unosa i izmene podataka generisati i tako znatno olakati i ubrzati proces razvoja

softvera.

U uslovima poslovanja velikih firmi poslovne aplikacije su obino distribuirane. Takoe

Internet i posebno web, olakavaju upotrebu takvih aplikacija korienjem internet

pretraivaa. Jedna od brzo razvijajuih i esto korienih tehnologija za razvoj web

distribuiranih aplikacija je Spring okvir. Zbog toga e ova tehnologija biti upotrebljena u

arhitekturi generisanih aplikacija.

Predmet istraivanja ovog rada predstavlja proces razvoja sopstvenog generatora web

aplikacija realizovanih u Spring tehnologiji. Tehnologije koje e se koristiti za razvoj

generatora su Freemarker ablon i Hibernate okvir. Takoe postoji i potreba da se ispita

opravdanost takvog pistupa razvoju softvera, tj. prednostii i nedostaci generisanja aplikacija

nasuprot runom (manual) razvoju softvera.

Iz predmeta istraivanjase mogu izvesti osnovni ciljevi istraivanja:

Opisati tehnologiju Spring okvira

Opisati tehnologiju Freemarker ablona

Opisati tehnologiju Hibernate okvira

Opisati proces razvoja sopstvenog generatora primenom opisanih tehnologija


11/131


2

Ispitati potrebu i opravdanost za razvoj generatora aplikacija kao metode razvoja

softvera

Rad e biti organizovan u sedam poglavlja:

U prvom poglavlju je dat Uvod u kojem su opisani predmet i ciljevi istraivanja.

U drugom poglavlju rada bie ukratko opisani generalni principi na kojima se zasnivaju svi

generatori aplikacija. Takoe e biti opisane i koristi od razvoja generatora i uslovi pod kojim

ne bi trebalo da se koriste.

U treem poglavlju e biti predstavljen Spring okvir (verzija 3.0) sa naglaskom na njegov

modul web MVCkoji e biti upotrebljen za arhitekturu generisanih aplikacija.

etvrto poglavlje e biti posveeno Freemarker ablonu kao tehnologiji na kojoj e se baziratiablon stranice upotrebljene u razvoju generatora. Bie detaljno opisan njegov princip rada,

struktura i najee koriene instrukcije.

Peto poglavlje e se fokusirati na jo jednu tehnologiju koja e se koristiti za razvoj

sopstvenog generator. To je Hibernate okvir. Pregled osnovnih karakteristika ove tehnologije

e biti dat u kratkim crtama dok edetaljnije biti opisana Hibernate arhitektura za generisanje

razliitih proizvoda.

U estom poglavlju e biti prikazan procesrazvoja sopstvenog generatora aplikacija. ablon

stranice e bitiprojektovane korienjem tronivojske arhitekture i Larmanove metode razvoja

softvera.

U poslednjem poglavlju su data zakljuna razmatranja o opisanim tehnologijama i o procesu

razvoja generatora.


12/131


3

2. Generatori aplikacija

2.1. Osnovni elementi generatora

Generator aplikacija predstavalja softversku komponentu koja slui za automatizovano

pravljenje drugih softverskih komponenti [1].

Svaki generator koristi odreeni ulaz i na osnovu definisanih pravila generie izlaz iz

generatora (slika 1).

ULAZ GENERATOR IZLAZ

Slika 1: Opti model generatora aplikacija

Najee korieni ulazi u generator su model podataka i ablon stranice.

Model podatakapredstavlja skup podataka, njihovih tipova i meusobnih veza. Moe biti dat

u vidu xml datoteke u kojoj su definisane tabele i polja baze podataka (xml definicija modela),

kao fiziki objekti baze podataka sa kojima se ostvaruje konekcija ili proizvoljni domenski

objekti (npr. Java Entity klase).

ablon stranicepredstavljaju tekstualne datoteke koje se sastoje iz statikih delova - koje

iniproizvoljni tekst i dinamikih delova - koji su predstavljeni oznakama specifinim za dati

ablon i koji se menjaju u zavisnosti od modela podataka. Za ablon stranice se mogu

koristiti tehnologije kao to su HTML, JSP, ASP, Freemarker, Velocity i mnoge druge.

Generator, koji se jonaziva i procesor ablona, koristi dati model podataka i ablonske

stranice, integrie ih na taj nain to odgovarajue podatke modela postavlja u za to

oznaena mesta na ablon stranicama i proizvodi odgovarajui izlaz. Neki od iroko

primenjenih procesora ablona su Freemarker template i Apache Velocity. Vie o

Freemarker-u bie opsiano u poglavlju 4.

Izlaz iz generatora moe biti HTML stranica, Java izvorni kod, sql skripta, XML definicija ili

datoteka sa dokumentacijom.


13/131


4

Na slici 2 su prikazani najee korieni ulazi i izlazi iz generatora.

MODEL PODATAKA

XML DEFINICIJA MODELA

EMA BAZE PODATAKA

DOMENSKE KLASE

GENERATOR

ABLON STRANICE

DDL

DOMENSKE KLASE

XML DEFINICIJEMODELA

POSLOVNALOGIKA

KORISNIKIINTERFEJS

TEST KLASE

DOKUMENTACIJA

Slika 2: Ulazi i izlazi iz generatora aplikacija

2.2. Opravdanost pravljenja generatora

Pre nego to se pristupi razvoju generatora potrebno je razmotriti potrebu i opravdanost

takvog reenja kao i prednosti i nedostatke naspram runog razvoja aplikacije. Takoe u

sluajevima kad su generatori aplikacija vekorieni na prethodnim projektima potrebno je

ispitati i mogunost izmene i prilagoavanja postojeih generatora.

Koristi od korienja generatora naspram runog pravljenja aplikacije se mogu ukratko

opisati na sledei nain [1]:

Upotreba generatora znaajno skra

uje vreme potrebno za razvoj aplikacije i

poveava produktivnost.


14/131


5

Ovo moe biti veoma znaajno kada je vreme kritian faktor realizacije projekta,

kod projekata sa velikim brojem funkcionalnosti i tabela u bazi podataka.

Poveava kvalitet programskog koda.

Dobro napravljen generator generie standardizovani kod i doprinosi

konzistentnosti imenovanja datoteka, metoda i promenljivih. Standardizacijom

koda se stvara dobra praksa i pravila kodiranja koja kasnije mogu postati

standard za razvojni tim. Standardi kodiranja kasnije omoguavaju lake

snalaenje u programskom kodu i breukljuivanje novih lanova tima u tekui

projekat.

Eliminie monotoniju u radu.

Ovo je veoma bitan faktor koji utie direktno na produktivnost zaposlenih. Pisanje

velike koliine slinog i ponavljajueg koda dovodi do monotonije u radu i

nezainteresovanosti. Nasuprot tome projektujui generator, radnici su motivisaniji

jer rade na zanimljivom, kreativnom i jedinstvenom poslu, time proirujui svoja

inenjerska znanja i iskustva.

Mogunost ponovne upotrebe (reusability).

Jednom dobro napravljen generator se sa odreenim izmenama moe koristiti i u

novim projektima sline strukture. Veina poslovnih aplikacija zahteva operacije

itanja, upisivanja i izmene podataka tako da deo generatora koji je zaduen zaove operacije moe ostati neizmenjen. Izmene se najee ogledaju samo u

dizajnu korisnikog interfejsa, tj. delu aplikacije koji korisnik vidi i sa kojim je u

interakciji.

Mogunostviestruke upotrebe.

Jedan generator snabdeven sa odgovarajuim modelom podaka moe se koristiti

za generisanje programskog koda, baze podataka (DDL-a), xml datoteka sa

definicijama modela, dokumentacije i drugih proizvoda.

Omoguava jedinstvenu ulaznu taku za promene.

Masovne promene na brojnim mestima u aplikaciji zahtevaju samo izmenu u

odgovarajuim ablonima i ponovno startovanje generatora.

Smanjuje mogunost greaka.

Manuelnim kodiranjem esto nastaju sintaksne greke koje kompajler ne moe, ili

bar ne dovoljno precizno, da definie (na primer na prezentacionom sloju) i koje

zahtevaju dosta vremena da bi se oktrile. To je posebno sluaj sa pisanjem koda

koji ve negde postoji u slinom obliku kada inenjeri obino pribegavaju


15/131


6

copy/pastemetodi. Eliminisanjem sintaksnih greaka, generator koda omoguava

da se vie vremena posveti funkcionalnom testiranju aplikacije.

Omoguava uporeivanje razliitih pristupa.

Generatori omoguavaju da se na brz i lak nain probaju razliite implementacije

pre samog poetka realizacije projekta i tako testiraju i uporede performanse i to

samo promenom napravljenih ablona.

Razdvaja poslovnu logiku od prezentacione tehnologije.

Konkretna prezentaciona tehnologija predstavljena ablon stranicama je potpuno

nezavisna od tehnologije kojom je predstavljena poslovna logika. ablon stranice

mogu ostati nepromenjene u sluaju da se promeni programski jezik, tehnologija

ili okvir (framework) poslovne logike i tako doprinosi portabilnosti (portability)

sistema.

Meutim generatori mogu predstavljati i ma sa dve otrice. Potrebno je obratiti panju na

sluajeve kada mogu proizvesti vie problema nego koristi. Pre poetka realizacije projekta

potrebno je izdvojiti odreeno vreme i analizirati da li takav pristup odgovara specifinostima

samog projekta. Ovde emo se osvrnuti na sluajeve kada generatori ne predstavljaju

optimalno reenje:

Kada obim posla nije dovoljno veliki da bi pravljenje generatora bilo isplativo u smislu

vremena i resursa

Kada deo aplikacije koji treba generisati nije jedan od slojeva sa dobro poznatom i

razraenom strukturom. Na primer, generisanje domenskih klasaje olakano poto je

njihova struktura poznata, tj. zna se da one sadre atribute i metode za pristupanje

tim atributima. To omoguava konstrukciju generikog domenskog objekta, tj. ablon

stranice za domenski objekat.

Kada skup osobina ili dizajn aplikacije nisu dovoljno precizno definisani unapred ili se

esto menjaju

Za delove aplikacije koji nisu ablonski, tj. koji su jedinstveni. Tipian primer je

stranica za logovanje korisnika u web aplikaciju. Logika koja je zaduena za ovu

stranicu obuhvata validaciju korisnike ifre i lozinke, proveru privilegija korisnika i

kreiranje web sesije (web session). Ove funkcionalnosti su jedinstvene za login

stranicu pa bi pravljenje ablona za nju bilo neefikasno.

Iz svega navedenog moe se zakljuiti da generatori mogu predstavljati veliku vrednost za

jedan razvojni tim ali da je ipak temeljnom analizom pre svakog projekta potebno ispitati

razloge za i potiv ovakvog reenja.


16/131


7

3. Spring web MVC

Spring okvir predstavlja Java platformu koja obezbeuje sveobuhvatnu infrastrukturnu

podrku razvoju kako standardnih tako i web aplikacija [2].

Spring okvir je lagani (lightweight) kontejner, aspektno orijentisan i zasnovan na IoC

(Inversion of Control) principu [3]. Znaenje pojedinih karakteristika Spring okvira je sledee:

Spring je kontejnerto znai da upravlja konfiguracijom i ivotnim ciklusom objekata

aplikacije.

Spring je lagani kontejner u smislu da sa poslovnim objektima radi na nenametljiv

(non-invasive) nain. To znai da poslovni objekti ne zavise od samog kontejnera tj.

ne moraju da nasleuju klase ili implementiraju interfejse specifine za kontejner.

IoC principomoguava slabu povezanost izmeu objekata na nivou implementacije.

To u sluaju Spring okvira znai da poslovni objekti aplikacije kojima upravlja Spring

kontejner nisu zadueni za kreiranje drugih objekata sa kojima sarauju i od kojih

zavise veto umesto njih radi kontejner.

Spring je aspektno orijentisanto znai da omoguava razdvajanje poslovne logike

aplikacije od sistemskih servisa (npr. upravljanje transakcijama).

Jedna od najbitnijih karakteristika Spring okvira je njegova modularnost, koja omoguava da

se prilikom projektovanja aplikacije ne koristi celokupni okvir, ve samo oni moduli koji su

potrebni u specifinoj situaciji. Spring okvir se sastoji od 20-ak modula smetenih u odreene

grupe. Na slici 3 je dat gafiki prikaz Spring modula.


17/131


8

Slika 3: Spring moduli [2]

Corekontejnerje najvaniji isadri osnovne module za rad sa Spring okvirom. Core i Beans

moduli omoguavaju korienje IoC principa. Context modul nasleuje osobine Beans

modula i omoguava pristupanje objektima kroz kontekst aplikac ije, internacionalizaciju

aplikacije i podrku za JavaEE komponente. Expression Language modul obezbeuje izrazni

jezik (expression language) za manipulaciju objektima u vreme izvravanja aplikacije.

Data Acess/Integration moduli omoguavaju upotrebu JDBC- kroz apstraktne interfejse,integraciju sa ORM alatima, korienje poruka (messages) i upravljanje transakcijama.

Web moduli obuhvataju Spring implementaciju MVC uzora za web aplikacije, web orijentisan

aplikacioni kontekst i podrku za integraciju Struts okvira u Spring aplikaciju.

Test modul omoguava testiranje Spring aplikacije korienjem JUnit i TestNG alata.


18/131


9

3.1. Konfigurisanje i pokretanje kontejnera

U Spring terminologiji, svi objekti aplikacije kojima upravlja Spring IoC kontejner nazivaju se

bean-ovi (beans).

Interfejs org.springframework.beans.factory.BeanFactory i njegov podinterfejs

org.springframework.context.ApplicationContext predstavljaju sr IoC

mehanizama i zadueni su za kreiranje, konfigurisanje i povezivanje bean-ova na osnovu

konfiguracionih metapodataka. Metapodaci se mogu predstaviti u obliku xml datoteka,

anotacija ili Java koda.

U sledeem delu koda prikazana je osnovna struktura xml datoteka za konfigurisanje bean-

ova.

Pokretanje Spring kontejnera vri se na osnovu definisane konfiguracione datoteke i

konkretne implementacije BeanFactoryili ApplicationContextinterfejsa.

U delu koda koji je nie naveden prikazan je jedan od naina pokretanja kontejnera

korienjem klase ClassPathXmlApplicationContext koja implementira

ApplicationContextinterfejs.

ApplicationContext spring = new

ClassPathXmlApplicationContext("appContext.xml");


19/131


10

U appContext.xml datoteci se nalaze konfiguracije bean-ova i pri pokretanju kontejnera ona

mora da se nalazi u classpath1putanji aplikacije.

Prilikom pokretanja kontejnera, Spring vri validaciju konfiguracije bean-ova i kreira po jedno

pojavljivanje za bean-ove iji je opseg oznaen kao singleton2,dok ostale bean-ove kreira na

zahtev korisnika.

U web aplikacijama konfigurisanje i pokretanje kontejnera se vri pomou datoteke web.xml.

Primer ove datoteke je prikazan u sledeem delu koda:

contextConfigLocation

/WEB-INF/appContext.xml

org.springframework.web.context.ContextLoaderListener

ApplicationContext objekat koji je na ovaj nain kreiran od strane

ContextLoaderListener klase smeta se u ServletContext objekat web aplikacije.

Objekat klase ContextLoaderListener prilikom pokretanja web aplikacionog konteksta

trai datoteku appContext.xml unutar WEB-INF direktorijuma.

3.2. MVC uzor

MVC predstavlja softverski uzor i sastoji se od tri osnovne komponente [4]:

Model (Model) je komponenta koja sadri strukturu poslovnog sistema i njene

operacije, odnosno, sadri podatke i operacije za obradu podataka.

Pogled (View) komponenta obezbeuje korisniki interfejs preko koga korisnik

komunicira sa sistemom. Takoe, on alje korisniku izvetaje koji se dobijaju iz

modela.

Kontroler (Controller) je komponenta koja je zaduena da upravlja izvravanjem

sistemskih operacija. Ona prihvata zahtev od klijenta, nakon toga poziva operaciju

1classpathputanja na osnovu koje Java virtuelna maina (JVM) pronalazi klase (class datoteke) Java

aplikacija. Putanja moe da se postavi korienjem classpath opcije prilikom poziva nekog Java alata ilipostavljanjem sistemske CLASSPATH promenljive.2Ukoliko je opseg bean-a definisan kao singleton, kontejner e kreirati samo jedno pojavljivanje bean -a za ivotni

vek aplikacije, tako da e pri svakom zahtevu za takvim bean-om biti vraeno isto pojavljivanje bean-a. Singletonpredstavlja podrazumevani opseg bean-a


20/131


11

koja je definisana u modelu i kontrolie njeno izvravanje. Rezultat izvrene operacije

on dalje preko view-a nazad alje do klijenta.

U kontekstu web aplikacija MVC uzor se grafiki moe predstaviti na sledei nain[5]:

Web pretraiva

Pogled

(JSP)

Kontroler(Servlet)

Model(JavaBeans)

Bazapodataka

zahtev

odgovor

bira iprosleuje

kreira

Aplikacioni server Server baze podataka

Slika 4: JSP Model 2

Na slici 4 se uoava postojanje kontroler servleta koji presree klijentske zahteve, poziva

poslovne operacije iz modela i odluuje na koju JSP stranu treba preusmeriti prikaz.

Spring web MVC funkcionie na slian nain s tim to zahteva postojanje jednog centralnog

kontroler servleta koji e predstavljati jedinstvenu ulaznu taku u web aplikaciju (slika 5). Ova

komponenta je realizovana preko klase DispatcherServlet. Centralni kontroler potom

delegira odgovornosti za obradu klijentskog zahteva (request) ostalim kontrolerima,

realizovanim preko klase Controller, koji pribavljaju model, izvravaju poslovne operacije

nad njim i rezultujui model vraaju centralnom kontroleru. Pored modela kontroleri vraaju i

logiko ime pogleda koji treba prikazati kao rezultat korisniku. Na osnovu logikog imena

pogleda vri se preslikavanje ka konkretnoj realizaciji pogleda i na taj nain se omoguava

potpuna razdvojenost poslovne logike i konkretne prezentacione tehnologije. Na kraju se

korisniku kao odgovor (response) prikazuje konkretna stranica sa atributima sadranim u

modelu.


21/131


12

Slika 5: Prikaz procesa rada komponenti u Spring web MVC [6]

3.2.1. Klasa DispatcherServlet

Klasa org.springframework.web.servlet.DispatcherServlet je u stvari servlet(izvedena je iz klase javax.servlet.http.HttpServlet) i to je jedini servlet koji je

potrebno deklarisati u opisivau rasporeda3 (deployment descriptor) web aplikacije. Takoe

je potrebno opisati i preslikavanja zahteva ka ovom servletu. Sledi prikaz deklaracije u

web.xml datoteci:


/WEB-INF/conf/applicationContext.xml

org.springframework.web.context.ContextLoaderListener

dispatcher

3Opisivaraposreda je xml datoteka koja opisuje strukturu aplikacije, njene komponente, parametre za

inicijalizaciju i sigurnosna ogranienja, dakle sve to je potrebno da aplikacioni server zna o aplikaciji


22/131


13

org.springframework.web.servlet.DispatcherServlet


dispatcher

*.htm

Iz prikazanog dela koda se vidi da e svi zahtevi za stranicama sa ekstenzijom htm biti

obraeni od strane centralnog kontrolera koji se u ovom sluaju naziva dispatcher i koji

predstavlja objekat klase org.springframework.web.servlet.DispatcherServlet.

Spring omoguava hijerarhijsko dekomponovanje aplikacionih konteksta (application

context), tako to omoguava da se svaki nivo konteksta fokusira na odreeni deo aplikacije.

Za svaki nivo konteksta potrebna je po jedna xml datoteka za kofiguraciju njegovih bean-ova.

U prethodnom primeru je prikazano da e datoteka applicationContext.xml biti zaduena za

bean-ove u poslovnoj logici aplikacije dok e datoteteka [nazivDispatcherServleta]-

servlet.xml (u naem primeru dispatcher-servlet.xml) biti zaduena za bean-ove u web sloju

aplikacije.

U okviru aplikacionog konteksta koji se kreira za klasu DispatcherServlet, u datoteci

dispatcher-servlet.xml, mogue je definisati jo neke bean-ove koji e se koristiti za

modelovanje toka obrade zahteva:

HandlerMapping - Odgovoran je za odreivanje odgovarajueg kontrolera kome e

zahtev biti prosleen

ViewResolver - Omoguava preslikavanje logikih imena pogleda (View) u stvarne

poglede

LocaleResolver - Komponenta koja omoguava lokalizaciju

MultipartResolver - Omoguava slanje (upload) datoteka na server korienjem HTTP

protokola

ThemeResolver - Omoguava korienje tema

HandlerExceptionResolver - Prua podrku za preslikavanje izuzetaka

Controller - Predstavlja komponentu MVCokvira

HandlerInterceptor - Omoguavapresretanje dolazeeg HTTP zahteva

Validator - Omoguava validaciju polja na formi


23/131


14

3.2.2. Kontroler

Kontroler je komponenta Spring web MVC okvira koja implementira interfejs

org.springframework.web.servlet.mvc.Controller. Ona je zaduena za

izvravanje konkrentne poslovne operacije, odreivanje koji e pogled (View) biti prosleen

korisnkiu i slanje rezultujueg modela tom pogledu. U sledeem delu koda je prikazan

interfejs Controller:

package org.springframework.web.servlet.mvc;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import org.springframework.web.servlet.ModelAndView;

public interface Controller

{

public abstract ModelAndView handleRequest(HttpServletRequest request,

HttpServletResponse response) throws Exception;

}

U najveem broju sluajeva je dovoljno samo implementirati metodu handleRequestkoja

kao parametre prihvata HttpServletRquest i HttpServletResponse objekte. Odatle

se primeuju zajednike osobine obinih servleta i konrolera. Kao i obian servlet i kontroler

moe da vrati direktno odgovor korisniku, postavljanjem nullkao povratne vrednosti umesto

pojavljivanja klase ModelAndView.

Svaki od kontrolera u aplikaciji je zaduen za rukovanje jednom ili vie web stranica.

Preslikavanje zahteva za stranicama ka odgovarajuim kontrolerima vri se u odgovarajuoj

xml datoteci za definiciju bean-ova, korienjem neke od implementacija interfejsa

HandlerMapping.

loginController

viewMatchesController

editMatchController

viewTeamsController


24/131


15

editTeamController

viewRefereesController

editRefereeController

U prethodnom delu koda je koriena klasa SimpleUrlHandlerMappingkoja je najea

implementacija interfejsa HandlerMapping. Ona omoguava preslikavanje zahteva za

stranicama ka kontrolerima eksplicitnim mapiranjem naziva stranica u identifikator bean-a

koji definie kontroler.

Tako na primer, zahtev za stranicom login.htme biti obraen od strane kontrolera koji je

definisan bean-om sa identifikatorom loginController.

3.2.3. Model i View

Model i View u Spring MVC-u su predstavljeni klasom

org.springframework.web.servlet.ModelAndView koju kontroleri definiu kao

povratnu vrednost nakon obrade korisnikog zahteva. Ova klasa sadri informacije o pogledu

koji e biti vraen korisniku i podacima koji e mu se prikazati.

Model je predstavljen mapom (klasa java.util.Map) koja sadri nazive poslovnih objekata

i njihove vrednosti. Zavisno od konkretne tehnologije prikaza model je kao atribut dostupan

na korisnikoj strani u odreenom formatu.

Pogled (View) moe predstavljati objekat kao konkretnu implementaciju interfejsa

org.springframework.web.servlet.Viewili logiki naziv pogleda koji se preslikava u

konkretan pogled na osnovu bean-ova za preslikavanje logikih naziva pogleda

(ViewResolver).

U prethodnom delu koda je dat prikaz preslikavanja logikih naziva pogleda u konkretan

pogled, iz dispatcher-servlet.xml datoteke, korienjem klase


25/131


16

InternalResiurceViewResolver. Logikim nazivima pogleda se dodaju vrednosti prefix

i suffix elemenata tako da e na primer logiko ime login biti preslikano u stranicu /WEB-

INF/login.jsp

3.2.4. Spring web MVC forme

U web aplikacijama prikaz i unoenje podataka se ostvaruje korienjem HTML formi. Spring

web MVC nudi mnotvo razliitih, hijerarhijski povezanih kontrolera koji omoguavaju

automatizaciju procesa rada sa formama: preuzimanje podataka sa forme, direktno

povezivanje polja na formi sa atributima Java objekata, validaciju i transformaciju podataka

itd. U standardnim web aplikacijama najee korien kontroler je SimpleFormController.

Jedan kontroler koji nasleuje klasu SimpleFormController zaduen je za rukovanje

jednom HTML formom. Jedna HTML forma je zaduena za operacije nad jednim Java

objektom koji se u kontekstu Spring web MVC-a naziva komandni bean. Nakon potvrivanja

forme (submit) vrednosti polja sa forme postaju parametri HTTP zahteva (HTTP request).

Jedna od najbitnih karakteristika koje SimpleFormController omoguava je direktno

povezivanje atributa (data binding) komandnog bean-a sa HTML poljima na formi. Ovakvo

povezivanje podataka u Springu se realizuje pomou klaseorg.springframework.validation.DataBinder. Proces povezivanja polja sa forme

sa atributima komandnog bean-a podrazumeva transformaciju parametara iz zahteva, koji

mogu da budu jedino tipa String, u odgovarajui tip atributa komandnog bean-a. Ova

transformacija se uglavnom deava automatski osim kod korisniki definisanih klasa i

datumskih klasa kada je potrebno koristiti neki od Springovih ili korisniki definisanih editora

osobina (property editors).

Za korienje formi Spring nudi podrku u vidu dodatnih oznaka (tag) u formatu

. Njihov opis je dat u tabeli 1:

bind Omoguava povezivanje jednog polja na HTML formi sa jednim

atributom komandnog bean-a. Atribut se specificira parametrom path,

kaopath = nazivKomandnogBeana.nazivAtributa.

Tom prilikom kreira se objekat klase BindStatus, koji je na stranici

dostupan pod imenom status. Objekat status sadri parametre

expression, value i errorMessages koji pruaju informacije o imenu,

vrednosti i eventualnim grekama vezanim za atribut koji se povezuje


26/131


17

nestedPath Definie komandni bean-a za koji e biti vezani svi bind elementi, tako

to se vrednost path atributa nestedPath elementa koristi kao prefiks

path atributa bind elementa

hasBindErrors Proverava da li komandni objekat ili njegov atribut sadre validacionu

grekutransform Daje mogunost ne-komandnim objektima da budu transformisani

pomou editora osobina na isti nain kao i komandni objekti

messages Omoguava korienje poruka definisanih u eksternim datotekama na

odgovarajuem jeziku zavisno od lokala

theme Koristi se za pronalaenje teme (theme) na osnovu kljua definisanog

kao parametar elementa

Tabela 1: Opis Sping oznaka za rad sa formama

Korienje ovih oznaka zahteva dodavanje sledee direktive koja ukljuuje potrebne

biblioteke oznaka na vrh jsp strane:

Na sledeem primeru je dat prikaz dela jsp strane koja sadri formu za unos novog Team

domenskog objekta i koja koristi opisane Spring oznake.

..............

-name : String

Team


27/131


18

Kontroler koji proiruje SimpleFormController i koji je zaduen za manipulaciju Team

komandnim bean-om prikazan je u sledeem delu koda:

public class EditTeamController extends SimpleFormController {

private TeamManager teamManager;@Override

protected ModelAndView onSubmit(HttpServletRequest request,

HttpServletResponse response, Object command, BindException errors) {

ModelAndView mav = new ModelAndView(getSuccessView());

Team t;

String param = request.getParameter("teamId");

if (param != null && !param.equals("")) {

t = teamManager.update((Team) command);

} else {

t = teamManager.create((Team) command);

}

mav.addObject(t);

return mav;

}

protected Object formBackingObject(HttpServletRequest request)

throws Exception {

Team team;

String param = request.getParameter("teamId");

if (param != null && !param.equals("")) {

Long teamId = Long.parseLong(param);

team = teamManager.findTeamById(teamId);

} else {

team = new Team();

}

return team;

}

..............

Dve najvanije metode ovog kontrolera su onSubmiti formBackingObjectmetode.

Metoda formBackingObject se automatski poziva neposredno pre nego to se stranica

uita i koristi se za inicijalizaciju komandnog bean-a i povezivanje njegovih vrednosti sa

poljima na formi. Atributi ovog bean-a mogu biti postavljeni na podrazumevane (default)

vredosti (u sluaju kad je forma za kreiranje novog objekta) ili na ve postojee vrednosti

uitane iz tabele baze podataka (u sluaju da je forma za izmenu postojeeg objekta).Metoda onSubmit se automatski poziva nakon potvrivanja forme. Ona kao parametar prima

komandni objekat sa ve postavljenim vrednostima atributa preuzetih iz paremetara HTTP


28/131


19

zahteva. Obino se koristi za snimanje komandnog bean-a u bazu podataka a kao povratnu

vrednost vraa pogled koji e korisniku biti prikazan nakon potvrivanja forme.

Definicija prikazanog kontrolera u dispatcher-servlet.xml datoteci je data u sledeem delu

koda:

U tabeli 2 su objanjene nejee korienih atributa za definiciju kontrolera kao bean-a:

id Jedinstveni identifikator kontroler bean-a

class Java klasa kojom je implementiran kontroler

sessionForm Mogue vrednosti su true i false. Pokazuje da li komandni

bean treba da bude sauvan u sesiji izmeu prikaza forme i

potvrivanja forme

commandName Naziv komadnog bean-a za iju manipulaciju je kontroler

zaduen

commandClass Java klasa kojom je implementiran komandni bean

formView Logiko ime stranice sa formom koja je inicjialno prikazana

korisniku

successView Logiko ime stranice koja e biti prikazana korisniku nakon

uspenog potvrivanja forme

[nazivAtributaKontrolera]-ref Identifikator bean-a komponente na koju kontroler referencira.

Moe ih biti vie

Tabela 2: Atributi za definisanje kontroler bean-a


29/131


20

4. Freemarker ablon

Freemarker je procesor ablona (template engine) zasnovan na Java programskom jeziku

koji podrava upotrebu MVC softverskog uzora. Procesor ablona predstavlja softversku

komponentu koja generie tekst (HTML, sql skripte, Java izvorni kod, itd) zasnovan na

ablonu.

Iako moe da generie razliite teskstualne izlaze, Freemarker se najee koristi za

generisanje HTML stranica kod web aplikacija zasnovanih na MVC uzoru. Time je

omogueno dizajnerima da menjanju izgled stranica bez potrebe da softver inenjeri menjaju

kod aplikacije, poto su na taj nain aplikaciona logika (Java kod) i izgled stranica

(Freemarker abloni) razdvojeni i nezavisni.

Na slici 6 je prikazana osnovna ema transformacije Freemarker procesora kod

projektovanja web aplikacija zasnovanih na MVC uzoru. Sa jedne strane se nalaze ve

napravljene Freemarker ablonske stranice a na drugoj Java programski kod. Java kod

predstavlja model podataka koji sadri atribute i njihove vrednosti. Freemarker procesor

koristi pripremljene promenljive prosleene iz Java klasa, umee njihove vrednosti u

ablonske stranice i kao rezultat prikazuje statike HTML stranice [7]. Ova transformacija je

prikazana na slici 6.

.. Zdravo ${ime}!...

.. osoba.ime = Pera;...

.. Zdravo Pera!...

Slika 6: Princip rada Freemarker ablona

ablon stranice se uvaju na web serveru, bakao to bi se uvao i statiki HTML i svaki put

kada se pristupi web stranici Freemarker procesor e ablon stranu transformisati u HTMLstranu, zamenjujui deo oznaen sa ${ . . .} odgovarajuim sadrajem.


30/131


21

Iz navedenog se moe zakljuiti da se osnova rada svakog ablonskog procesora pa i

Freemarker ablona moepredstaviti izrazom:

ablon stranica + Model podataka = Izlaz

4.1. ablon stranica

Osnovni gradivni elementi Freemarker ablona su:

Oznake za umetanje ija je sintaksa predstavljena izrazom ${ . . . } mesta sa

ovakvim oznakama u ablonu e u vreme procesiranja ablona biti zamenjenaizraunatim vrednostima prosleenim iz modela podataka.

FTL4oznake poinju # karakterom. One predstavljaju ili neke od Freemarker-ovih

ugraenih instrukcija ili korisniki definisane instrukcije. Nakon procesiranja ablona,

FTL oznake nee biti prikazane na stranici vesamo rezultat njihovog izvrenja. FTL

oznake se jozovu i direktive.

Komentari u Freemarker ablonu su slini HTML komentarima. Oni se predstavljaju

oznakama . Sve to se nalazi izmeu ove dve oznake kao i same oznake

nee biti obraene od strane procesora niti prikazani na izlaznoj stranici.Statiki tekstkoji e biti prikazan na stranici kao takav predstavlja sve ostalo to nisu

FTL oznake, direktive i komentari i on nee biti interpretiran od strane Freemarker-a.

4.1.1. Oznake za umetanje

Format oznaka za umetanje je ${izraz}, gde izraz mogu predstavljati razliite vrste izraza

(npr. ${100 + x}) ili promenljive prosleene iz modela (npr. ${property.name}).

Oznake za umetanje se koriste za tampanje vrednosti izraza pretvorene tekst (string) na

stranici. Osnovno ogranienje ovih oznaka je da se ne smeju koristiti unutar FTL oznaka. Na

primer, sledei izraz je sintaksno pogrean jer se unutar FTL oznaka koriste oznake za

umetanje:

[#if ${property.name != idField}]

[/#if]

4FTL je skraenica od Freemarker Teamplate Language


31/131


22

Umesto toga treba koristiti:

[#if property.name != idField]

[/#if]

Rezultat izraza, kada eli da se tampa na stranici, mora biti string, broj ili datum zato to se

jedino brojevi i datumski tipovi mogu transformisati u string automatski. Ostali tipovi kao to

su boolean ili kolekcije moraju se na neki nain runo pretvoriti u string. U suprotnom e

Freemarker prijaviti greku i zaustavie procesrianje ablona.

Na primer, sledei izraz e prouzrokovati greku i nee prikazati vrednost tipa trueili false.

${property.name == idField}

Da bi se ovo ispravilo moe se koristiti Freemarkerova ugraena funkcija za pretvaranje

boolean vrednosti u string, na sledei nain:

${(property.name == idField)?string(true, false)}

4.1.2. FTL oznake

FTL oznake ili direktive imaju sledeu strukturu:

U sluaju da direktiva nema ugnjedeni sadraj krajnja oznaka se ne koristi. Primer

korienja direktivi dat je u sledeem delu koda:

5

Pojoprestavlja Hibernate referencu na apstraktni omenski objekat koji de obiti svoju konkretnu vrednostnakon procesiranja ablona oreenim moelom poataka. Metoa getAllPropertiesIterator() vrada sve

atributepojo objekta. Metodepojo objekta se po potrebi mogu ugnjeiti u Freemarker ablon ali nede biti

detaljnije razmatrane u ovom poglavlju jer nisu deo Freemarker instrukcija.


32/131


23

FT

FTL oznake moraju biti pravilno ugnjedene. Tako da na gornjem primeru i poetna i krajnja

oznaka direktive moraju biti unutar oznaka. HTML oznake ne moraju biti

pravilno ugnjedene u FTL oznake jer ih Freemarker procesor ne obrauje.

Neke od najee korienih predefinisanih direktiva u Freemarker ablonu su prikazane u

tabeli 3:

Opis direktive Primer korienja

...

...

...

- koristi se za opciono prikazivanje delova

ablona

- uslov1, uslov2 su izrazi koji imaju boolean

vrednost

x je tipa Double

x je tipa Date

x nije ni Double ni Date tipa

-Omoguava kreiranje nove ili zamenu

postojee promenljive

-naziv: naziv promenljive

-vrednost: vrednost promenljive


33/131


24

...

- omoguava iteraciju kroz elemente kolekcije.

omoguava izlazak iz iteracije

- kolekcija: izraz koji predstavlja kolekciju

elemenata

- var: naziv iteracione promenljive

${team}

- koristi se za umetanje drugog Freemarker

ablona u tekui ablon.

- putanja: putanja datoteke koja se umee u

String formatu

functions.ftl

main.ftl

. . . . . . . . . . .

property je tipa String!

...

- Freemarker nee parsirati FTL oznake i

oznake za umetanje unutar ovih oznaka, ve

e ih prikazati kao takve

ablon

Izlaz

Tabela 3: Predefinisane direktive u Freemarker ablonu


34/131


25

4.1.3. Korisniki definisane direktive

Korisniki definisane direktive se jonazivaju makrodirektive i imaju sledeu strukturu:

...

Gde su:

naziv: naziv makro promenljive.

param1,param2,: nazivi lokalnih promenljivih koji predstavljaju parametre makroa.

Mogu imati podrazumevane vrednosti koje su dodeljene sa

param=podrazumevanaVrednost.

Makro predstavlja deo ablona koji je povezan sa odreenom promenljivom. Toj promenljivoj

se kasnije moe pristupiti iz drugog ablona i njenim pozivom e biti odtampan tekst

definisan unutar makroa. Na taj nain on omoguava redukovanje ponavljajueg koda u

ablonu. Makro promenljivoj se pristupa pomou @oznake.

Na sledeem primeru je prikazana instrukcija za kreiranje makro promenljive nazvaneinputValue:

Pozivom makroa komandom

za svaki od string atributa domenskog objektapojo bie prikazan tekst


35/131


26

Poto deo koda izmeu i oznaka predstavlja takoe deo Freemarker

ablona, on moe sadrati HTML, Freemarker direktive, oznake za umetanje itd.

4.1.4. Funkcije

Pored korisniki definisanih direktiva mogue je definisati i korisnike funkcije.

...

...

Gde su:

naziv: naziv funkcije

param1,param2: nazivi lokalnih promenljivih koje predstavljaju parametre funkcije.

Svakom parametru je opciono mogue dodeliti podrazumevanu vrednost kao

param=podrazumevanaVrednost.

povratnaVrednost: izraz koji izraunava vrednost koja e biti vraena iz funkcije

Ova direktiva je slina makro direktivi sa razlikama to mora sadrati povratnu vrednost

(return direktiva) koja e biti prikazana pozivom funckije i nee tampati unutranjost

direktive.

Korisniki definisane funkcije se u ablonu pozivaju na sledei nain:

${nazivFunkcije(param1, param2,,paramN)}

Na sledeem primeru je prikazana definicija funkcije pod nazivom isStringkoja proverava da

li je prosledjeni atribut tipa String:


36/131


27

property.value.typeName == "java.lang.String"/>

4.1.5. Promenljive u Freemarker ablonu

Postoji tri tipa promenljih koje se mogu definisati u ablonu:

Plain promenljive: One su dostupne sa bilo koje lokacije u ablonu ili iz ablona

umetnutih sa include direktivom. Mogu se kreirati ili zameniti korienjem assign ili

macrodirektive.

Lokalne promenljive: Lokalne promenljive se mogu postaviti samo unutar makro

definicije i definicije funkcija i vidljive su samo unutar njih. Ove promenljive postoje

samo dok traje izvravanje makroa ili funkcije i mogu se kreirati sa localdirektivom

Iteracione promenljive: Ove promenljive se kreiraju automatski deriktivom listi postoje

samo izmeu poetne i krajnje oznake direktive.

4.1.6. Izrazi

Izrazi su na ablon stranicama definisani pravilnim kombinovanjem prethodno opisanih

elemanata.

4.1.6.1. Pristupanje promenljivim

Promenljivim koje su definisane u modelu podataka i prosleene ablonu moe se pristupi

na jednostavan nain preko njihovog naziva:

${nazivPromenljive}

Hepromenljive se u Freemarker ablonu mogu definisati kao niz parova [naziv, vrednost]:

Elementima hea se moe pristupiti po nazivu kao hash.naziv1 ilihash[naziv1].

Sekvence u Freemarkeu u stvari predstavljaju niz vrednosti:


37/131


28

Elementima sekvence se pristupa pomou njihovog indeksa: sekvenca[0], sekvenca[1]

4.1.6.2. Operacije nad promenljivim

Freemarker podrava razliite operacije nad promenljivim:

Nad promenljivim se mogu izvravati 4 osnovne aritmetikeoperacije: sabiranje (+),

oduzimanje (-), mnoenje (*) i deljenje (/) plus izraunavanje ostatka pri deljenju -

modul (%). Pri ovim operacijama oba operanda moraju biti izrazi koji se sraunavaju

u numeriku vrednost.

U Freemarkeru se mogu korisiti sve standardne operacije poreenja: (=) i (!=) se

mogu koristiti za stringove, numerike vrednosti i datume dok se (>),(=) i (


38/131


29

Kapitalizacija var?cap_firstprvo slovo kapitalizovano

var?uncap_first - prvo slovo dekapitalizovano

var?upper_casesva slova kapitalizovana

Pretvaranje stringa u datum sa

zadatim formatom

"10/25/1995"?date("MM/dd/yyyy")

"15:05:30"?time("HH:mm:ss")

"1995-10-25 03:05 PM"?datetime("yyyy-MM-dd hh:mm a")

Operacije nad sekvencama

Opis operacije Primer

Spajanje sekvenci ["vrednost1", " vrednost 2"] + ["vrednost3", " vrednost 4"]

Provera da li sekvenca sadriodreeni element, vraa boolean

vrednost

seq?seq_contains(vrednost)

Pronalaenje indeksa odreenog

elementa

seq?seq_index_of(vrednost)

Veliina sekvence seq?size

Operacije nad brojevima


Pretvaranje broja u string sa

odreenim formatom

x?string(",##0.00")


39/131


30

Zaokruivanje x?roundna najblii ceo broj

x?floorna niu vrednost

x?ceilingna viuvrednost

Operacije nad logikim promenljivim


Pretvaranje logike vrednosti ustring

bool?string("yes", "no")

4.2. Model podataka

Model podataka u Freemarkeru moe sadrati razliite tipove Java objekata, od prostih

tipova do korisniki definisanih klasa (npr. Entity klase). Sam model podataka se priprema u

Java kodu i prosleuje odreenom ablonu koji Freemarker procesor transformie u statiku

stranu. Primer modela je dat u sledeem delu koda:

// Kreira worldcup hash mapu

Map worldcup = new HashMap();

// Dodaje String nazivFunkcionalnosti u mapu

worldcup.put("nazivFunkcionalnosti , "Timovi");

// Kreira objekat klase Team

Team team = new Team();

// Postavlja vrednosti za polja name i rank objekta team

team.setName(Serbia);

team.setRank(12);

// Dodaje objekat teamu mapu

worldcup.put("team", team);

Ovaj model podataka se sa gledita ablon stranice vizuelno moe predstaviti kao struktura uobliku drveta:


40/131


31

(worldcup)

|

+- nazivFunkcionalnosti = "Timovi"

|

+- team

|

+- name = "Serbia"

|

+- rank = 12

Kada je potrebno pristupiti nekoj od podpromenljivih na ablon stranici navodi se putanja od

worldcup elementa i svaki korak se razdvaja takom. Na primer da bi se pristupilo

podelementu name elementa team, potrebno je napisati team.name. Kada se ta putanja

postavi u oznaku ${ . . . }dobija se tekstualna vrednost elementa name.

4.2.1. Tipovi promenljivih u modelu podataka

Freemarker razlikuje tri tipa promenljivih u svom modelu podataka:

Hepromenljive koje uvaju u sebi druge promenljive, svaku pod odreenim nazivom

U Javi su hepromenljive predstavljene pomou klasa Map, HashMapitd.

Skalari su promenljive koje uvaju pojedinane vrednosti. U Javi su ove vrednosti

predstavljene brojnim tipovima i klasama poput String, Date/Time i Boolean

klasa.

Sekvence su sline hepromenljivim osim to ne uvaju naziv svojih podpromenljivih.

Umesto toga ih uvaju sekvencijalno i njima se moe pristupiti po indeksu. U Javi su

one predstavljene listama i nizovima.

Promenljive koje su dostupne na ablon stranicama su Java objekti koji implementiraju

freemarker.template.TemplateModelinterfejs. Softver inenjeri ipak mogu da koriste

standardne Java objekte u svom modelu podataka poto e Freemarker ove objekete

automatski zameniti odgovarajuuim TemplateModel objektima iza scene. Ovo svojstvo se

naziva umotavanje objekata (object wrapping).


41/131


32

4.3. Pokretanje Freemarker procesora

Za pokretanje Freemarker procesora prvo je potrebno napraviti odgovarajue pojavljivanje

konfiguracije. Freemarker konfiguracija se uva u objektu klase

freemarker.template.Configuration. On predstavlja centralno mesto za uvanje

parametara za pokretanje generatora i najee se podeava samo jednom, na poetku

ivotnog ciklusa generatora. Ovaj postupak je prikazan u sleem delu koda:

Configuration cfg = new Configuration();

// Postavljanje putanje do direktorijuma gde se uvaju ablon datoteke

cfg.setDirectoryForTemplateLoading(

new File("/putanja do direktorijuma u kome se nalaze sabloni"));

// Odreuje se kako e ablon videti model podataka:

cfg.setObjectWrapper(new DefaultObjectWrapper());

Nakon postavljanja parametara Configurationobjekta potrebno je uitati odreeni model

podataka na nain kako je to prikazano u sledeemdelu koda:

Map worldcup = new HashMap();

worldcup.put("nazivFunkcionalnosti , "Timovi");

Team team = new Team();

team.setName(Serbia);

team.setRank(12);

worldcup.put("team", team);

ablon je u Freemarker-u predstavljen pojavljivanjem klase

freemarker.template.Template. On se obino kreira pomou pojavljivanja klase

Configuration kreiranog u prethodnom koraku i to pozivanjem metode getTemplate

kako je prikazano u sledeemdelu koda:

Template temp = cfg.getTemplate("teams.ftl");

Ovom komandom Freemarker kreira pojavljivanje klase Template koja je zaduena za

ablon stranicu teams.ftl. Stranicu uitava iz putanje /putanja do direktorijuma u kome se

nalaze abloni/teams.ftl i nakon toga je parsira (kompajlira).


42/131


33

Configuration pojavljivanje keira Template pojavljivanje, tako da kada se ponovo

pozove test.ftl nee se kreirati novo pojavljivanje Templateklase

Kao to je u uvodu napomenuto, integracija modela podataka i ablon stranica proizvodi

izlaz iz generatora (modelpodataka + ablon stranica = izlaz). Do sada je napravljen model

podataka (worldcup) i ablon (temp), tako da je sad potrebno integrisati ih. To se postie

korienjem process metode klase Template. Ona koristi model podataka worldcup i

objekat klase Writerkao parametre. Sledei kod e radi jednostavnosti ispisati proizvedeni

rezultat obrade ablona na standardni izlaz:

Writer out = new OutputStreamWriter(System.out);

temp.process(worldcup, out);

out.flush();


43/131


34

5. Hibernate okvir

5.1. Perzistencija

Perzistencija podataka predstavlja jedan od fundamentalnih koncepata u razvoju softverskih

sistema. Uopteno, podaci su perzistentni ako nastave da postoje i nakon zavretka rada

programa koji ih je kreirao.

Postoji vie definicija perzistentnosti u kontekstu objektno orijentisanog razvoja softvera [4]:

Objekat je perzistentan ukoliko se moe materijalizovati i dematerijalizovati.

Objekat je perzistentan ukoliko nastavi da postoji i nakon prestanka rada programa

koji ga je stvorio (G.Booch).

Materijalizacija predstavlja proces transformacije slogova baze podataka u objekte

programa.

Dematerijalizacija predstavlja proces transformacije objekta iz programa u slogove

baze podataka.

Perzistentni okvir je skup interfejsa i klasa koji omoguava perzistentnost objektima

razliitih klasa.

Pod perzistencijom podataka u Javaaplikacijama najee se podrazumeva uvanje Java

objekata u relacionoj bazi podataka. Transformancije koje se odnose na pretvaranje Java

objekata u relacije baze podataka i obrnuto nazivaju se objektno-relaciono mapiranje (ORM).

5.2. ORM alati

Pod ORM alatima podrazumevaju se softverske komponente koje omoguavaju

automatizaciju procesa transformacije izmeu relacionog i objektnog modela. Ovi alati

obezbeuju automatsko generisanje SQL upita na osnovu pripremljenih meta podataka,

upravljanje transakcijama, upravljanje konekcijama ka bazi podataka, objektno orijentisan

upitni jezik itd. ORM alati nude odgovarajuiAPI koji softver inenjerima omoguava rad sa

objektima i ne zahtevaju direktno korienje JDBC-a6 ve je to prepuetno samom alatu.

Meu najkorienijim ORM alatima su Hibernate, TopLink i iBatis.

6JDBC - Java Database Conectivity je Java API koji omoguava metode za pristup specifinoj bazi podataka.


44/131


45/131


36

Interfejsi i klase koje aplikacija poziva da bi konfigurisala Hibernate okvir. To je pre

svega klasa Configuration.

Interfejsi koji omoguavaju aplikaciji da reaguje na dogaaje unutar okvira (callback

interfaces) kao to su Interceptor, Lifecyclei Validatable

Interfejsi koji omoguavaju nadogradju (extension) Hibernate funkcionalnosti zamapiranje kao sto su UserType, CompositeUserTypei IdentifierGenerator.

Ovi interfejsi se implementiraju po potrebi u samoj aplikaciji.

Veze izmeu ovih komponenti su prikazane na slici 7:

Slika 7: Arhitektura Hibernate okvira [9]


46/131


37

5.3.2. Konfiguracija okvira

Konfiguracija okvira se moe podeliti u dve faze. U prvoj je potrebno obezbediti podatke koji

su potrebni okviru da se povee sa odgovarajuom bazom podataka a u drugoj podatke

kojima se opisuje preslikavanje izmeu perzistentnih objekata itabela baze podataka.

Centralna klasa pomou koje se vri konfigurisanje i pokretanje Hibernate okvira je klasa

org.hibernate.cfg.Configuration. Ovoj klasi se prosleuju konfiguracioni podaci na

osnovu kojih ona kreira pojavljivanje klase SessionFactory. Ovo pojavljivanje je

jedinstveno za konekciju sa jednom bazom podataka i njegovo stanje se ne moe menjati

nakon kreiranja. Na ovaj nain okvir je potpuno konfigurisan. Pojavljivanje klase

SessionFactoryje zadueno i za manipulisanje objekatima klase Session pri svakoj

interakciji sa bazom podataka.

Klasa Session predstavlja osnovnu jedinicu rada sa bazom podataka i manipulacije nad

podacima. Odravanje stanja Java objekata, upravljanje transakcijama i izvravanje upita su

pod kontrolom ove klase.

Jedan od moguih naina konfigurisanja i pokretanja okvira je prikazan sledeim kodom:

Configuration cfg = new Configuration();SessionFactory factory =

cfg.configure(/hibernate.cfg.xml).buildSessionFactory();

Pozivom configuremetode, uitavaju se podaci iz datoteke hibernate.cfg.xml a zatim se

pozivom buildSessionFactorymetode kreira objekat SessionFactoryklase.

Pojavljivanje klase Session pri pristupu bazi podataka se moe napraviti pozivanjem

metode openSession nad kreiranim jedinstvenim pojavljivanjem klase SessionFactory

na sledei nain:

Session session = factory.openSession();

Opisani postupak je prikazana na slici 8.


47/131


38

Session

SessionFactory

Configuration

hibernate.cfg.xml hibernate.hbm.xml hibernate annotationshibernate.properties

configure()

openSession()

Slika 8: Konfigurisanje Hibernate okvira

Konfiguracioni podaci potrebni za povezivanje okvira sa bazom podataka se mogu

obezbediti na dva naina: pomou datoteke za definisanje osobina (properties datoteke) pod

nazivom hibernate.properties ili pomou xml datoteke pod nazivom hibernate.cfg.xml.

U sledeem kodu je dat prikaz hibernate.cfg.xml datoteke:

com.mysql.jdbc.Driver

root

jdbc:mysql://127.0.0.1:3306/world_cup


48/131


39

root

org.hibernate.dialect.MySQLDialect

Obavezni podaci koje ova datoteka mora da sadri su:

connection.driver_class: upravljaki program (driver) za izabrani sistem za upravljanje

bazom podataka (SUBP);

connection.url: JDBC URLdo baze podataka. JDBC URLse sastoji iz simbolikog

imena upravljakog programa (jdbc:mysql), IP adrese maine na kojoj se nalazi

SUBP (localhost=127.0.0.1), porta na kome je podignut SUBP (3306) i imena baze

podataka sa kojom program treba da uspostavi konekciju (worldcup). Na taj nain

dobija se URL prikazan u prethodnom sprimeru;

connection.username : Korisniko ime za pristup bazi podataka;

connection.password : Lozinka za pristup bazi podataka;

dialect : Naziv SQL dijalekta za specifinu bazu podataka

Podaci kojima se opisuje preslikavanje izmeu perzistentnih objekata i relacija u bazi

podataka se mogu obezbediti ili xml datotekama za preslikavanje (hbm.xml) ili pomou

anotacija koje koriste Hibernate Annotations modul i koje su postale dostupne poev od JDK

1.5. Sledeim kodom jeprikazan deo Entity klase sa odgovarajuim anotacijama:

@Entity

@Table(name = "match", catalog = "world_cup")

public class Match implements java.io.Serializable {

private Long id;

private Team teamGuest;

@Id

@GeneratedValue(strategy = IDENTITY)

@Column(name = "id", unique = true,

nullable = false)

public Long getId() {

return this.id;

}

public void setId(Long id) {

Mapira naziv Entity klase u

naziv tabele bazepodataka

Mapira naziv atr ibuta klase

u naziv kolon e u tabeli

baze podataka


49/131


40

this.id = id;

}

@ManyToOne(fetch = FetchType.EAGER)

@JoinColumn(name = "team_guest_id",nullable = false)

public Team getTeamGuest() {

return this.teamGuest;

}

public void setTeamGuest(Team teamGuest) {

this.teamGuest = teamGuest;

}

5.4. Hibernate arhitektura generisanja proizvoda

5.4.1. Hibernate meta model

Hibernate meta model je koncept koji Hibernate Core modul koristi da bi izvrio objektno

relaciono mapiranje. Model sadri informacije o tabelama i kolonama baze podataka,

domenskim klasama i atributima i ostalim komponentama relevantnim za ovo mapiranje.

Ulazna taka za model predstavlja klasa Configuration. Na slici 9 je prikazan Hibernate

meta model, naini na koje moe da se izgradi kao i izlazi koje moe da proizvede.

Slika 9: Hibernate meta model [8]

Mapira vezu izmeu

objekata u vezu izmeu

tabela baze podataka


50/131


41

Sa slike se mogu izdvojiti tri grupe elemenata. Prvu ine ulazi i izlazi iz meta modela:

Java perzistente klase (izvorni kod)

Java Dao klase (izvorni kod)

Metapodaci za mapiranje u obliku anotacija

Metapodaci za mapiranje u obliku xml datotetaka

DDL ema baze podataka

XML datoteke za konfiguraciju okvira

HTML datoteke za dokumentaciju

Freemarker abloni

Drugu grupu ine konfiguracije. Konfiguracije slue za izgradnju meta modela na osnovu

odreenog ulaza. Pored standardne Hibernate konfiguracije (klasa Configuration) mogu

se koristiti i izvedene konfiguracije:

JDBC konfiguracija,

Konfiguracija pomouanotacija (klasa AnnotationConfiguration)

JPA konfiguracija

Treu grupu ine generatori (exporter). Oni slue za generisanje izlaza u odgovarajuem

obliku na osnovu informacija sadranih u meta modelu. To su:

hbm2java - generie Java perzistente klase

hbm2ddl - generie emu baze podataka

hbm2hbmxml - generie xml datoteke za preslikavanje

hbm2cfgxml - generie xml datoteke sa konfiguracionim podacima

hbm2doc - generie HTML dokumentaciju

hbmtemplate - generie korisniki definisane stranice pomou Freemarker ablona

Proces generisanja koda primenom Hibernate meta modela se moe opisati na sledei

nain. Hibernate konfiguracija predstavljena klasom Configuration (ili nekom od

pomenutih podklasa) uitava konfiguracionu datoteku i datoteke za mapiranje i na osnovu

njih proizvodi interni meta model. Izabrani generator nakon toga procesira ovaj meta model i

proizvodi odgovarajui izlaz iz modela.

Hibernate meta model moe da se izgradi na osnovu nekog od opisanih ulaza. Njegova

glavna vrednost kod generisanja koda je to nakon toga moe da proizvodi razliite izlaze

koristei neki od gore navedenih generatora. Proces generisanja koda je na taj nain

nezavistan od izvora meta modela.


51/131


42

5.4.1.1. Konfiguracije

Osnovna klasa pomou koje se kreira konfiguracija u Hibernate okviru je klasa

org.hibernate.cfg.Configuration. Ona se nalazi u Hibernate Core modulu. Za

izgradnju meta modela kao ulaz koristi xml mapirajue datoteke (hbm.xml) ixml datoteku sa

konfiguracionim podacima (hibernate.cfg.xml).

AnnotationConfigurationje klasa koja nasleuje klasu Configuration. Zasniva se

na Hibernate Annotations modulu. Ona omoguava itanje mapirajuih metapodataka iz

EJB3/Hibernate anotacija koje se nalaze u Java klasama. Takoe podrava i xmlmapirajue

datoteke. Da bi proizvela meta model pored mapirajuih metapodataka koristi i

konfiguracionu datoteku.

JPA konfiguracija se zasniva na Hibernate EntityManager modulu i zahteva da projekat ima uclasspath-u definisanu perzistentnu jedinicu u obliku META-INF/persistence.xml datoteku i

nju koristi kao konfiguracionu datoteku. JPA konfiguracija za mapiranje koristi hbm.xml

datoteke ili Java klase sa anotacijama.

JDBC konfiguracija se koristi za generisanje meta modela iz eme baze podataka (reverse

engeneering) koristei JDBC konekciju. Ona koristi JDBC konfiguracione podatke definisane

u datotekama hibernate.cfg.xml ili hibernate.properties i opcione xml datoteke za dodatno

podeavanje preslikavanja (hibernate.reveng.xml).

5.4.2. Pokretanje Hibernate generatorabiblioteka hibernate-tool

Korienje Hibernate generatora koji su opisani u prethodnom poglavlju omogueno je

bibliotekom koja se zove hibernate-tool. Ova biblioteka omoguava to na dva naina:

Pomou dodatka (extension) za Eclipse razvojno okruenje koji omoguava

vizualizaciju procesa generisanja koda. On sadri razliite grafike editore za

mapiranje i kreiranje konfiguracija i razliite tipove arobnjaka (wizards) za kreiranje

standardnih Hibernate datoteka (hbm.xml, cfg.xml, revenge.xml). Takoe omoguava

lako i intuitivno pokretanje napravljenih generatora.

Definisanjem Ant zadatka za generisanje koda, eme baze podataka i ostalih izlaza

koji se kao i standardni Ant zadaci zatim moe ukljuiti u proces izgradnje (build)

aplikacije.

U ovom radu generator koda e biti pokretan kao Ant zadatak.


52/131


53/131


44

password="${ftp.lozinka}">

Kao to se vidi iz prikazanog primera koreni element ove datoteke je project element koji

opisuje konkretni projekat, sadri ime projekta - atribut name i podrazumevani cilj atribut

default. Projekat se sastoji iz skupa ciljeva (target). Unutar svakog cilja se nalaze zadaci koje

Ant treba da izvri da bi ispunio odgovarajui cilj. Ovo predstavlja osnovnu strukturu svake

build.xml datoteke.

Primer standardnog Ant zadatka je zadatak oznaen komandom javac u okviru cilja

kompajliranje. On izvrava kompajliranje java izvornih datoteka koje se nalaze u

direktorijumu pod atributom src i nakon toga class datoteke smeta u direktorijum pod

atributom destdir. Komandajavaci atributi srci destdirsu Ant rezervisane rei.

U svakom ciljnom elementu se nalazi i atribut depends(zavisi) koji referencira na drugi ciljni

element i tako oznaava da se ne moe izvriti pre cilja od kojeg zavisi. Na primer cilj

kompajliranjese ne moe izvriti dok se za to ne steknu odgovaraju i uslovi, tj. dok se ne

izvri cilj inicijalizacija u okviru kojeg se kreiraju odgovarjui direktorijumi u koje e biti

smeteni rezultati cilja kompajliranje (class datoteke). Ove zavisnosti su u obliku dijagrama

prikazane na slici 10.


54/131


45

inicijalizacija : target

: task : task

testProjekat : project

kompajliranje : target

: task

dokumentacija : target

: task

postavkaNaServer : target

: task : task

Slika 10: Dijagram zavisnosti u build.xml datoteci

Kada se pokrene Ant prvo skenira ceo dokument build.xml i utvruje njegovu strukturu i

zavisnosti. Nakon toga izgrauje interno drvo zavisnosit izmeu ciljeva (neto nalik

prethodnoj slici) i tako utvruje koji cilj treba prvo da izvri. Redosled kojim su ciljevi navedeni

u xml datotetci nema nikakav uticaj na to. Ant prvo pokree cilj koji je na vrhu drvetazavisnosti (ne zavisi ni od jednog drugog cilja), izvrava njegove zadatke izatim prelazi na

s

Documents

Strahinja Lazetic Razvoj Generatora Spring Aplikacija Primenom Freemarker Sablona i Hibernate Okvira