1.

Spring Data
U JPA sa Spring Data: sa obzirom da su CRUD operacije iste nad svim
entitetima i da se samo razlikuju u imenu entiteta Spring Data modul
nudi mogućnost da se ovo pojednostavi. Ideja da Spring na osnovu
imena operacije prepozna šta treba da se uradi. Potrebno je da naš
interfejs nasledi klasu JpaRepository<T, I> da bi smo radili sa JPA. T
označava tip entiteta, a I je tip ključa u entitetu. Odgovarajuću
konfiguracionu klasu je potrebno anotirati sa @EnableJpaRepositories.
Time što nasleđuje JpaRepository kreirani interfejs automatski ima na
korišćenje metode: findAll() koji vraća List<T>, findOne(), count(),
delete(T), deleteAll(), save(T) i exists(I).
Spring Data dozvoljava da se definišu specifični metodi čija imena
zadovoljavaju određenu konvenciju i tad nema potrebe da ih
implementiramo. Primer: public Student findByBrojIndeksa(String
brojIndeksa) pa iako nema implementaciju ovaj metod, vraća studenta
sa zadatim brojem indeksa. Spring Data prepoznaje imena metode koje
imaju imena u skladu sa definisanim paternima i izvršava ih.
Imena metode se sastoje od glagola, subjekta, ključne reči BY i
predikata. Dozvoljeni glagoli su read, find, get i count. Subjekat je
opcionalan deo i ne utiče na parsiranje imena. Predikat je najzanimljiviji
deo i on definiše ograničenja nad upitom. Ograničenja su definisana
posebnim ključnim rečima: And, Or, Like, OrderBy, IgnoringCase,
Between, Null, Not, LessThanEqual, GreaterThanEqual. Jedan od
primera je public List<Student> findByImeOrPrezime(String i, String p)
znači ova metoda treba da vrati sve studente koji imaju ili takvo ime ili
takvo prezime, mogu i oba da važe.
Ispred definicije metoda može se definisati i specifičan upit koji ne
možemo da dobijemo kreiranjem odgovarajućeg imena. Potrebno je
samo iznad metoda definisati anotaciju @Query i u njoj odgovarajuću
select (select s from Student s where ..) naredbu kao string, bez ;.
Ukoliko neki upit ne može da se definiše kroz konvenciju imena ili kroz
query anotaciju, može se koristiti standardni način za izvršavanje upita
preko EntityManagera. Potrebno je kreirati klasu koja će imati sufiks
Impl, a početak imena je isti kao i interfejs koji nasleđuje JpaRepository
(sufiks Impl je default, ali se može kastomizovati). U kreiranoj klasi
implementiramo određeni metod koji smo definisali u interfejsu i na
ovaj način smo zadržali i mogućnosti JpaRepository klase plus dodali
nove metode. Definišemo interfejs u kome definišemo specifičan
metod, dodamo da Spring Data repozitorijum – novi interfejs sa
JpaRepository nasleđuje prethodno napravljeni interfejs i sad klasa
treba da se zove kao Spring Data repozitorijum sa sufiksom Impl i da
implementira prvi interfejs. Ta klasa treba da ima anotaciju repository, i
anotaciju gde koristimo objekat EntityManagera pa iznad da bude
PersistenceContext.

2. Validacija input polja na formi

Umesto da proveravamo da li su svi podaci određenog formata u
metodi kontrolera koristimo Java Validation API. Konfiguracija je
jednostavna, dodamo Hibernate Validator maven dependencije.
Potrebno je još dodati određene anotacije u objekat koji se šalje kroz
formu. Neke anotacije su: @Size – definiše dužinu karaktera u input
polju, @Patern – proverava da li je vrednost određenog oblika, @Past –
provera da li je datum manji ili jednak sa tekućim u sistemu, @NotNull
– da vrednost nije null, @Digit – vrednost mora biti broj i @Max, @Min
– vrednost je broj veći ili manji od zadatog broja. Anotacijom @Valid
pored objekta koji se šalje, definišemo da želimo da primenimo
validaciju i parametar tipa Errors.
Primer: klasa Studenta pa kažemo not null anotacija iznad String
prezime, anotacija not null pa anotacija size gde u zagradama kažemo
min neki broj i max, i ispod je String ime. A metoda ima anotaciju
RequestMapping(value da doda, method je RequestMethod.POST) pa
vraća string i kažemo dodajStudenta sa parametrima @Valid Student s,
Errors e pa se pitamo if e.hasErrors onda da vrati neki string, inače nad
njegovim repozitorijumom napr. sr kažemo da sačuva taj s i da vrati
string da je ok.

