Dezvoltarea de aplicatii web folosind limbajul de programare Java. Framework- ul Struts.

- Dezvoltarea de aplicaţii Web dinamice folosind limbajul de programare Java

- Servleti- JSP(Java Server Pages)- Framework-ul Struts- Framework-ul de formatare Tiles

1.1. Ce este Struts?

Struts este un framework MVC Java folosit pentru dezvoltarea de aplicatii web bazate pe tenologia JSP construit peste platforma J2EE.

Struts este folosit in primul rand in aplicatii bazate pe tehnologia JSP dar el poate fi folosit de asemenea si in aplicatii bazate pe template cum ar fi Velocity.

Voi incepe descrierea frameworkului Struts printr-o introducere in platforma J2EE si in tehnologia JSP.

1.2. Platforma J2EE

J2EE este o platforma ce ofera posibilitatea de a executa aplicatii Java pe partea de server.

Intainte de aparitia J2EE aplicatiile Java pentru partea de server erau scrise utilizand API – uri (Aplication Programing Inteface) oferite de diferiti producatori. Din moment ce fiecare producator avea un API si o arhitectura unica, dezvoltatorii si arhitectii nu puteau reutiliza cunostintele acumulate de a lungul dezvoltarii unei aplicatii cu ajutorul unui astfel de API, cand li se cerea schimbarea API-ului cu un altul. Curba de invatare era foarte mare (costuri ridicate) pentru ca dezvoltatorii si arhitectii sa lucreze cu fiecare dintre aceste API-uri. In consecinta intreaga comunitate de programatori Java ar fi fost fragmentata in grupuri izolate si acest fapt ar fi facut aproape inposibila dezvolarea de aplicatii enterprise serioase in limbajul Java.

Din fericire introducerea platformei J2EE si adoptarea ei de catre producatori, a rezultat in standardizarea API-ului ei, acest fapt reducand curba de invatare pentru dezvoltatorii Java. Specificatia J2EE defineste o multime de interfete si cateva clase. Producatori (ca BEA si IBM de exemplu) au oferit implemetari pentru aceste interfete astfel creand servere de aplicatii, acest proces numindu-se aderare la specificatia J2EE.

Serverele de aplicatii J2EE pun la dispozitie servicii de infrastructura cum ar fi threading, pooling, si management de tranzacii direct din “fabricatie”. In

1

acest fel dezvoltatorii se pot concentra numai pe implementarea partii de “business logic” (functionalitatea propriuzisa a aplicatiei) si a interfetelor cu utilizatorul.

Specificatia J2EE definsete containere pentru administrarea ciclului de viata a componentelor de pe partea de server.

Exista doua tipuri de containere – containere Servlet (Servlet Container) si containere EJB (EJB Container). Containerele Servlet administreaza ciclul de viata al aplicatiilor web iar containerele EJB administreaza ciclul de viata al EJB-urilor (Enterprise Java Beans).

1.3. Aplicatii web J2EE

Orice aplicatie care ruleaza intr-un container Servlet se numeste aplicatie web J2EE. Containerul servlet implementeaza specificatiile Servlet si JSP. El ofera diferite puncte de intrare pentru rezolvarea unei cereri (request) HTTP initiata de un browser web. Exista trei puncte de intrare pentru un browser in aplicatiile web J2EE – Servlet, JSP si Filter.

- Servletii se pot crea, extinzand clasa javax.servlet.http.HttpServlet si implementand metodele doGet() si doPost() ale acesteia.

- JSP urile se pot crea simplu, creand un fisier text care contine etichete de markup JSP (JSP markup tags).

- Filtrele se pot crea implementand interfata javax.servlet.Filter.

Containerul servlet este informat despre existenta servletilor si a filtrelor atunci cand acestea vor fi declarate intr-un fisier special numit web.xml. O aplicatie web J2EE are doar un singur fiser web.xml. Aplicatiei web i se va face “deploy” in containerul Servlet sub forma unei arhive zip numita Web ARchive – cunoscuta sub numele de fiser WAR.

1.4. JSP – uri

JSP urile sunt servleti deghizati! Asadar daca JSP urile sunt servleti, de ce mai avem nevoie de ele?

Raspunsul la aceasta intrebare sta in separarea conceptelor care exista in adevaratele proiecte J2EE.

Pe vremea cand JSP urile nu existau, servletii erau singurele componente pentru a dezvolta aplicatii web J2EE. Ei rezolvau cererile de la browsere, invocau metode de bussines logic si generau raspunsuri (response) sub forma de pagini HTML, pentru browser.

2

Problema aparea din cauza ca Servletul este o clasa Java scrisa de programatori Java. Este in regula ca un servlet sa se ocupe de tratarea cererilor venite de la browser si sa aiba in interiorul lui apeluri de metode de bussiness logic sau functionalitati de presentation logic, insa partea de formatare in HTML si generare a raspunsului ii revine celui care se ocupa de crearea paginilor HTML (page author), care de cele mai multe ori nu are cunostinte de Java.

Intrebarea care s-a pus a fost: cum sa se faca separarea intre aceste doua cocepte intalnite intr-un servlet. JSP a fost raspunsul la aceasta intrebare.

Filozofia din spatele JSP ului este:

Dezvoltatorii de pagini HTML stiu HTML. Dar HTML este un limbaj de markup.Faptul ca invata cateva taguri in plus, nu e mare lucru pentru un dezvoltator de pagini HTML, sau macar este mult mai simplu decat sa invete Java si Orientare pe Obiect. JSP pune la dipozitie cateva tag-uri standard iar programatorii Java pot crea altele specializate.

Dezvoltatorii de pagini HTML pot scrie pagini pentru partea de server (server side pages) folosind tagurile HTML impreuna cu tagurile JSP. Aceste pagini se vor numi JSP-uri. JSP urile se numesc pagini pentru partea de server din cauza ca, cel care le interpreteaza pentru a genera raspunsuri HTML care vor fi apoi trimise la client (browserul web), este containerul Servlet.

In alte limbaje paginile server sunt parsate de fiecare data cand ele sunt accesate acest lucru fiind destul de costisitor. In J2EE aceste costuri sunt reduse generand cate o clasa Java pentru fiecare JSP. Prima data cand un JSP este accesat, continutul acestuia este parsat si se genereaza o clasa Java echivalenta cu acesta, accesurile ulterioare fiind mult mai rapide.Clasa Java generata parsand un JSP nu este altceva decat un Servlet. In alte cuvinte fiecare JSP este parsat la runtime pentru a genera clase Servet.

1.5.A

rhitectura denumita Modelul 1

