1.

Templejt patern
Spring koristi ovaj patern za pristup podacima. Ideja ovog paterna je da
su određene aktivnosti za rad sa bazom podataka uvek iste i da se
menjaju samo neke specifične aktivnosti koje zavise od izabrane
tehnologije: uvek se mora otvoriti konekcija bez obzira koja tehnologija
se koristi, bazi se postavljaju upiti ali ti upiti su specifični za tehnologiju.
Spring koristi template klase kako bi definisao fiksne aktivnosti, a
callback klase kako bi definisao aktivnosti koje su specifične.
Spring ima različite templejte u zavisnosti od vrste komunikacije sa
bazom podataka, napr: org.springframework.jdbc.core.JdbcTemplate ili
.orm.hibernate5.HibernateTemplate. Da bi smo mogli koristiti Spring
Template i uopšte da pristupamo bazi podataka potrebno nam je da
prvo definišemo datasource (preko JDBC drivera i JNDI imena – podaci
izmešteni iz aplikacije pa se lakše mogu promeniti). Ideja je da se u
aplikacijama koje treba da rade u realnom svetu koriste connection
pool – definiše maksimalan broj konekcije u jednom trenutku i
aplikacija da vraća konekciju koja je trenutno slobodna, a da ne utiče
performanse aplikacije.

2. Controller – Service – Repository patern

Iako bi smo svu poslovnu logiku mogli da smestimo u Spring kontrolere,
to nije dobra praksa. Takav kod je teži za izmene i za testiranje. Ideja je
da koristimo Controller – Service – Repository patern u kom: repository
je zadužen za perzistenciju podataka tj. dobavljanje i čuvanje podataka
u različitim tipovima skladišta (relacione baze, NoSQL, fajl sistem),
obično se definiše interfejs sa odgovarajućim operacijama a onda se
implementiraju konkretni repozitorijumi za konkretne tipove skladišta.
Repozitorijumi imaju anotaciju @Repository, kako bi omogućili
jednostavno instanciranje pomoću DI tehnike. Obično jedan
repozitorijum je odgovoran za jedan entitet i operacije nad njim.
Servis je komponenta nad repozitorijumom i ona koristi njegove usluge
kao i usluge drugih servisa. Servisi enkapsuliraju poslovnu logiku
aplikacije. Servisi su označeni anotacijom @Service i takođe
implementiraju određeni interfejs kako bi se smanjila zavisnost od
konkretne implementacije servisa. Operacije u servisu možemo
posmatrati kao transakcije – mogu pozivati različite repozitorijume i ili
će se sve uspešno izvršiti ili se ništa neće izvršiti.
Kontroler ima anotaciju @Controller i njegova uloga je da prima poruke
od View komponente i da ih prosleđuje ka servisu i obrnuto, da
odgovor Servisa prosleđuje View komponenti. Ovo je definicija
kontrolera u kontekstu ovog paterna CSR. Međutim u kontekstu MVC
paterna i kontroler, i servisi i repozitorijumi čine komponentu kontroler
u tom paternu.

3. Spring kontroler
Kontroleri su ono što su bili Servleti i zaduženi su za obradu HTTP
zahteva. To su klase koje imaju anotaciju @Controller i čiji metodi imaju
anotaciju @RequestMapping. Anotacija @Controller omogućava da
Spring prepozna automatski ovu komponentu i da je inicijalizuje.
Anotacija @RequestMapping ima atribute value: definiše koji url patern
treba da obradi metoda definisana u kontroleru i method: definiše koji
tip HTTP metoda se obrađuje. Anotacija se može staviti i iznad klase i
time se definiše da je ta klasa zadužena za određeni URL – anotacije na
metodama sada samo detaljnije opisuju URL paterne na koje će
odreagovati.
Ukoliko želimo da metod kontrolera vrati neki objekat, definišemo
ulazni parametar objekat tipa Model. Pozivom metode addAttribute
setujemo naš objekat u taj model i možemo ga isčitati iz JSP stranice
pomoću EL jer je postavljen u request objekat. Model ima strukture
ključ – vrednost i možemo pozivati više puta metodu addAttribute kako
bi dodavali više objekata. Objekat možemo vratiti View komponenti i
ako koristimo java.util.Map umesto klase Model. Možemo vratiti i same
objekte, ali onda se naziv view komponente izvodi iz URL paterna koji
stoji uz metod – u jsp stranici kojoj se šalje objekat je na određenoj
putanji i u request je sačuvan objekat pod imenom koji je izveden iz
return tipa.