3. Prosleđivanje parametara kontroleru

Kao i kod servleta, metode u kontroleru mogu imati parametre
HTTPServletRequest, HTTPServletResponse, HTTPSession i tad
koristimo na isti način kao i kod servleta da pročitamo nešto iz tih
objekata. Preko requesta možemo iskoristiti request.getParameter() i
unutra prosledimo name kako smo stavili u JSP stranici da se zove polje.
Parametri u request objektu se mogu definisati i anotacijom
@RequestParam. Znači da ne pišemo u metodi sa metodom requesta,
nego kao parametar gore kažemo @RequestParam() i stavimo isto taj
name pa pored String to nešto što ćemo koristiti u metodi.
Parametri se mogu prosleđivati i kroz URL adresu kao Path varijable sa
primerom localhost:8080/web/student/getBr/147 ovde smo parametar
147 upisali u URL adresu i na ovaj način obaveštavamo student
kontroleru želimo da pozovemo njegov metod getBr i da mu
prosledimo parametar 147. Ako smo tako koristili onda u value
RequestMapping pored getBr/naziv u kom ćemo čuvati tu vrednost da
bi u metodi kao parametar stavili @PathVariable(sa nazivom koji smo
stavili gore) i gde se sad nalazi kao napr. String broj.
Postavlja se pitanje šta ako treba da prosledimo post HTTP zahtev i pri
tome unosimo veliki broj parametra u HTML formu. Path variable i
čitanje iz requesta objekta nije baš zgodno, zamisli da zaglavlje metoda
ima 10 prosleđenih parametara. Zato nam treba mogućnost da
pošaljemo ceo objekat što je u Springu veoma jednostavno i potrebno
je samo da imamo prazan konstruktor i da se polja u JSP stranici zovu
isto kao polja u objektu. Verovatno da konstruktor treba da vrati novi
objekat sa anotacijom @ModelAttribute, i da to stavljamo i kao
parametar u metodi onako kako smo u atributu JSP stranice sačuvali i
napravimo objekat.

4. Arhitektura web aplikacije bazirane na Springu

Redosled izvršavanja: 1. zahtev stiže do DispetcherServleta, 2. aplikacija
može da ima više kontrolera i da DispetcherServlet mora da prepozna
kome je zahtev upućen pa mu u tome pomažu komponente koje se
nazivaju Handler maperi, 3. DispetcherServlet sad zna kome treba da
uputi zahtev i poziva odgovarajućeg kontrolera, 4. Kontroler obrađuje
zahtev i ukoliko treba da vrati neke podatke klijentu onda ih on pakuje
u model. Takođe kontroler definiše i odgovarajuće logičko ime view
komponente koja treba da prikaže taj model.
5. DispetcherServlet konsultuje komponentu ViewResolver koja treba
da mu na osnovu logičkog imena view komponente koju je poslao
kontroler da da stvarnu implementaciju view komponente, 6.
DispetcherServlet prosleđuje model View komponenti i 7. da View
komponenta renderuje podatke i prikazuje ih korisniku u browseru tj.
odgovor.

5. Principi Dependency Injection

To je tehnika koja čini suštinu Springa. Tehnika koja se koristi kako bi se
dodelilo objekat varijabli nekog drugog objekta. Ideja je da se objekti
inicijalizuju u runtimeu, a ne u compile timeu. Primer bez DI da u okviru
klase koja implementira neki interfejs i ima neko polje drugog tipa u
odnosu na klasu. Poenta je što se to polje inicijalizuje u konstruktoru
klase, ali ne stavlja ga kao parametar konstruktora.
Ukoliko objekte inicijalizujemo u runtimeu onda ne možemo da
koristimo različite implementacije interfejsa tog objekta. Primenom DI
instancira se neka treća komponenta, obično je to kontejner. Dovoljno
je samo naznačiti da će se određeni objekat inicijalizovati u runtimeu.
Primer sa DI je isto kao prethodno, ali u konstruktoru se nalazi polje
koje inicijalizujemo.
Kako povezati konkretne objekte odnosno kako nekom objektu dodeliti
konkretan zadatak – odnosno konkretan objekat drugog tipa kao polje.
U Springu je to moguće uraditi pomoću XML konfiguracionih fajlova ili
pomoću određenih anotacija iz programa. Kažemo u XMLu tag bean id
da je naziv nekog interfejsa i iz koje klase zatim unutra kažemo tag
konstruktor arg da je ref na taj drugi objekat. A taj drugi objekat
napravimo kao bean isto i on je id.
Compiletime je kad instanca u kojoj je uneti kod konvertovan u izvršni,
a runtime je kad se izvršna instanca izvršava.
 6. Alati za pakovanje aplikacija