3

Business Logic si Presenation Logic – Care este diferenta?

Termenul de business logic se refera la partea de functionalitate a aplicatiei, centrul unui sistem, de obicei implementata sub forma de Session EJB-uri.

Codul care controleaza navigarea in JSP, se ocupa de datele care vin de la utilizator si invoca metode business logic potrivite, se mai numeste si Presentation Logic.

Pagina JSP propriuzisa (interfata cu utilizatorul) contine HTML si taguri specializate si cat mai putin business logic si presentation logic posibil.O regula de baza este ca, cu cat JSP ul este mai sarac in continut logic cu atat mai usor este de intretinut.

Modelul 1 este cea mai usoara cale de a dezvolta aplicatii web bazate pe tehnologia JSP. In Modelul 1 browserul acceseaza direct paginile JSP. Cu alte cuvinte cererile utilizatorilor sunt rezolvate direct de catre JSP.

Voi ilustra functionalitatea Modelului 1 printr-un exemplu. Sa consideram o pagina HTML care contine un hyperlink catre un JSP. Cand utilizatorul da click pe hyperlink, JSP ul va fi invocat direct. Acest lucru este ilustrat in figura 1.1. Containerul Servlet parseaza JSP-ul si executa Servletul Java rezultat. JSP-ul contine in interiorul lui cod si taguri pentru a accesa JavaBean-uri reprezentand partea de model a unei aplicatii. JavaBean-urile din model contin atribute care stocheaza valorile parametrilor HTTP din query string. Aditional JSP-ul mai contine cod pentru conectarea la middle tier sau direct la baza de date utilizand JDBC, pentru a prelua datele aditionale necesare pentru a afisa pagina. Folosind datele stocate in JavaBean-uri si alte clase ajutatoare, JSP-ul este apoi generat ca o pagina HTML, si trimis utilizatorului ca raspuns.

Dezavantaje ale arhitecturii Model 1

Modelul 1 este usor de folosit. Exista o oarecare separare intre continut (JavaBean-uri) si prezentare (JSP). Acesta separare este destul de buna pentru aplicatii mici. Aplicatiile mari au o cantitate mare de logica de prezentare (presenation logic). In Modelul 1, logica de prezentare duce de obicei la cantitati mari de cod Java continut in paginile JSP sub forma de scriptleti. Acest lucru este urat, si intretinerea unor astfel de pagini poate fi un cosmar chiar si pentru cei mai experimentati dezvoltatori Java. In aplicatiile mari JSP-urile sunt dezvoltate si intretinute de dezvoltatorii de pagini web. Amestecarea de scriptleti cu taguri duce la neclaritate in definirea rolurilor in proiect si aceasta este o problema.

Controlul aplicatiei este descentralizat in Modelul 1 din moment ce pagina care va trebui afisata mai departe este determinata de logica inclusa in pagina curenta. Controlul descentralizat poate da mari batai de cap cand specificatiile aplicatiei se modifica constant.

4

1.6. Arhitectura denumita Modelul 2 – MVC

MVC este acronimul pentru Model View Controller. MVC isi are originea in limbajul de programare SmallTalk si a reushit sa ocupe un rol important in comunitatea Java. Modelul 2 JSP este de fapt un MVC aplicat aplicatiilor web si in consecinta cele doua denumiri pot fi folosite alternativ in lumea web. Figura 1.2 ilustreaza arhitectura Modelului 2 (MVC).

Principala diferenta dintre Modelul 1 si Modelul 2 este aceea ca in Modelul 2, un controlerul trateaza cererile utilizatorilor in loc de alt JSP. Controlerul este implementat ca un servlet.

Cand un utilizator va face o cerere catre aplicatie se vor executa urmatorii pasi:

1. Servletul Controller (controler) rezolva cererea utilizatorului (acest lucru inseamna ca hyperlinkul din pagina JSP trebuie sa trimita la controler)

2. Controlerul instantiaza apoi JavaBean-urile potrivite bazandu- se pe parametri din request (si aditional bazandu-se pe atributele aflate in sesiune)

3. JavaBean-urile comunica mai departe cu middle tier sau direct cu baza de date pentru a pregati datele cerute.

4. Controlerul seteaza JavaBean-ul pentru rezultat in unul dintre contextele – request, session, application

5. Controlerul retrimite cererea catre urmatorul view (JSP) bazandu-se pe URL-ul cererii

6. View – ul va utiliza JavaBean-ul rezultat in pasul 4 pentru a afisa datele.

De remarcat este faptul ca nu exista nici un fel de logica de prezentare in JSP. Singura functie a JSP-ului in Modelul 2 este aceea de a afisa datele din JavaBean-ul aflat intr-unul din scopurile enumerate mai sus.

5

Avantajele arhitecturii Model 2 Atata timp cat nu exista presentation logic in JSP, nu exista scriptleti.

Acest fapt presupune o intretinere mai usoara a paginilor JSP. Desi Modelul 2 incearca eliminarea scriptletilor din paginile JSP, el nu impune acest lucru, scriptletii putand fi folositi daca este nevoie de ei.

Cu MVC pot exista in aplicatia web atatia servleti controler, de cati este nevoie. Astfel poate exista un singur Servlet Controller per modul.

In orice caz exista mai multe avantaje pentru care se recomnada ca aplicatia web sa contina numai un singur servlet controler. Intr-o aplicatie web obijnuita pot exista mai multe operatiuni (taskuri) care trebuiesc executate pentru fiecare request. De exemplu trebuie verificat daca un utilizator care a cerut executia unei operatii este autorizat sa faca acest lucru. De asemenea poate se doreste inregistrarea intr-un log (logare) a intrarii si iesirii unui utilizator din aplicatie pentru fiecare cerere sau poate se doreste centralizarea operatiunilor de delegare a cererilor catre alte pagini. Avand mai multi servleti controler exista posibilitatea repetarii codului pentru aceste operatiuni in toti servletii controler. Un singur controler pentru toata aplicatia web va ofera posibilitatea de a centraliza toate aceste operatiuni intr un singur loc, astfel codul fiind mult mai clar si mai usor de intretinut.

Aplicatiile web bazate pe modelul 2 sunt usor de intretinut si extins, din moment ce view-urile nu au legatura unele cu celelalte si nu exista logica de prezentare in view. Modelul 2 ofera posibilitatea definirii clare a rolurilor si responsabilitatilor in proiecte mari, permitand o mai buna coordonare intre membrii unei echipe.

Dezavantajele arhitecturii Model 2Daca MVC este atat de bun de ce mai avem nevoie de Struts pana la