4. Spring Boot
Da bismo mogli da razvijamo web aplikaciju pomoću Spring MVC –
model view controller, potrebno je da konfigurišemo DispatcherServlet.
Konfigurisanje DispatcherServleta je: moguće pomoću web.xml – ovo je
jedini način ako koristimo specifikaciju servleta manju od 3.0, može se
iskoristiti Java i konfigurisanje izvršiti programski ili jedan od načina je
da se kreira klasa koja nasleđuje klasu
AbstractAnnotationConfigDispatcherServletInitializer. Najlakši način da
se konfiguriše Spring MVC aplikacije je upotreba drugog Spring
projeketa koji se zove Spring Boot.
Programsko konfigurisanje DispatcherServleta: naslediti klasu
AbstractAnnotationConfigDispatcherServletInitializer i na ovaj način se
u springu automatski kreira odgovarajuća instanca klase
ApplicationContext. Zatim redefinisati metode: metod
getServletMappings() definiše URL paterne, odnosno URL adrese koje
će osluškivati DispatcherServlet. U primeru je to root aplikacije označen
sa / što znači da svi zahtevi koji stignu prvo dolaze do
DispatcherServleta. Metod getServletConfigClasses() treba da vrati
klase koje služe za konfigurisanje binova koji će se koristiti u web
aplikaciji kako bi se automatski instancirali. Ova klasa će učitati binove
kao što su kontroleri, view resolveri i handler mappere. Metod
getRootConfigClasses() vraća konfiguracionu klasu za sve binove koji
nisu deo web aplikacije. Obično učitava binove koji su zaduženi za
poslovnu logiku i podatke.
Zatim implementiramo konfiguracionu klasu koja vraća metod
getServletConfigClasses(). Ona sadrži sledeće anotacije: @Configuration
– daje Spring kontejneru instrukcije kako da inicijalizuje komponente,
@ComponentScan – daje informaciju u kom folderu da traži
komponente, inače DispatcherServlet ne bi mogao da nađe kontrolere i
@EnableWebMVC. U ovoj klasi je definisan i bin ViewResolver koji u
konkretnom primeru sve što kontroler vrati zapravo tumači da je JSP
stanica koja se nalazi u views folderu web aplikacije. Overrrideujemo
metod configureDefaultServletHandling() čime želimo da kažemo da sav
statički sadržaj neće ići preko DispatcherServleta.