Building tools: alati za kreiranje izvršne verzije programa na osnovu
izvornog koda. Izvršna verzija može biti: web aplikacija, desktop
aplikacija ili biblioteka koja će se koristiti u drugim projektima. Često je
uključeno i kreiranje dokumentacije, testova. Razni alati su se razvijali
tokom godina: sofisticiraniji i bogatiji novim konceptima,
funkcionalnostima. Dve osnovne komponente su: build script – skript sa
komandama za bildovanje i executable – program koji izvršava skript.
Operacije building toolsa: kompajliranje izvornog koda, kopiranje
resursa, kompajliranje i izvršavanje testova, pakovanje projekta bilo jar,
war zatim deploy, brisanje nepotrebnih resursa i upravljanje povezanim
bibliotekama i projektima preko dependencija.
Druge biblioteke ili projekte koristimo za razvoj našeg programa preko
dependencija. Jedan od osnovnih zadataka alata za pakovanje aplikacija
jeste upravljanje tim dodatnim bibliotekama gde svaki alat na specifičan
način obavlja svoj zadatak. JAR HELL je stanje u kome se naša aplikacija
nalazi zbog problema sa dependencija. Problemi koji se mogu javiti: za
rad nekog jara potrebni su nam drugi jar fajlovi. Da bi smo otkrili koji su
to jar fajlovi, čitamo dokumentaciji ili pokušavamo da eliminišemo
jedan po jedan error tipa NoClassDefFoundError. Na class pathu se
nalaze jarovi koji imaju iste klase ili postoje dva ista jara, sa različitim
verzijama. Prilikom učitavanja jar fajlova, učitaće se onaj koji je prvi na
redu dok ostali će biti sakriveni. Verzije jarova nisu kompatibilne.
Najpoznatiji building toolsu su: Maven, Gradle, Ant, SBT i Ivy. Apache
Ant – skraćeno od Another Neat Tool je jedan od prvi alata za
pakovanje aplikacija. Build script je XML dokument i veoma je
fleksibilan. Postoji kombinacija Ant + Ivy – dodato je upravljanje
povezanim bibliotekama i projektima.
Apache Maven – maven je jevrejska reč koja znači akumulator znanja.
Trenutno je najpopularniji alat za pakovanje aplikacija – posebno kod
Java programa. Build script je XML dokument. Gradle je kombinacija
Mavena i Groovy skriptinga gde za razliku od Anta i Mavena, ne koristi
XML za opis build scripta već Groovy jezik. Prva verzija se pojavila 2012.
godine i postoji plugin za Eclipse. Ima veoma dobru dokumentaciju.