urma? Raspunsul sta in dificultatile asociate cu aplicare mdelului MVC peste complexitatile lumii reale.

In aplicatiile mari si mijlocii, controlul si procesarea logica centralizate in servlet – cel mai mare avantaj al modelului MVC este de asemenea si un mare dezavantaj. De exemplu sa consideram o aplicatie medie cu 15 pagini JSP. Sa consideram ca fiecare pagina are 5 linkuri (sau butoene de submit) aceasta insemnand in total 75 de tipuri de cereri de administrat pentru intreaga aplicatie. Din moment ce utilizam modelul MVC, un servlet controler centralizat se ocupa de rezolvarea fiecarei cereri care vine de la utilizator. Pentru fiecare tip de cerere exista in metoda doGet()a servletului controler un bloc “if” in care se proceseaza cererea si se trimite controlul catre urmatorul view. Pentru acesta aplicatie medie servletul controler contine 75 de blocuri if.

Desi servletul controler a fost o idee buna la inceput, odata cu evolutia aplicatiilor care au de venit din ce in ce mai complexe, aceste a devenit din ce in ce mai mare si mai dificil de intretinut. Aceasta problema este cunoscuta sub numele de “Fat Controler”.

6

1.7. MVC cu controler configurabil

Pentru aplicatiile mari modelul MVC obisnuit nu mai este indeajuns de bun. Pentru a ne confrunta cu complexitatile aplicatiilor mari acest model trebuie extins cumva. Un mecanism de extinedere, care sa raspandit si a fost adoptat foarte repede, este modelul MVC cu controler configurabil. Acesta este ilustrat in figura 1.4.

Cand o cerere HTTP ajunge de la client, controlerul servlet cauta intr-un fiser de proprietati pentru a decide care este clasa Handler potrivita pentru tratarea cererii HTTP.Aceasta clasa handler este cunoscuta sub numele de Request Handler. Request Handler-ul contine logica de prezentare pentru cererea HTTP cu care este asociat, si include invocari de business logic. Cu alte cuvinte un Request Handler face tot ce este necesar pentru rezolvarea unei cereri HTTP. Singura diferenta pana acum fata de MVC ul obijnuit, este ca servletul controler cauta in fiserul de proprietati pentru a instantia un Handler potrivit in loc sa il cheme direct.

Pentru ca servletul controler sa instantieze Handlerul potrivit pentru o cerere HTTP el se foloseste de URL-ul cererii HTTP. Doua cereri HTTP diferite nu pot avea acelasi URL, asadar fiecare URL identifica in mod unic o cerere pe partea de server si pentru fiecare URL exista un Handler unic. Cu alte cuvinte, exista o legatura unu la unu intre fiecare URL si clasa Handler insarcinata cu rezolvarea requestului. Aceste informatii sunt stocate in fisierul de proprietati ca perechi cheie – valoare (key-value). Servletul controler incarca fisierul de proprietati la pornire petru a gasi Request Handler-ul potrivit pentru URL – ul fiecarei cereri.

Servletul controler foloseste Java Reflection pentru a instantia Request Handlerul. In orice caz trebuie sa existe ceva comun intre request handler-e pentru ca servletul sa poata instantia in mod generic toate handler-ele. Parte comuna este ca toate Request Handler-ele implementeaza aceiasi interfata pe

7

care o vom numi Handler Inteface. In cea mai simpla forma aceasta interfata are o metoda denumita execute(). Controlerul servlet instantiaza Request Handler-ul in metoda doGet() si ii invoca metoda execute() utilizand Java Reflection. Metoda execute() invoca niste metode business logic si apoi selecteaza urmatorul view care ii va fi afisat utilizatorului. Controlerul servlet inainteaza apoi cererea catre JSP ul selectat. Toate acestea se intampla in metoda doGet() a controlerului, iar ciclul de viata al acestei metode ramane intotdeauna neschimbat. Ce se schimba este metoda execute() a Request Handlerului.

Modelul de arhitectura pe care este bazat frameworkul Struts este asemanator cu cel prezentat mai sus. In loc de un fisier de proprietati, ca in cazul de mai sus, Struts foloseste ca fiser de configurare un fiser XML in care mai stocheaza si alte informatii utile.

1.8. Struts la prima vedere

In ultima sectiune am vazut principiile care stau la baza frameworkului Struts.In aceasta sectiune vom descrie mai detaliat terminologia utilizata de frameworkul Struts pentru servlet-ul controler si obiectele handler care au fost descrise anterior. Figura 1.4 este o adaptare a figurii 1.3 utilizand terminologia Struts.

In struts exista un singur servlet controler pentru intreaga aplicatie. Acest servlet se numeste ActionServlet si se afla in pachetul org.apache.struts.action. El intercepteaza fiecare cerere de la client si populeaza un ActionForm cu datele obtinute din parametrii cererii HTTP. ActionForm-ul reprezinta o clasa JavaBean obisnuita. Ea are mai multe atribute care corespund parametrilor cererii HTTP si metode get si set pentru aceste atribute. Pentru fiecare cerere HTTP care va fi rezolvata utilizand frameworkul Struts trebuie creata cate o clasa ActionForm extinzand clasa org.apache.struts.action.ActionForm. De exemplu pentru o cerere HTTP de forma: http://localhost:8080/appname/create.do?firstName=John&lastName=Doe clasa MyForm care extinde org.apache.struts.action.ActionForm va contine doua atribute – firstName si lastName precum si metode get si set pentru aceste campuri.

8

Pentru o mai buna intelegere a ActionForm-urilor putem spune ca acestea sunt niste obiecte de transfer dinspre partea de view spre partea de controler (View Data Transfer Object). Acestea sunt niste obiecte care pastreaza datele din pagina HTML si le transfera in alte clase ale aplicatiei.

ActionServlet-ul instantiaza apoi un Handler.Numele acestui handler este obtinut dintr-un fisier XML si depinde de URL-ul cererii. Acest fiser XML este cunoscut sub numele “Struts configuration file” (fisier de configurare pentru frameworkul Struts) si denumirea lui este in general struts-config.xml.

In terminologia Struts, Handler-ul se numeste Action si poate fi creat extinzand clasa Action din pachetul org.apache.struts.action.

Clasa Action este o clasa abstracta si defineste o singura metoda denumita execute(). Acesta metoda trebuie suprascrisa in actiunile create si se foloseste pentru ivocarea metodelor business logic. Metoda execute() returneaza numele view-ului (JSP) care urmeaza sa fie afisat utilizatorului. ActionServlet–ul inainteaza cererea la view-ul selectat.