5. Sesija i cookies
HTTP je stateless protokol – svaki zahtev je samostalna jedinica. Sesije
se koriste za upravljanjem stanjem između različitih zahteva. Sesija je u
fizičkom smislu fajl, objekat u memoriji kojim rukovodi web server i u
nju skladišti različite podatke – klijentov browser ne sadrži ništa od ovih
podataka, jer je to odgovornost web servera. Sesiji se dodeljuje random
ID i prvi put kada klijent pošalje zahtev, taj ID se vraća u okviru HTTP
odgovora. Svaki sledeći HTTP zahtev će sadrži taj ID. ID sesije se
razmenjuje pomoću session cookies ili URL mehanizma.
HTTP dozvoljava da se određeni podaci razmenjuju između servera i
browsera tako što se upišu u HTTP header (set cookie response
header). Ovi podaci se smeštaju na klijentski računar i pri ponovnom
pozivu istog servera se pakuju HTTP zahtev (cookie request header).
Cookies mogu imati različite atribute: domen – daje informaciju
browseru o imenu domena na koji taj cookie treba poslati, path –
definiše tačnu URL adresu u okviru domena, expires – definiše datum
do kada cookie važi i ukoliko je datum prošao onda browser automatski
briše taj cookie, max – age: definiše broj sekundi pre nego što cookie
prestane da bude važeći. Ukoliko nisu definisani atributi expires i max –
age, cookies se brišu kad se browser zatvori. ID sesije se može postaviti
i u okviru URL adrese kao odgovarajući parametar pre query stringa, a
posle ; kao JSESSIONID=neki brojevi. Da bi server poslao ID sesije, on
mora da taj ID ugradi u svaki link koji prosleđuje klijentu bez obzira da li
je to location atribut ili form action atribut.
Konfigurisanje sesije u deployment descriptoru: sa tagom session –
config imamo unutar tagove session – timeout i cookie – config za koje
postavljamo tagove onih atributa. Za upravljanje sesijama iz servleta:
potrebna nam je klasa HttpSession i metode setAttribute() i
getAttribute(). Objekti koje stavimo u sesiju su dostupni dokle god je
sesija aktivna – inicijalizujemo sesiju Http session da je jednako od
request.getSession. Brisanje podataka iz sesije je metod
removeAttribute. Upravljanje sesijama iz JSP stanice pomoću implicitnih
objekata u okviru skriptlet tagova kao malo pre setujemo neki string u
sesiju pa možemo da ga pridobijemo i sa out.print ispišemo. Takođe
može i pomoću implicitnih objekata u EL tagovima. Tako što sa
prefiksom c setujemo var pa stavimo value i neki scope pa u drugom
tagu sa c kaže out value od var.
Web server može obavestiti web aplikaciju kad dođe do izmena u sesiji
– da li je dodato nešto ili izbrisano iz nje. Postoje definisani interfejsi u
Servlet APIju: ServletRequestListener, ServletRequestAttributeListener,
HttpSessionListener, HttpSessionAttributeListener. Da bi smo kreirali
sopstveni listener, treba da implementiramo neki od ovih interfejsa i da
stavimo anotaciju @WebListener.
 6. JSTL biblioteka
JSTL (Java standard tag library) to je standardna biblioteka tagova koja
se koristi za implementaciju dinamičkih elemenata u JSP stranici
umesto skriptleta. Potrebne bibliteke su jstl.jar i standard.jar na class
pathu. Grupe tagova su: osnovni tagovi – Core, tagovi za formatiranje,
SQL tagovi, XML tagovi i JSTL funkcije.
JSTL Core tagovi su za implementaciju petlji, grananja, postavljanja
promenljivih u neki opseg. Prvo moramo postaviti direktivu sa <%@
taglib uri=http://java.sun.com/jsp/jstl/core prefix=”c” %> pa imamo
primere: <c:out> kao JSP izraz za štampanje napr: <c:out
value=’’knjiga.naslov’’/>, <c:set> koji služi da postavlja vrednost neke
promenljive u određenom ospegu kao malo pre setujemo var, scope i
value i imamo <c:if> pa dodamo test=’’promenljivu od gore var što smo
setovali’’ i imamo <c:forEach> pa stavimo var kroz koju prolazi sa items
gde je neka postavljena lista pa sa out ispisujemo var. Var je naziv
promenljive iz liste koja se koristi u telu i items je kolekcija preuzeta iz
nekog opsega koja je najčešće postavljena u servletu. Tagovi za
manipulaciju URLovima imamo <c:url> za formiranje URL adrese,
<c:param> dodela parametara URL pa <c:import> čita sadržaj sa
proizvoljnog URLa i ubacuje u stranicu, imamo <jsp:include> učitava
samo stranice koje pripadaju istoj Web aplikaciji i <c:rediret>
redirektuje odgovor na navedeni URL.
Tagovi za formatiranje isto je za direktivu samo umesto core stavimo
fmt i prefix je fmt. Pa imamo <fmt:formatNumber> formatiranje
brojeva, valuta i procenata, <fmt:parseNumber> je za parsiranje stringa
i pretvaranja u broj od tipova NUMBER, CURRENCY i PERCENT, zatim
<fmt:formatDate> je da datum pretvori u String reprezentaciju i
<fmt:parseDate> parsira String i pretvara u datum od tipova DATE,
TIME, BOTH sa dateStyleovima od FULL, LONG, MEDIUM, SHORT,
DEFAULT i to je patern.
SQL tagovi sa uri isto samo sad je sql i prefix je sql. Operacije nad bazom
podataka poput <sql:query>, <sql:update>, <sql:param>,
<sql:dateParam>, <sql:transaction>.
XML tagovi isto menjamo xml u uri dok je prefix x. Služi za kreiranje i
obradu XML dokumenata i potrebna su dva jara: xercesimpl.jar i
xalan.jar. Imamo tagove <x:out> za prikazivanje rezultata XPath izraza i
<x:parse> parsira XML sadržaj znači sa c importujemo var i neki url dok
u parse stavimo xml tu var i napravimo novi var tu kako bi ištampali sa
x:out tagom.
JSTL funkcije menjamo u uri functions i prefix je fn. Za standardne
funkcije nad stringovima: fn:contains(), fn:endsWith(), fn:indexOf(),
fn:split() i fn:trim().