7. Filteri
Filteri su softverske komponente koje presreću zahteve klijenta ili
odgovore servera i vrše neke aktivnosti. Filteri mogu da odbiju neke
zahteve ili da napr. izvrše redirekciju zahteva. Za rad sa filterima je
potrebno implementirati javax.servlet.Filter interfejs. Filteri se mogu
definisati u deployment deskriptoru, programski ili pomoću anotacija.
Upotreba filera su razne: logovanje aktivnosti u aplikaciji (sačuvati
informaciju o svakom HTTP zahtevu i svakom odgovoru), autentifikacija
(provera da li je neki korisnik ulogovan se može vršiti samo na jednom
mestu – u filteru), kriptovanje poruka koje se razmenjuju između
servera i neke aplikacije i upravljanje greškama.
Metodi ovog interfejsa Filter su: init(FilterConfig f), destroy() i
doFilter(ServletRequest r, ServletResponse rs, FilterChain fc). Potrebno
je definisati filter u deployment deskriptoru tj. web.xml sa tagom filter i
unutra tagovi filter name i filter class. Tu se mogu postavljati vrednosti
URL paterna ili naziva servleta na koje će se primenljivati filteri i radi se
u okviru taga filter mapping gde kažemo tag filter name i tagovi url
patern ili servlet name. Iznad klase je potrebno postaviti anotaciju
@WebFilter i možemo tu navesti filterName, urlPatterns ili
servletName.
HTTP zahtev ili odgovor može biti presretnut od strane više filtera koji
su stavljenu u lanac – filter chain. Svaki filter mora pozvati metodu
doFilter kako pri HTTP zahtevu ili odgovoru prosledio sledećem filter.
Da bi smo definisali redosled izvršavanja filtera koristimo deployment
deskriptor, ali moguće je to uraditi i kroz odgovarajuće metode. Prvo se
izvršavaju filteri koju su definisani preko URL paterna, pa onda oni koji
su definisani preko imena servleta. Ako ima više filtera, prvo se
izvršavaju oni koji imaju opštiji URL patern.