9

clasa MyForm:

public class MyForm extends ActionForm {private String firstName;private String lastName;

public MyForm() {firstName = “”; lastName = “”;

}public String getFirstName() {

return firstName;}public void setFirstName(String s) {

this.firstName = s;}public String getLastName() {

return lastName;}public void setLastName(String s) {

this.lastName = s;}

}

Cam asa arata Struts la prima vedere, dar el este, binenteles, mult mai complex de atat. Pe parcursul dezvoltarii unei aplicatii, atat autorul paginilor web cat si dezvoltatorul trebuie sa se coordoneze si sa se asigure ca orice schimbare intr-o parte este corect tratata in cealalta parte. Aceasta duce la dezvoltarea rapida a aplicatiilor web prin separarea conceptelor in proiecte.

Frameworkul Struts ofera o cale eleganta de tratare si procesare a datelor venite de la utilizator. El are de asemenea puncte de extensie pentru a fi specializat.

1.9. Instalarea serverului de aplicatii Tomcat si a fremeworkului Struts

Pentru dezvoltarea aplicatiilor web folosind framework-ul Struts avem nevoie de un server de aplicatii. Am ales a server de aplicatii serverul Tomcat oferit de Apache. Acesta poate fi descarcat de la urmatorul link : http://jakarta.apache.org/tomcat. de unde puteti alege varianta cu extensia zip. Pentru instalare dezarhivati arhiva zip. Va fi creat automat un director cu denumirea jakarta-tomcat-<version_number>. Acesta reprezinta directorul TOMCAT_HOME. In directorul TOMCAT_HOME exista doua directoare care ne intereseaza mai mult: directorul bin si directorul webapps.

Directorul bin contine doua fisere bat, startup.bat pentru a porni serverul si shutdown.bat pentru a opri serverul. Toate fiserele WAR vor fi puse in directorul webapps de unde vor fi deployate automat de catre server.

10

Instalare frameworkului Struts este foarte ushoara. Pe site-ul web http://jakarta.apache.org/struts mergeti la sectiunea download si selectati versiunea 1.1. Odata descarcata arhiva zip a acestei versiuni, dezarhivati-o intr-o locatie care va place. Se va crea automat un director numit “jackarta-struts-1.1”. Acest director are trei subdirectoare.

Directorul lib contine fiserul struts.jar – libraria de baza – si alte fisere jar de care depinde Struts. In general multe dintre aceste fisere vor trebui copiate in directorul WEB-INF/lib din aplicatia pe care o dezvoltati.

Directorul webapps contine mai multe fisere war care pot fi puse in directorul webapps al serverului de aplicatii Tomcat.In acest moment puteti testa serverul Tomcat si citi in acelasi timp documentatia struts. Pentru aceasta trebuie sa urmati urmatorii pasi:

- Porniti serverul Tomcat utilizand fiserul startup.bat- Puneti fiserul war struts-documentation.war din directorul webapps din

cadrul distributiei Struts in directorul webapps din Tomcat. Fisierul war va fi deployat imediat.

- Accesati documentatia accesand din browserul web URL-ul http://localhost:8080/struts-documentation

1.10. Componentele frameworkului Struts

Componente din categoria controler

ActionServlet-ul si clasele cu care colaboreaza reprezinta cea mai importanta parte a framework-ului. Aceste clase sunt : RequestProcessor, ActionForm, Action, ActionMapping and ActionForward.

Componente din categoria view

Categoria view cuprinde clase utilitare – o varietate de taguri care usureaza interactiunea dintre view (JSP) si controller. Folosirea acestor clase nu este obligatorie, dezvoltatorii putand scrie propriile clase utilitare. In orice caz, a scrie clase utilitare specializate care sa imite comportamentul claselor utilitare oferite de Struts pe partea de view, in cazul in care se foloseste JSP pentru acesta parte, inseamna munca de doua ori si nu se recomanda acest lucru.

In cazul folosirii framework-ului Struts cu Cocoon sau Velocity, ramane la latitudinea dezvoltatorului sa isi creeze componente specializate pe partea de view, Struts neoferind nici un suport pe partea de view pentru aceste tehnologii.

Componente din categoria model

Struts nu ofera nici o componenta din aceasta categorie. Deoarce fiecare aplicatie este diferita in ceea ce priveste partea de business logic, componentele de model vor fi diferite de asemenea, si ele nu ar trebui sa fie dependente de

11

partea de prezentare. Filozofia limitarii framework-ului la ceea ce este esential si absolut necesar, a facut din Struts un framework generic si reutilizabil. Desi ActionForm-urile ar putea fi interpretate ca si componente apartinand modelului, ele nu sunt altceva decat niste obiecte de transfer, dependente de framework, care au rolul de a transfera datele de la utilizator catre diferite clase din interiorul controler-ului.

1.10.1. Ciclul de viata al unei cereri HTTP (request) in Struts

ActionServletComponenta centrala a framework-ului Struts este ActionServlet-ul.Aceasta este o clasa care extinde javax.servlet.HttpServlet si executa urmatoarele operatiuni:

1. La pornire, in metoda init(), citeste fiserul de configurare Struts si il incarca in memorie

2. In metodele doGet() si doPost() intercepteaza cererile HTTP si le trateaza corespunzator.

Numele fiserului de configurare Struts nu este batut in cuie. Este doar o conventie ca acest fiser sa se numeasca struts-config.xml si sa se afle direct in directorul WEB-INF al aplicatiei web. Acest fisier se poate denumi oricum si poate fi pus in oricare subdirector din WEB-INF, deoarece numele acestui fiser poate fi configurat in fiserul web.xml.

Intrarea din fiserul web.xml care foloseste la configurarea ActionServlet-ului si al fiserului de configurare Struts este urmatoarea:

<servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet </servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/config/myconfig.xml </param-value> </init-param> <load-on-startup>1</load-on-startup></servlet>

In intrarea de mai sus fiserul de configurare Struts se gaseste in directorul WEB-INF/config si se numeste myconfig.xml. ActionServlet-ul va lua numele fiserului de configurare Struts ca un parametru de initializare. La pornire, in metoda init(), ActionServlet-ul citeste fiserul de configurare Struts si creaza in memorie obiecte de configurare potrivite (structuri de date).

Ca orice servlet ActionServlet-ul invoca metoda init() cand primeste prima cerere HTTP. Operatia de incarcare a fisierului de configurare Struts in obiecte

12