7. Expression language
EL kao koncept je dodat u JSP 2.0 specifikaciji. Cilj je bio da se izbace
skriptleti iz JSP stranice. Sa direktivom na page i atribut
isELIgnored=true ili false, označava da li će se obrađivati EL izrazi.
Sintaksa je $izraz gde izraz mora biti validan EL izraz. Može se koristiti
na dva načina: kao vrednost atributa u tagovima da u tagu jsp:include
page stavimo neku =$promenljiva i kao ispis u HTML stanici unutar
tagova h1 da stavimo $promenljiva.
Implicitni objekti u EL: EL može koristiti implicitne objekte za pristup
promenljivama iz opsega sa . kao $knjiga.naziv. Pristup promenljivama
u različitom opsegu vidljivosti: pageScope, requestScope, sessionScope,
applicationScope. Pristup parametrima sa param, paramValues – niz
stringova koji sadrži sve HTTP request parametre i pristup podacima iz
zaglavlja HTTP zahteva sa header.
Primer da imamo jednu jsp stranicu i akcija forme baca na drugu
stranicu i imamo input polje sa name. Pa na toj drugoj stranici kažemo
da isELIgnored je false, pa ispišemo u h1 tagu $param.name koji smo
stavili u prvoj stranici. Ne moraju se koristiti implicitni objekti za pristup
promenljivama u opsegu: $knjiga.naslov radi tako što se prikazuje
knjiga iz najmanjeg opsega – prvo se gleda page, pa request, pa session
i na kraju application.Moguća je navigacija kroz povezane objekte napr.
$knjiga.autor.ime ali moramo paziti na lenjo izračunavanje primer sa
logičkim operatorima da se drugi broj ne uzima u obzir. EL sintaksa za
pristup kolekcijama $niz[0] – vraća prvi element iz niza, dok za uslov ide
$test?opt1, opt2 pa ako je test true onda se prikazuje opt1 ili suprotno
opt2. EL podržava standardne aritmetičke operacije kao i logičke
operatore (==, !=, <, >, &&, negacija - !, ili - ||)

8. Konfigurisanje web aplikacije pomoću init parametra

Postoje različiti načini kako neke parametre možemo proslediti
servletu, a da pri tome koristimo web.xml. Upotrebom taga context –
param ili taga init – param.
Upotrebom taga context – param imamo da su vrednosti definisane u
ovom tagu vidljive svim servletima u okviru web aplikacije. Vrednosti
ostaju iste dok se aplikacija ponovo ne deployuje. U okviru tog taga
koristimo param – name kako da nazovemo bazu, pa tag param value
da postavimo localhost tj. server. A kako pristupamo vrednostima iz
context – param taga, jeste da u servletu napr. u metodi void doGet
koja ima parametre request, response i baca Exception kažemo
ServletContext da je this.getServletContext() pa da dobijemo String neki
pozovemo nad objektom servletContexta getInitParameter i prosledimo
param name koji smo stavili napr. baza.
Ukoliko koristimo tag init – param, onda želimo da parametre vežemo
za tačno jedan servlet. U okviru taga servlet dodajemo taj tag i isto
param – name i param – value. Upotreba anotacije iznad servleta
@WebServlet da napišemo name servleta, urlPatterns i onda unutar
njega anotacija @WebInitParam pa navedemo name i value. Mana je
što izmena init parametara nije moguća bez rekompajliranja što nije
slučaj kad se koristi web.xml.
Pristup servlet init parametrima se koristi isto kao prethodno, samo
kroz objekat klase ServletConfig pa dobijemo njega sa get i neki string
sa getInitParam.