8. JSP akcije
JSP specifikacija obezbeđuje nekoliko tagova koji se mogu koristiti u
okviru JSP stranica za izvršavanje određenih akcija – zamena za
skriptlet. Pišu se sa prefiksom jsp:. Neke od najčešće korišćenih akcija
su: forward (prosleđuje zahtev drugoj stranici), include (uključuje
odgovor neke druge stranice), plugin (umetanje Java apleta), useBean
(instancira JavaBean klasu), setProperty (postavlja vrednost atributa
JavaBean klase) i getProperty (preuzima vrednost atributa JavaBean
klase).
U JSP stranicama kažemo da koristimo JavaBean klase korišćenjem 3
akcije: useBean – instancira JavaBean klasu, setProperty – postavlja
vrednost atributa JavaBean klase i getProperty – preuzima vrednost
atributa JavaBean klase. Ove akcije rade isključivo sa JavaBean klasama.
To su klase koje imaju konstruktor bez argumenata, set i get metode za
sva privatna polja i implementiraju interfejs java.io.Serializable.
Sintaksa <jsp:useBean id=”myBean” class=”PersonBean”
scope=”page|request|session|application” izaberemo request> gde je
id – naziv objekta JavaBean klase, class – JavaBean klasa čiji objekat se
instancira i navodi se puno ime klase sa paketima i scope je opseg
vidljivosti beana. Data deklaracija je ekvivalentna sledećem Java kodu:
PersonBean myBean = (PersonBean) request.getAttribute(’’myBean’’) i
ako sad myBean je jednak null onda je myBean = new PersonBean() pa
sa request.setAttribute(’’myBean’’, myBean). useBean akcija proverava
da li u navedenom opsegu vidljivosti postoji bean sa datim imenom, ako
postoji preuzima ga ili ako ne postoji, kreira novi bean i smešta ga u
navedeni opseg. Akcija <jsp:getProperty name=”beanName”
property=”propertyName”/> naprimer kad smo postavili myBean u
useBeanu ovde ga napišemo, a kao property stavimo šta ima od polja
napr. name.
Jsp:setProperty postavlja vrednost atributa beana i postoje 4 načina:
<jsp:setProperty name=”beanName” property=”*”> postavlja vrednosti
svih atributa bean na osnovu vrednosti istoimenih request parametara,
<jsp:setProperty name=”beanName” property=”propertyName”>
postavlja vrednost jednog atributa na osnovu vrednosti istoimenog
request parametra, <jsp:setProperty name=”beanName”
property=”propertyName” param=”parameterName”> postavlja
vrednost jednog atributa na osnovu vrednosti request parametra sa
zadatim imenom i poslednji način je <jsp:setProperty
name=”beanName” property=”propertyName”
param=”parameterName value=”propertyValue”> postavlja vrednost
atributa beana na zadatu vrednost.
Data akcija <jsp:setProperty name=”person” property=”name”> je
ekvivalentna sledećem Java kodu,
person.setName(request.getParameter(’’name’’);.
Akcija setProperty se može postaviti posle definicije bean – akcije sa
useBean i to će značiti da će se vrednost atributa promeniti bez obzira
da li se bean kreira prvi put ili ne. Akcija može biti definisana u okviru
useBean akcije i to će značiti da vrednost atributa se postavlja samo kad
se bean prvi put kreira.
Tipičan patern za komunikaciju servleta i JSP je da servlet bude zdužen
za primanje HTTP zahteva i implementaciju poslovne logike i da zatim
odgovarajući model prosledi JSP stranici koja će znati da prikaže taj
model. Potrebna klasa je RequestDispetcher i metoda forward,
setujemo atribut u request i onda sa
request.getRequestDispetcher(kažemo putanju do
stranice).forward(request, response). A onda u stranici kao skriptlet
napravimo objekat tog što smo setovali i sa request getujemo atribut
od toga.

9. Implicitni objekti
To su predefinisane promenljive koje se odnose na neke najčešće
korišćene koncepte u web tehnologijama. Napr. pristup određenom
opsegu vidljivosti i često se koriste u skriptletima.
Implicitni objekti sa njihovim opisima: request (objekat tipa
HTTPServletRequest i odnosi se na trenutni HTTP zahtev), response
(objekat tipa HTTPServletResponse i odnosi se na tekući HTTP odgovor
koji se prosleđuje brauzeru), out (JspWriter objekat se odnosi na output
stream HTTP odgovora), session (objekat klase HTTPSession i odnosi se
na tekuću sesiju), application (objekat klase ServletContext i odnosi se
na celu web aplikaciju) i page (objekat ekvivalentan promenljivoj this u
Javi).
Generalna preporuka je ne koristiti skriptlete, izraze i deklaracije tj. ne
ugrađivati Java kod u JSP stranicu. Zato što je teško za održavanje,
nečitko je, HTML dizajn je pomešan sa Java kodom i narušava MVC
patern – u skriptletima se može greškom naći nešto što pripada
kontroleru. Alternativa jesu JSP akcije, JSTL i EL.
Ako u JSP stranicu hoćemo da ubacimo nešto što ne može da se uradi
preko JSP akcije, JSTL i EL onda to verovatno ne pripada JSP stranici i
treba ga staviti na drugo mesto napr. Java Servlet.

10. Šta je JSP

JSP je Java Server Pages i to je deo Java EnterpriseEdition platforme.
Koristi se kao tehnologija za razvoj Java web aplikacija i proširenje Java
servlet tehnologije. JSP fajl ima ekstenziju jsp. JSP tehnologija
omogućava jednostavno i brzo kreiranje dinamičnog web sadržaja.
Osnovna zamisao jeste ugradnja Java koda u HTML stranicu, ali danas je
to mnogo više jer imamo i JSP akcije, biblioteke tagova i expression
language. JSP je nastao iz Java Servlet tehnologije i predstavlja drugačiji
tj. lakši način pisanja servleta.
Problem sa Java Servlet tehnologijom: jeste što je lakše menjati HTML
nego upravljati velikim brojem println naredbi. Dizajn stranice HTML i
programska obrada sa Javom su pomešani u istim datotekama, pritom
dizajn može biti veoma komplikovan. Teško je razdvojiti funkcije
dizajnera i programera.
JSP tehnologija predstavlja nadogradnju Servlet tehnologije. JSP
stranica se prevodi u Java Servlet. Dobijeni servlet se kompajlira i
obrađuje zahteve JSP stranice. Rezultat njegovog izvršavanja tj. obrade
zahteva jeste rezultat izvršavanja JSP stranice. Kod sledećih poziva iste
stranice, web server poziva odgovarajući servlet – ne kompajlira iznova
JSP stranicu. Generisanje servleta, njegovo kompajliranje i pozivanje je
zadatak servlet kontejnera.
JSP nasprem drugih tehnologija: nasprem statičkog HTML (ne može da
prikaže dinamički sadržaj napr. podatak iz baze), nasprem ASP – Active
Server Pages (zavistan od platforme – Microsoft) i nasprem JavaScripta
(generiše dinamički HTML na klijentskoj strani, ali teže pristupa serveru
i obavlja komplikovane operacije poslovne logike i pristupa bazi
podataka)
JSP sintaksa je nekad bila HTML + Java, danas je HTML + JSP tagovi + EL i
više liči na XML dokument. Elementi JSP stranice su: skripting elementi,
implicitni objekti – predefinisane promenljive, JSP akcije, EL i dodatni
tagovi tj. JSTL biblioteka.