de configurare dureaza mai mult. Daca obiectele de configurare Struts ar fi create la prima cerere HTTP, aceasta operatiune ar afecta performanta aplicatiei intarziind raspunsul pentru primul utilizator. O alternativa ar fi specificarea parametrului load-on-startup din web.xml, ca in exemplul de mai sus. Specificand parametrul load-on-startup cu valoarea 1, se instiinteaza containerul servlet ca trebuie sa cheme metoda init() pentru acest servlet la pornirea lui.

A doua insarcinare pe care o are ActionServletul este aceea de a intercepta cererile HTTP bazandu-se pe un pattern URL, si de a le rezolva.

Pattern-ul URL poate fi ori o cale ori un sufix. Aceasta este specificate utilizand atributul servlet-mapping in web.xml. Un exemplu de declarare a unui servlet-mapping este urmatorul:

<servlet-mapping><servlet-name>action</servlet-name><url-pattern>*.do</url-pattern>

</servlet-mapping>

Daca utilizatorul va tasta URL-ul http://localhost:8080/App1/submitForm.doin bara de URL din browser, URL-ul va fi interceptat si procesat de ActionServlet din moment ce respecta patternul *.do, si are sufixul “do”.

Odata ce ActionServlet-ul intercepteaza cererea HTTP, el nu mai face mare lucru. El deleaga rezolvarea cererii catre alta clasa numita RequestProcessor invocand metoda process() a acesteia. Figura 2.1 ilustreaza o diagrama de secventa cu componentele Struts din categoria controler, colaborand in procesul de rezolvare a unei cereri HTTP,in interiorul metodei process() din RequestProcessor. O mare parte a functionalitatii controlerului Struts este inclusa in metoda process() a clasei RequestProessor. Intelegerea diagramei de secventa din figura 2.1, va va ajuta in rezolvarea problemelor ce pot aparea in aplicatiile Struts din viata reala.

13

1.10.2. RequestProcessor si ActionMapping

RequestProcessor-ul face urmatoarele in metoda process():Pasul1. RequestProcessor-ul gaseste in fisierul struts-config.xml blocul potrivit pentru URL-ul primit. Acest bloc se numeste in terminologia Struts ActionMapping. ActionMapping este o clasa din pachetul org.apache.struts.action. ActionMapping-ul este o clasa care face legatura dintre un URL si un Action. Un exemplu de ActionMapping asha cum apare el in fisierul de configurare Struts, struts-config.xml poate fi:Listing 2.1 A sample ActionMapping from struts-config.xml<action path="/submitDetailForm"

type="mybank.example.CustomerAction"name="CustomerForm"scope="request"validate="true"input="CustomerDetailForm.jsp"><forward name="success"

path="ThankYou.jsp"redirect=”true”/>

14

<forward name="failure" path="Failure.jsp" /></action>

Pasul 2. RquestProcesor-ul cauta in fisierul de configurare URL-ul care respecta paternul /submitDetailForm (calea URL-ului fara sufixul .do), si va gasi ActionMapping-ul exemplificat mai sus. Atributul type indica ce clasa Action urmeaza a fi instantiata. Blocul XML mai contine si alte atribute, care impreuna constituie proprietatile instantei de ActionMapping pentru calea /submitDetailForm.

1.10.3. ActionForm

Alt atribut important din ActionMapping il reprezinta atributul name. Valoarea atributului name este numele logic al obiectului ActionForm care urmeaza a fi populat de RequestProcessor. Dupa ce selecteaza ActionMapping-ul RequestProcessor-ul instantiaza ActionForm-ul. Pentru a instantia ActionForm-ul RequestProcessor-ul trebuie sa cunoasca, clasa din care face parte ActionForm-ul. Mumele complet al acesteoi clase este declarat tot in fiser-ul de configurare intr-un bloc de forma:

<form-bean name="CustomerForm"type="mybank.example.CustomerForm"/>

Elementul <form-bean> asociaza numele logic CustomerForm, cu clasa mybank.example.CustomerForm.

Pasul 3:RequesteProcessor-ul instantiaza CustomerForm-ul si il pune in scopul potrivit, request sau session. RequestProcessor-ul determina scopul potrivit cautand valoarea atributului scope din ActionMapping.

Pasul 4:Mai departe RequestProcessor-ul itereaza parametri cererii HTTP si populeaza proprietatile din CustomerForm, proprietati care au acelasi nume cu numele atributelor din cererea HTTP, utilizand Java Introspection. (Java Introspection reprezinta o forma generala de Java Reflection utilizand JavaBeans, care in loc sa foloseasca direct reflection pentru a seta valorile atributelor, se foloseste de metodele seter pentru a seta valorile, si de cele getter pentru a afla valorile atributelor).

Pasul 5:In continuare RequestProcesor-ul verifca atributul validate din ActionMapping. Daca acest atribut are valoare true atunci RequestProcesor-ul invoca metoda validate() din obiectul CustomerForm instantiat. In aceasta metoda puteti pune toate validarile pentru campurile unui form HTML. Vom presupune ca

15

deocamdata nu exista erori de validare pentru a continua explicatia diagramei de secventa si vom reveni ulterior la cazul in care exista erori de validare.

1.10.4. Action

Pasul 6:RequestProcessor-ul instantiaza clasa action specificata in ActionMapping (CustomerAction) si invoca metoda execute() a aceste instante. Signatura metodei execute este urmatoarea.

public ActionForward execute(ActionMapping mapping,ActionForm form,HttpServletRequest request,HttpServletResponse response) throws Exception

In afara de HttpServletRequest si HttpServletResponse in clasa Action mai este disponibil si ActionForm-ul. Scopul ActionForm-ului este acela de a pastra si transfera datele din parametrii cererii HTTP, catre alte componente ale controlerului pentru ca acesta sa nu fie nevoit sa le extraga de fiecare data din cererea HTTP.

Metoda execute() nu ar trebui sa contina business logic de baza, indiferent daca se utilizeaza sau nu EJB-uri sau alte frameworkuri pentru partea de business logic, deoarece astfel se creaza dependente fata de controlere si se reduce reuzabilitatea partii de busniess logic folosita in aplicatie.

Un alt motiv pentru care se recomanda a nu se utiliza business logic in clasele Action este acela ca, daca doriti sa inlocuiti framework-ul Struts cu un alt framework, va trebui sa adaptati partea de business logic aflata in clasele Action. Metoda execute() ar trebui sa contina numai logca de prezentare si invocari de metode business logic, apartinand altor clase independente de framework, sau metode ale EJB-urilor.