9. Java Servlet
Definicija: Java klasa, izvršava se na web serveru i zasniva se na HTTP
protokolu. Obrađuje HTTP zahtev klijenta i generišu HTTP odgovor.
Servleti su osnova svake web aplikacije. Nastanak 1996. godine u firmi
Sun Microsystems. Apache tomcat – jedan od najpopularnijih web
servera implementiranih u Javi. Java Servlet klasa je klasa dostupna u
Java Servlet APIju koji je implementiran u servlet – api.jar pa ga je
potrebno dodati u Maven dependency file – pom.xml.
Objektom servleta upravlja servlet kontejner koji je deo HTTP web
servera. Servlet kontejner upravlja životnim vekom servlet objekta.
Funkcionalnosti servlet kontejnera su: prihvatanje zahteva klijenta,
kreiranje instance servlet klase, prosleđivanje rezultata klijentu u
raznim formatima.
Servlet najčešće predstavlja srednji sloj aplikacije – može da prosledi
zahtev donjem sloju aplikacije kao što je napr. baza podataka. Servlet
najčešće radi zajedno sa drugim komponentama kao što su JSP stranice,
Java Bean. Java Servlet je java klasa koja nasleđuje apstraktnu klasu
HttpServlet, a ona nasleđuje apstraktnu klasu GenericServlet koja
implementira 3 interfejsa: Servlet, ServletConfig i Serializable.
Interfejs servlet obezbeđuje metode za realizaciju životnog ciklusa
servleta kao i metode za pristup konfiguraciji servleta. Životni vek
servleta se sastoji od poziva sledećih metoda: init – inicijalizacija,
service – odgovor na zahtev klijenta i destroy – uništavanje servleta.
Metode za pristup konfiguraciji: getServletConfig i getServletInfo.
Interfejs ServletConfig obezbeđuje veliki broj metoda za pristup
informacijama o konfiguraciji. Najčešće korišćene metode su:
getInitParameter(String name) – vraća vrednost parametra na osnovu
imena parametra, getServletContext – vraća referencu na
ServletContext u okviru web aplikacije i getInitParameterNames – vraća
listu imena parametra za inicijalizaciju.
GenericServlet je idalje klasa koja je nezavisna od protokola i
implementira neke metode iz interfejsa Servlet: init i getServletContext.
Implementira pomoćne metode za dobijanje informacija o konfiguraciji
servleta.
Servlet se kreira tako što se nasledi i implementira HttpServlet
apstraktna klasa. Klasa servleta treba da implementira barem jedan od
sledećih metoda: doGet za HTTP get zahteve ili doPost za HTTP post
zahteve. Interfejs Serializable omogućava implementaciju mehanizma
za praćenje sesija.
HTTP get se koristi za preuzimanje podataka ili slika sa web servera i on
je default tip, iako se u osnovi koristi za čitanje ali on može i da pošalje i
neke male podatke prilikom zahteva. HTTP post se najčešće koristi za
slanje podataka sa ekranske forme web serveru – bolje koristiti ako je
sadržaj koji se šalje u zahtevu velik ili treba da ostane poverljiv. Svi
zahtevi u okviru HttpServlet API. Dovoljno je naslediti klasu HttpServlet i
imamo kreiran naš prvi servlet ali dolazi do greške. Status 405 da metod
GET nije podržan na tom URL pa na taj način definišemo na koje HTTP
metode naš server odgovora – svaki metod koji redefinišemo
obezbeđuje prijem odgovarajućeg HTTP metoda. DoGet i doPost su dve
najčešće korišćene metode za obradu zahteva HTTPa – void doPost i
ima parametre requesta, response i baca Exception i isto tako je i
doGet. Dovoljno je samo naslediti klasu HttpServlet i redefinisati
odgovarajuće HTTP metode i imao kreiran naš prvi servlet. Napr. tu u
metodi dodamo response.getWriter().append(’’Hello’’) pa web server
vodi računa o resursima koje dobavlja pa nema potrebe da pozovemo
metodu close od PrintWriter objekta. Korišćenje servleta u url mapping
– definisanje URL adrese za poziv servleta na dva načina web.xml ili
anotacija @WebServlet.