RequestProcessor-ul creaza o instanta a unei actiuni daca nu exista alta instanta creata.In aplicatie exista doar o instanta a unei clase Action. Din aceasta cauza trebuie sa va asigurati ca aceasta clasa si atributele sale, daca esista, sunt thread safe. Regulile generale care se aplica la servleti sunt valabile si aici. Clasa Action nu ar trebui sa contina nici un atribut care se poate modifca , in metoda execute().

1.10.5. ActionForward

Metoda execute returneaza urmatorul view care va trebui sa fie afisat utilizatorului. ActionForward-ul este clasa care contine informatiile despre urmatorul view care trebuie afisat. Frameworkul Struts nu incurajeaza folosirea numelui real al paginilor JSP la crearea ActionForward-ului care trebuie returnat, ci folosirea unui nume logic pentru pagina JSP propriuzisa. Asocierea dintre

16

numele logic al paginii si pagina propriuzisa este stocata in ActionForward-ul returnat de catre metoda execute. ActionForward-ul poate fi global sau local. Revenind la ActionMappingul exemplificat mai sus putem observa ca el contine elemente numite <forward> care pot avea trei atribute – name, path si redirect.

Atributul name reprezinta numele logic al paginii propriuzise, pagina a carei cale este specificate in atributul path. Aceste elemente <forward> sunt relative la ActionMapping-ul exemplificate mai sus si ele nu pot fi folosite decat in metoda execute() a clasei CustomerAction. Pe de alta parte, atunci cand forward-urile sunt declarate in sectiunea <global-forwards> a fisierului de configurare struts-config.xml, ele sunt disponibile pentru orice ActionMapping.

In ambele cazuri, metoda findForward() a instantei ActionMaping extrage ActionForward-ul dupa cum urmeaza.

ActionForward forward = mapping.findForward(“success”);

Numele logic al paginii (success) este transmis ca parametru metodei findForward(). Metoda findForward() cauta un forward cu numele “success” in ActionMapping iar apoi, in cazul in care nu gaseste nici un forward cu acest nume, cauta in sectiunea <global-forwards>.

Metoda execute a Action-ului returneaza ActionForward-ul si RequestProcessor-ul returneaza utilizatorului pagina JSP propriuzisa. In termeni J2EE aceasta operatie este cunoscuta sub numele de expediere a view-ului la utilizator. Aceasta expediere poate fi HTTP Forward sau HTTP Redirect.

De exemplu expedierea spre pagina “success” este HTTP Redirect iar expedierea spre pagina “failure” este HTTP Forward.

17

Diferenta dintre HTTP Forward si HTTP Redirect

HTTP Forward reprezinta procesul de afisare a unei pagini atunci cand este ceruta de catre utilizator.Utilizatorul cere o resursa (pagina) apasand pe un link sau facand submit la un form si pagina urmatoare ii este afisata ca raspuns. In containerul servlet, HTTP Forwad-ul se face apeland urmatoarea secventa:

RequestDispatcher dispatcher =httpServletRequest.getRequestDispatcher(url);

Dispatcher.forward(httpServletRequest, httpServletResponse);

HTTP Redirect e un pic mai sofisticat. Cand un utilizator cere o resursa, ii este trimis inapoi un raspuns. Aceste raspuns nu este resursa ceruta. In schimb este un raspuns care are codul HTTP “302” si contine URL-ul resursei cerute. Acest URL poate fi acelasi sau poate fi diferit de URL-ul cerut initial. Browser-ul client face apoi automat inca o cerere cu noul URL, si de aceasta data utilizatorul va primi ca raspuns resursa ceruta. Pe partea de web HTTP Redirect-ul se poate face apeland metoda sendRedirect() a instantei HttpServletResponse, restul procesului fiind facut de catre HTTP. HTTP Redirect-ul face o itoarcere suplimentara la client si este folosit numai in cazuri speciale.

1.10.6. ActionErrors si ActionError

Pana acum am vazut ce se intampla cu o cerere in Struts din momentul cand utilizatorul face submit la un formular HTML pana in momentul cand ii este afisata urmatoarea pagina. Dar ce se intampla daca utilizatorul introduce date gresite sau nu introduce datele necesare deloc? Programatorul trebuie sa previna acest lucru, inainte ca datele sa ajunga in partea de business logic sau inainte ca baza de date sa semnaleze ca unele campuri nu pot avea valori nule, din doua cauze.

1. Deoarece sunt folosite de mai multi utilizatori, resursele si timpul de acces la server ar trebui economisite. A cheltui prea multe resurse si timp de acces pentru o cerere care stim ca poate esua, reprezinta o exploatare neechilibrata a resurselor serverului.

2. Are un impact negativ asupra calitatii codului. Din moment ce se stie ca atributele unei crereri pot fi incorecte, aceste trebuie verificate si trebuiesc aruncate exceptii peste tot in cod. In general codul business logic este destul de complicate si contine destule blocuri if-else. Mai multe blocuri if-else pentru verificarea atributelor cu valori nule ar insemna un cod dezorganizat si intretinerea lui ar fi un cosmar. Daca aceste validari s-ar

18

putea face cat mai aproape de partea de utilizator atunci restul codului are avea de a face cu partea de business logic si nu cu verificarea validitatii datelor.

Struts pune la dispozitie in clasa ActionForm, metoda validate() pentru validarea datelor venite de la utilizator. Cum se poate observa si in diagrama de secventa, metoda validate() este apelata dupa ce atributele ActionForm-ului sunt populate cu datele de la utilizator. In metoda validate exemplificata mai sus se poate observa ca este instantiat un obiect ActionErrors. Toate verificarile de erori se fac cu blocuri if-else obisnuite. Daca exista erori atunci va fi creat un obiect ActionError pentru campul care a fost validat, care va fi adaugat la obiectul ActionErrors creat anterior.

ActionErrors este ca un Map pentru obiectele ActionError. Se pot asocia unul sau mai multe obiecte ActionError pentru fiecare cheie. Numele campului din formular este ales in general ca si cheie si poate avea asociate mai multe obiecte ActionError. ActionError-ul poate fi asociat cu un camp dintr-un formular sau el poate fi global pentru intregul formular. Cand eroarea este specifica unui camp numele campului este folosit ca si cheie in ActionErrors. Cand eroarea este una globala (pentru intreg formularul) cheia din ActionErrors este intotdeauna GLOBAL_ERRORS. In metoda exemplificata mai sus sunt exemplificate amandoua cazurile. Se mai poate observa cum constructorul ActionError-ului primeste ca argument o cheie, mai degraba decat un mesaj. Acesta cheie este declarata intr-un fiser de proprietati si valoarea ei este mesajul de eroare propriuzis. Fiserul de proprietati este ales in functie de Locale-le utilizatorului. Termenul tehnic pentru acest fiser de proprietati in care sunt stocate mesajele este Message Resource Bundle si se bazeaza pe conceptul Java de Localizare utilizand java.util.ResourceBundle. Fisierul de proprietati mai are si alte scopuri decat localizare mesajelor. Ele permite modificarea mesajelor fara a recompila codul si acest lucru usureaza intretinerea codului. Un mesaj I interiorul

Metoda validate din clasa CustomerFormpublic ActionErrors validate(ActionMapping mapping,

HttpServletRequest request){

// Perform validator framework validationsActionErrors errors = super.validate(mapping,

request);// Only need crossfield validations hereif (parent == null) {

errors.add(GLOBAL_ERROR,new ActionError("error.custform"));

}if (firstName == null) {

errors.add("firstName",new ActionError("error.firstName.null"));}

return errors;}

19

fiserului de proprietati arata astfel: error.firstName.null=First Name cannot be null

RequestProcessor-ul opreste executia procesarii carerii cand primeste obiecte ActionErrors sau ActionError. Astfel instanta Action nu mai primeste controlul si in consecinta nu reuseste sa returneze un ActionForward. RequestProcessor-ul consulta ActionMapping-ul ca sa gaseasca pagina ce trebuie afisata in continuare. ActionMapping-ul are un atribut numit input care specifica pagina ce trebuie afisata in caz de eroare. In general aceasta pagina este pagina cu formularul, din moment ce utilizatorul ar dori sa corecteze erorile si sa faca submit din nou.

1.10.7. Fisierul de configurare Struts – struts-config.xml

Fisierul de configurare Struts adera la struts_config_1_1.dtd (dtd - document type definition). In fisierul struts_config_1_1.dtd sunt definite toate elementele care pot fi folosite in fiserul de configurare Struts, precum si atributele si descrierile lor.

Cele mai importante sectiuni din fisierul de configurare Struts sunt:

1. Sectiunea de definitii pentru Form bean-uri2. Sectiunea de definitii pentru Global forward-uri3. Sectiunea de definitii pentru Action mapping-uri4. Sectiunea de configurare a controller-ului5. Sectiunea de definitii pentru Aplication Resource-uri

Sectiunea de definitii pentru form bean-uri contine unua sau mai multe intrari pentru fiecare ActionForm. Fiecare form bean este unic identificat printr-un nume logic. Atributul type reprezinta numele complet al clasei ActionForm. O calasa ActionForm poate fi declarata pentru mai multe form bean-uri atata timp cat numle form bean-ului este unic. Aceasta proprietate este folositoare atunci cand se doreste stocarea mai multor form-uri de acelasi tip in sesiunea servlet-ului.

Tabelul 2.1: Cele mai importante atribute si elemente ale unui ActionMapping:

Atribut / Nume Element

Descriere

Path URL-ul (calea completa sau sufixul) pentru care acest action mapping este utilizat

Type Numele complet al clasei Action pentru acest ActionMapping

Name Numele logic al form bean-ului. ActionForm-ul propriuzis asociat cu acest ActionMapping este gasit cautand in sectiunea de definitii pentru form bean-uri, o definitie care are ca nume, acest nume logic. Acesta spune aplicatiei Struts ce ActionForm ar trebui sa foloseasca un

20

ActionMapping.Scope Scopul in care va fi stocat form bean-ul. Acesta poate fi

session sau request.Validate Poate avea ca valori “true” sau “false”. Cand valoarea este

true, form bean-ul este validat cand este submis. Cand valoarea este “false” se trece peste validare.

Input O pagina fizica sau alt ActionMapping spre care controlul va fi innaintat cand exista erori de validare in form bean

Forward O pagina fizica sau alt ActionMapping spre care controlul va fi innaintat cand action forward-ul cu acest nume este selectat in metoda execute a clasei Action.

Sectiunea de ActionMapping defineste legatura de la un URL la o clasa Action. Atributul type reprezinta numele complet al clasei Action. Atributul path trebuie sa fie unic deoarece in Struts nu exista posibilitatea de a asocia mai multe Action-uri cu acelasi path. Atributul name reprezinta numele Form bean-ului asociat cu acest Action. O descriere mai amnuntita a atributelor unui element action din ActionMapping se gaseste in tabelul 2.1.

In fisierul de configurare exemplificat mai jos, in definitia unui ActionMapping exista doua elemente forward. Aceste elemente sunt forward-uri locale ceea ce inseamna ca ele pot fi accesate doar in interiorul ActionMapping-ului. Pe de alta parte forward-urile definite in sectiunea Globa Forwards, sunt accesibile din orice ActionMapping. Dupa cum ati vazut mai devreme, un forward are poate avea ca atribute, name si path. Atributul name reprezinta numele logic al forward-ului iar atributul path este resursa catre care va fi inaintat controlul. Aceasta resursa poate fi o pagina ca in

<forward name="logon" path="/logon.jsp"/>sau poate fi alt ActionMapping ca in

<forward name="logoff" path="/logoff.do "/>./logoff reprezinta alt ActionMapping din struts-config.xml. Forward-ul – global sau local – este utilizat in metoda execute() a unei clase Action pentru a inainta controlul catre alta pagina fizica sau ActionMapping.

Sectiunea controller este optionala in fiserul de configurare. Daca nu este specificat alt controler, controler-ul default utilizat este org.apache.struts.action.RequestProcessor. Exista cazuri in care acesta trebuie inlocuit sau extins pentru a avea un processor de cereri specializat. De exemplu cand se utilizeaza Tiles (framework pentru template-uri) alaturi de Struts, se urilizeaza TilesRequestProcessor.

21

Exemplu de fisier de configurare Struts care include cele mai importante sectiuni.

<?xml version="1.0" encoding="ISO-8859-1" ?><!DOCTYPE struts-config PUBLIC"-//Apache Software Foundation//DTD Struts Configuration1.1//EN""http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>

Form bean Definitions <form-beans> <form-bean name="CustomerForm" type="mybank.example.CustomerForm"/> <form-bean name="LogonForm"

type="mybank.example.LogonForm"/> </form-beans>

Global Forward Definitions <global-forwards> <forward name="logon" path="/logon.jsp"/> <forward name="logoff" path="/logoff.do"/> </global-forwards>

Action Mappings <action-mappings> <action path="/submitDetailForm" type="mybank.example.CustomerAction"

name="CustomerForm" scope="request" validate="true" input="/CustomerDetailForm.jsp"> <forward name="success" path="/ThankYou.jsp" redirect=”true” /> <forward name="failure" path="/Failure.jsp" /></action><action path=”/logoff” parameter=”/logoff.jsp” type=”org.apache.struts.action.ForwardAction” />

</action-mappings>

Controller Configuration <controller processorClass="org.apache.struts.action.RequestProcessor"/>

Message Resource Definition <message-resources parameter="mybank.ApplicationResources"/></struts-config>

22

Cand am vorbit despre ActionError, am amintit despre o cheie criptica, a carei valoare se afla intr-un fisier de proprietati.Acest fisier de proprietati este declarat in fiserul de configurare Struts, in sectiunea MessageResources. In fisierul exemplificat putem observa ca fisierul de proprietati al aplicatiei se numeste ApplicationResources.properties si este situat in pachetul mybank.

Componente pe partea de View

In Struts componentele pe partea de view sunt compuse din sase librarii de taguri specializate utilizate in JSP-uri – HTML, Logic, Bean, Nested, Template si Tiles. Fiecare dintre aceste librarii are un scop anume si ele pot fi utilizate singure sau in combinatie cu alte librarii.

Stim deja ca ActionForm-ul este populat de catre RequestProcessor folosind Java Introspection. In aceasta parte vom vedea cum tagurile Struts interactioneaza cu controller-ul si clasele ajutatoare, ca sa afiseze JSP-urile.

Ce sunt tagurile specializate?

Tagurile specializate sunt clase Java scrise de programatori Java si pot fi utilizate in paginile JSP prin intermediul limajului de mrkup XML.Putem sa ne gandim la ele ca la niste bean-uri ajutatoare ce pot fi utilizate fara a fi nevoie de scriptleti. Scriptletii sunt secvente de cod java amestecate cu taguri JSP. Pentru a scrie scriptleti este nevoie de dezvoltatori Java, dar paginile JSP sunt in general scrise de autori de pagini, care nu stiu sa interpreteze scriptletii. Utilizarea scrptletilor poate crea probleme si in definirea rolurilor intr-un proiect. Tagurile specializate reprezinta rezolvarea acestor probleme ele fiind bazate pe markup XML, si putand fi usor de utilizat de catre autorii de pagini.

Cum functioneaza tag-ul Form?

Un formular Html poate fi creat in Struts utilizand tagul <html:form/> care este reprezentat in Java de clasa org.apache.struts.taglib.html.FormTag, el fiind un tag cu corp (body). Tagul <html:text> este reprezentat de clasa org.apache.struts.taglib.html.TextTag si spre deosebire de <html:form/> el este un tag normal, fara corp.

JSP-ul :

<html><head> <html:base/>

23

</head><body> <html:form action="/submitDetailForm"> <html:text property="firstName" /> <html:text property="lastName" /> <html:submit>Continue</html:submit> </html:form></body>

</html>Va avea ca rezultat in HTML urmatoarea secventa:

<html><head> <html:base/></head><body> <form name=”CustomerForm” action=”/submitDetailForm.do”> <input type=”text” name=”firstName” value=”” /> <input type=”text” name=”lastName” value=”” /> <input type=”submit” name=”Submit” value=”” /> </form></body>

</html>

Tagul FormTag poate contine alte tag-uri in corpul lui. Tagul SubmitTag va genera la runtime un buton de submit. Tagul <html:text> va genera la runtime un textbox Html. Tagul FormTag are un atribut numit action, a carei valoare reprezinta un ActionMapping.

Containerul Servlet parseaza JSP-ul si genreaza pagina HTML. Cand containerul intalneste tagul FormTag, el apeleaza metoda doStartTag() a acestuia. Metoda doStartTag() din FormTag face exact ce face RequestProcessor-ul in metoda execute().

In exemplul de mai sus avem urmatoarele:

1. Tagul FormTag cauta un ActionMapping cu valoarea atributului path egala cu /submitDetailForm

2. Cand gaseste ActionMapping-ul, el cauta un ActionForm cu numele CustomerForm, (pe care il va lua din ActionMapping) in unul din scopurile request sau sesiune (pe care il va lua deasemenea din ActionMapping).

3. Daca gaseste un obiect ActionForm deja creat il foloseste iar daca nu gaseste, va crea unul in scopul corespunzator facand disponibil numele formului in contextul paginii.

4. Tagurile pentru campurile form-ului (TextTag) acceseaza ActionForm-ul dupa numele din contextul paginii, si extrag atributele care au acelasi nume cu numele campului. De exemplu tagul TextTag <html:text property=”firstName”/> va extrage valoarea atributului firstName

24

din mybank.example.CustomerForm si o va inlocui in atributul value.Daca CustomerForm ar exista in unul din scopurile request sau session, si atributul firstName ar avea valoarea “John”, atunci TextTag-ul ar genera un HTML care arata astfel :<input name=firstName” type=”text” value=”John” />Daca atributul firstName ar fi fost gol sau null in obiectul CustomerForm atunci HTML ul ar fi aratat astfel:<input name=firstName” type=”text” value=”” />

In acest fel se face afisarea unui form HTML cu ajutorul tagului specializat <html:form/>. Pentru afisarea de informatii ce trebuiesc editate ActionForm-ul ar trebui pus la dispozitie inainte de a afisa pagina. Altfel FormTag-ul creaza un ActionForm nou fara nici o data. Al doilea caz este potrivit in cazul formularelor de creare de date noi.

2.10.8.2. Cum functioneaza tag-ul Errors?

Cand avem de a face cu obiecte de tipul ActionErrors, am invatat ca erorile de validare dintr-un ActionForm sunt raportate framework-ului prin intermediul unui container ActionErrors.

Facilitatile oferite de Struts pentru afisarea erorilor pe parte de JSP sunt tagurile Errors. Cand ActionForm-ul returneaza un obiect ActionErrors, RequestProcessor-ul il seteaza in scopul request sub un nume predefinit dupa care genereaza pagina de intrare. Tagul ErrorsTag itereaza continutul obiectului ActionErrors din request, si afiseaza in HTML toate erorile cotinute in acesta.

Tagul Errors se poate adauga in JSP prin intermediul lui <html:errors>. Acest tag nu are nici un atribut, si de asemenea nu are corp. El va afisa erorile exact unde se afla tagul in pagina.

Componentele de pe partea de view au fost ultimele ce trebuiau descrise. Dupa cum am aratat, toata treaba in Struts este facuta de partea de controller a framework-ului. Tagurile de view cauta informatii in scopul request sau session, si il afiseaza sub forma de HTML. Astfel partea de view ramane asa cum ar trebui sa fie: cat mai simpla si mai eleganta.

25