Tehnologia JSP

Tehnologia JSP
Java Server Pages este o simpla dar puternica tehnologie folosita pe partea de server pentru a genera continut HTML dinamic. JSP este o extensie directa a Java Servlets si furnizeaza o modalitate de a separa partea de procesare de cea de prezentare. Motorul JSP este doar un alt Servlet, mapat la extensia *.jsp. O pagina JSP este un document bazat pe text care descrie cum se va procesa o cerere ( request) pentru a crea un raspuns (response). Sunt amestecate date sablon (template data) cu anumite actiuni dinamice si mecanisme din cadrul platformei Java. In continuare se prezinta un fisier simplu JSP:
<HTML> <BODY> <% out.println("HELLO JSP WORLD"); %> </BODY> </HTML>

Paginile JSP sunt create sa suporte mai multe tipuri de documente structurate, ndeosebi HTML si XML. n general, JSP-urile folosesc anumite informatii pe care le trimit la server ntr-o cerere HTTP care interactioneaza cu datele existente pe acesta si creaza dinamic un raspuns organizat ntr-un format standard (HTML, DHTML, XML, etc.) sau ntrun format text sau neorganizat ce va fi trimis napoi clientului. O aplicatie Web are la baza: Java Runtime Environment, ce va rula obligatoriu pe server JSP page, care preia cererile si genereaza un continut dinamic Java Servlets, cu acelasi rol ca si JSP JavaBeans, componenta server-side care ncapsuleaza comportamente si stari pagini statice HTML, XML, DHTML,. Java Applets sau JavaBeans, componente client-side si eventual alte fisiere Java de tipclass Java Runtime Environment care sa ruleze pe client si care sa poata fi ncarcate prin plug-in
Java Server Pages mostenesc de la Servlets concepte despre Applications, ServletContexts, Sessions, Requests si Responses. Paginile JSP sunt unice prin faptul ca ele pot contine att continut ct si cod de reprezentare. Astfel ofera o multitudine de optiuni n proiectarea de aplicatii usor de ntretinut si extins. Optiunile disponibile pentru ntreteserea continutului cu codul, includ componente JavaBeans, tag-uri personalizate si scriplets.
3.3.1. Directive
Directivele sunt elemente JSP care furnizeaza informatii globale despre pagina JSP. Ele au urmatoarea sintaxa:
<%@ directive %>

n exemplul de mai sus se specifica asignarea valorii value ca si atribut. O directiva poate contine n optiuni ale perechilor atribut/valoare. La momentul potrivit veti observa utilitatea acestor directive. Exista trei directive, diferite de specificatiile JSP: page, include si taglib.
3.3.1.1. Directiva page

Aceasta directiva defineste informatii disponibile global pentru JSP. n cele ce urmeaza vom aminti cteva setari care vor afecta direct compilarea unei pagini JSP :
-language="scriptingLanguage" - atribut care spune serverului ce limbaj sa foloseasca la compilare. -extends="className" atribut care defineste clasa de baza a serverului generat. -import="importList" atribut care defineste o lista de pachete disponibile JSP-ului. -session="true|false" - atribut care defineste disponibilitatea datelor de sesiune n cadrul paginii. -buffer="none|size in kb" - determina daca stream-ul de scriere ( OutputStream) este sub forma de buffer. -autoFlush="true|false" determina daca stream-ul amintit mai sus va fi golit automat. -isThreadSafe="true|false" - specifica daca motorul JSP poate raspunde la mai mult de o cerere la un moment dat. - info="text" - specifica daca pagina JSP poate fi accesata de metoda getServlet a servletului generat. -errorPage="error_url" URL-ul relativ catre pagina JSP care prinde exceptiile. -isErrorPage="true|false" specifica daca pagina JSP este o pagina de eroare. -contentType="ctinfo" - reprezinta tipul MIME si setul de caractere de raspuns.
3.3.1.2. Directiva include

Directiva include este folosita pentru nserare de cod si text . Are urmatoarea sintaxa:
<%@ include file="relativeURLspec" %>

De obicei fisierul spre care se face referire este fie un fisier text, fie unul HTML, dar nu este exclus sa fie chiar o sursa JSP.
3.3.1.3. Directiva taglib

JSP prezinta un mecanism de extindere a setului curent de tag-uri JSP care se realizeaza prin crearea unei bilbioteci de tag-uri, taglib. Se specifica astfel faptul ca o pagina foloseste tag-uri particularizate, unice prin nume si asociaza prefixul tag pentru distingerea lor n utilizare. Sintaxa arata astfel:
<%@ taglib uri="tagLibraryURI" prefix="tagPrefix" %>

uri: referentiaza un URI care n mod unic numeste prefix: defineste prefixul folosit pentru a distinge o instanta a tag-ului particularizat. un set de taguri.
3.3.1.4. Actiuni
Actiunile furnizeaza o abstractizare folosita usor pentru a ncapsula diferite task-uri. Ele creaza obiecte de tip JavaBeans si actioneaza asupra lor. Tehnologia JSP suporta cteva actiuni standard: <jsp:useBean> instantiaza un obiect de tip JavaBean avnd un scop dat si un id <jsp:setProperty> seteaza valoarea unei proprietati a Bean-ului <jsp:getProperty> preia valoarea proprietatii unei instante a unui Bean, o converteste ntrun String pregatind-o pentru afisare <jsp:include> furnizeaza un mecanism pentru a include resurse statice si dinamice n pagina JSP curenta. Are sintaxa:
<jsp:include page="urlSpec" flush="true" />
sau
<jsp:include page="urlSpec" flush="true"> </jsp:include>

<jsp:forward> permite ca un motor JSP sa comunice runtime, cererea curenta catre o resursa statica, Servlet sau alt JSP. Actiunea se termina efectiv cnd se termina executia paginii curente. Are sintaxa:
<jsp:forward page="relativeURLspec" />

sau
<jsp:forward page=relativeURLspec"> </jsp:forward>

<jsp:plugin> face posibila generarea unei pagini HTML care contine constructii dependente de browser, de exemplu, OBJECT sau EMBED, care va rezulta n download-ul unui plug-in Java si n executia subsecventiala a appletului specificat sau a componentei JavaBeans. Exista posibilitatea nlocuirii tag-ului <jsp:plugin> de un tag <object> sau <embed>, n functie de cerere, si noul tag este trimis ca raspuns. Atributele actiunii <jsp:plugin> furnizeaza date de configurare pentru prezentarea elementului. Are sintaxa:
<jsp:plugin type="pluginType" code="classFile" codebase="relativeURLpath"> <jsp:params> ... </jsp:params> </jsp:plugin>
Un exemplu simplu de pagina JSP care combina Script HTML si Beans este cel de mai jos, care afiseaza numele de login al clientului cnd acesta solicita o pagina prin intermediul unui form HTML:
Pagina contine comenzi sablon, ntlnite n orice pagina HTML si cteva elemente JSP, subliniate. Raspunsul este creat pe baza comenzilor HTML. Cnd s-a ajuns la primul element JSP este creat un obiect server-side Bean cu numele 'login' de tip 'Profi.Login'. Acest obiect va putea fi folosit si utilizat mai tirziu n pagina. Urmatoarele doua elemente JSP acceseaza proprietatile obiectului si nsereaza aceste valori n pagina response ca String.
3.3.2. Semantica JSP

3.3.2.1. Interpretarea si executia paginilor JSP
O pagina JSP este executata ntr-un container JSP ( JSP container), instalat pe un server Web. Acesta preia cererile de la client si le livreaza paginii JSP, returnnd rezultatele. Structura semantica a JSP-ului este aceeasi ca si la servleti, prin descrierea modului de creare a obiectul raspuns pornind de la un obiect cerere, pentru un anumit protocol dat, cu posibilitatea folosirii unor alte obiecte deja create. Toate containerele JSP trebuie sa suporte protocolul HTTP, ca si protocol cerere/raspuns. Un container JSP poate sa suporte si alte protocoale. Obiecte cerere/raspuns implicite sunt de tip HttpServletRequest si HttpServletResponse. De asemenea o pagina poate sa indice cum se trateaza anumite evenimente, de exemplu, JSP 1.1 poate doar sa initializeze si sa distruga un event. O pagina JSP este reprezentata de o JSP page implementation class care implementeaza interfata javax.servlet.Servlet. De multe ori paginile JSP sunt implementate folosind JSP translation phase care se poate utiliza o singura data, urmata de un request processing phase, care se foloseste o singura data pe cerere. O pagina va contine cteva declaratii, comenzi standard ( fixed template), actiuni (action instances) cel mai frecvent ncuibarite si elemente script. Cnd o cerere este livrata paginii, toate aceste elemente sunt folosite ca sa creeze obiectul raspuns ce se returneaza clientului. O pagina JSP descrie etapele de creare a unui obiect reponse pe baza unui obiect request pentru un protocol dat, cu posibilitatea crearii si/sau utilizarii altor obiecte. O pagina JSP este executata de un container JSP; cererile trimise paginii sunt livrate de catre container unei JSP page implementation care este o subclasa de Servlet. O aplicatie Web este o colectie de resurse disponibile prin intermediul unor URL-uri. Aceste resurse includ pagini JSP, Java Servlets, pagini statice si alte resurse sau clase bazate pe tehnologia Java folosite de componentele serverside. Pe lnga acestea exista si clase (cum ar fi applet-uri Java, componente JavaBeans) ce pot fi folosite de client prin download. O aplicatie Web are o descriere a desfasurarii ( deployment descriptor) web.xml care contine informatii despre JSP, Servleti si alte resurse folosite de catre aceasta. n utilizarea JSP 1.1 este obligatoriu ca toate aceste resurse sa fie asociate implicit cu o instanta unica ServletContext si accesibile prin aceasta. Instanta este disponibila ca obiect implicit application. JSP mosteneste notiuni despre aplicatiile Web de la Servlet 2.2. Aplicatia careia i apartine pagina JSP este reflectata n obiectul application si are influenta n semantica elementelor ca si instructiunea include, actiunea jsp:include, sau actiunea jsp:forward. Un container JSP este o entitate la nivel de sistem care permite managementul rularii programului si suport pentru componentele JSP si Servlet. O componenta Web este fie un Servlet, fie o pagina JSP. Aceasta componenta poate folosi serviciile propriului container. Elementul servlet web.xml este folosit pentru a descrie ambele tipuri de componente web. Majoritatea componentelor de tip pagina JSP sunt definite implicit n descriptorul desfasurarii programului, prin folosirea unei extensii implicite .jsp. O clasa JSP page implementation defineste o metoda jspService() care mapeaza cererea n obiect de tip response. Detaliile acestei transformari sunt specifice fiecarui limbaj, dar n cazul nostru sunt tratate doar cele generale. Aproape tot continutul paginii JSP este dedicat descrierii datelor ce vor fi puse n stream-ul de scriere, returnat clientului. Descrierea este bazata pe un obiect JspWriter, out. Acesta poate avea mai multe valori, initial, out este un nou obiect JspWriter. Acesta poate fi diferit de stream-ul obtinut prin apelul metodei response.getWriter() si este obiectul initial de iesire. n interiorul unor anumite actiuni, out poate fi temporar realocat pentru o alta instanta a obiectului JspWriter, ncuibarita. De obicei, continutul sau rezultatul procesarii continutului acestor stream-uri temporare este adaugat streamului out apoi reasignat. Unele stream-uri ncuibarite sunt puse ntr-un buffer si necesita o creare explicita pentru a returna continutul lor. Daca obiectul initial de iesire JspWriter este ntr-un buffer, atunci n functie de valoarea atributului autoFlush din instructiunile paginii, continutul buffer-ului va fi automat transferat n stream-ul de scriere ServletResponse sau este lansata o exceptie buffer overflow. Daca JspWriter nu este ntr-un buffer, continutul sau va fi trecut direct n stream-ul de scriere. Instructiuni (directive) Instructiunile sunt mesaje destinate containerul JSP. In JSP 1.1 acestea au urmatoarea sintaxa:
<%@ directive *%>

ntre "<%@" si "*%>" pot exista spatii libere fara sa apara nici un fel de probleme. Singurul necaz este acela ca aceasta sintaxa nu este compatibila XML, pentru rezolvare trebuind sa se faca o mapare a comenzilor. Instructiunile nu returneaza nimic n stream-ul de scriere curent.
Instructiunea page defineste un anumit numar de atribute dependente de pagina si le comunica containerului. O unitate de interpretare (un fisier sursa si orice alte fisiere incluse cu instructiunea include) poate contine mai multe comenzi page, atributele lor aplicndu-se apoi unitatii. Ideal, ar trebui sa existe o singura aparitie a fiecarui atribut/valoare definit de aceasta comanda cu exceptia atributului import. Atributele/valorile nerecunoscute sau repetate pot genera erori de interpretare. Iata cteva detalii despre atribute : language: defineste limbajul utilizat n scriptlets, expresii scriptlets si declaratii cuprinse n interiorul unitatii de interpretare (pagina JSP si orice alt fisier inclus prin comanda include). Este prezentata doar semantica scripturilor pentru valoarea "java" a acestui atribut, aceasta fiind singura definita si necesara n JSP 1.1. Versiuni ulterioare JSP specifications vor defini si alte valori ale acestui atribut, dar pna atunci ntlnirea unei alte valori este considerata eroare de interpretare. extends: valoarea lui este un nume de clasa Java care defineste superclasa din care este derivata pagina JSP. Acestui atribut trebuie sa i se acorde atentie deoarece prin limitarea capacitatii containerului JSP trebuie sa se furnizeze superclase specializate, fapt care poate mbunatatii calitatea serviciilor. import: valoarea lui este o declaratie de import din limbajul Java, n care pot exista mai multi parametrii separati prin virgula. Daca parametrul este un pachet de clase Java, trebuie urmat de ".*". Lista de import implicita este: java.lang.*, javax.servlet.*, javax.servlet.jsp.*, javax.servlet.http.* . aceasta lista este valabila doar cnd language are ca parametru java. session: indica faptul ca pagina implica prezenta unei sesiuni http. Daca valoarea este "true", atunci implicit variabila "session" de tipuljavax.servlet.http.HttpSession este o sesiune curenta/noua pentru pagina. Daca este "false" atunci pagina nu participa la sesiunea respectiva, variabila " session" nu este definita si orice referire la aceasta este considerata eroare. Valoarea implicita este "true". buffer: specifica modelul buffer-ului pentru iesirea initiala out pentru a prelua continutul de iesire din pagina. Daca e "none", iesirea este trimisa direct prin ServletResponse PrintWriter. Daca este specificata o valoare n kb, iesirea este pusa ntr-un buffer de dimensiune data. n functie de valoarea atributului " autoFlush", la umplerea buffer-ului continutul sau este automat afisat sau se lanseaza o exceptie. Valoarea implicita a bufferului este de 8k. autoFlush: pentru valoarea "true", la umplerea buffer-ului continutul este golit automat iar pentru "false" se lanseaza o exceptie. Valoarea implicita este "true". Se interzice "false" pentru autoFush "buffer=none". isThreadSafe : indica nivelul de siguranta al thread-ului implementat n pagina. Daca avem "false", cererile clientilor vor fi procesate una dupa alta, n ordinea sosirii lor. Daca este "true", procesarea cererilor se poate face simultan, n acest caz fiind necesara sincronizarea accesului la pagina. Valoarea implicita este "true". info : este un sir de caractere ce poate fi ncorporat n pagina. Dupa implementarea paginii poate fi obtinut prin apelarea metodei Servlet.getServletInfo(). isErrorPage : este utilizat pentru a indica daca se intentioneaza ca pagina JSP curenta sa fie un URL target al unei errorPage din alta pagina. Pentru "true", variabila " exception" este definita si are ca si valoare o referinta la Throwable din pagina cu eroarea. Pentru "false", variabila " exception" nu este definita si orice referire la ea din corpul paginii este considerata eroare. Valoarea implicita este "false". errorPage : defineste un URL la o resursa la care orice obiect Throwable din Java lansat (nu si prins) de page implementation este trimis mai departe pentru partea de tratare a erorilor. Daca URL-ul face referire la o alta pagina, variabila exception trebuie sa contina o referinta la acel obiect Throwable care nu a fost prins. Nu exista un URL implicit, fiind dependent de implementare. Ramne de mentionat ca obiectul Throwable este transferat catre error page implementationprin salvarea referintei sale ntr-un obiect comun ServletRequest folosind metoda setAttribute() cu numele javax.servlet.jsp.jspException. contentType : defineste codarea caracterelor pentru pagina JSP si raspunsul returnat de aceasta. Continutul acestui atribut este de tipul "TYPE" sau "TYPE; charset=CHARSET". Valoarea implicita pentru TYPE este text/html, iar pentru codarea caracterelor este ISO-8859-1.
3.3.2.2. Compilarea JSP
Paginile JSP pot fi compilate n propriile clase JSP page implementation class, ceea ce permite folosirea mijloacelor puse la dispozitie de autori. Acest fapt are o serie de avantaje cum ar fi eliminarea ntirzierilor la receptionarea cererilor si reducerea numarului de pasi la pornirea unui container JSP. Daca o clasa JSP implementation class depinde de anumite clase aditionale pachetului oferit de JSP 1.1 si Servlet 2.2, acestea trebuie incluse n pachetul WAR (arhiva web), devenind astfel portabile n toate containerele JSP.
3.3.2.3. Obiecte si domenii de vizibilitate

O pagina JSP poate crea si/sau accesa anumite obiecte Java pentru a procesa o anumita cerere. Unele obiecte sunt create implicit, ca rezultat al unei instructiuni, iar altele explicit prin anumite actiuni. De asemenea, obiectele pot fi create direct, prin scrierea unui script. Odata creat, un obiect are un scope attribute care arata unde este referinta sa si cnd aceasta este stearsa. Obiectele pot fi accesibile script-ului prin intermediul unor variabile scripting-level, care vor fi descrise mai pe larg n sectiunea "Obiecte si variabile". Obiectele sunt ntotdeauna create n cadrul unei pagini JSP, care trebuie sa returneze un anumit obiect raspuns. Exista urmatoarele atribute de tip domeniu de vizibilitate ( scope) definite de JSP: page - obiectele sunt accesibile numai n cadrul paginii n care au fost create. Toate referintele la un astfel de obiect ar trebui eliberate dupa ce este formulat si trimis un raspuns. Referintele la aceste obiecte sunt stocate n obiectul pageContext. request - obiectele sunt accesibile din toate paginile care proceseaza aceeasi cerere unde au fost create. Referintele se gasesc n obiectul request, si trebuie eliberate dupa ce cererea a fost procesata; fac exceptie cererile transmise n cadrul executiei curente. session - obiectele sunt accesibile n toate paginile care proceseaza cereri din aceeasi sesiune cu cea n care au fost create. Referintele trebuie eliberate dupa ce sesiunea asociata se termina si sunt stocate n obiectul session, asociat cu activarea paginii. application - obiectele pot fi accesate din paginile care proceseaza cereri ce sunt n aceeasi aplicatie cu cea n care au fost create. Referintele se gasesc n obiectul application.
3.3.2.4. Instructiuni si actiuni

Elementele JSP pot fi de doua tipuri instructiuni si actiuni. Instructiunile furnizeaza informatii globale care sunt conceptual independente de orice cerere primita de JSP. Actiunile sunt dependente de detaliile fiec[rei cereri primite. Ele pot crea anumite obiecte si le pot face disponibile elementelor script prin variabile de tipul scripting-specific. Sintaxa actiunilor o urmeaza pe cea a elementelor XML, avnd un tag de start, un body si un tag de sfrsit:
<mytag attribute = "attribute value" .>

.body.
</mytag>
Sintaxa unei instructiuni:
<%@ directive .%>

Un element JSP contine un element type care descrie numele tag-ului, atributele valide si forma lui.
3.3.2.5. Script-uri
Elementele script sunt folosite pentru manipularea obiectelor. Sunt trei clase de elemente script: declarations, scriptlets si expressions. Primul tip de elemente pentru a declara constructori ai limbajului, valabili pentru toate celelalte elemente script, al doilea sunt fragmente din program care permit descrierea actiunilor ce preced returnarea unui raspuns, cum ar fi blocuri de executie conditionata, ciclari, etc., iar ultimul tip sunt expresii complete, evaluate doar la sfrsit, rezultatul lor fiind convertit ntr-un sir si inclus n stream-ul de scriere.
Containerele JSP asigura suport elementelor script bazate pe limbajul Java, care permit diferite operatii cum ar fi manipularea obiectelor Java, folosirea metodelor, tratarea exceptiilor, etc.
3.3.2.6. Obiecte si variabile

Un obiect poate fi accesibil elementelor script din cod printr-o variabila. Un element poate defini o variabila n doua locuri: imediat dupa tag-ul de start sau dupa ce a fost nchis cu tag-ul de sfirsit. Variabilele contin o referinta la obiectul definit de respectivul element, cu toate ca mai exista o referinta dependenta de domeniul de vizibiliate al obiectului. Mentionam faptul ca numele si tipul variabilei pot fi dependente de limbajul script folosit, acesta putnd influenta modul de expunere al caracteristicilor obiectului.
3.3.2.7. Script-uri, actiuni si elemente beans

Script-urile, actiunile si elementele beans reprezinta toate mecanismele care pot fi implementate pentru descrierea comportamentului dinamic al unei pagini JSP. Specificatiile JSP nu limiteaza folosirea acestora, lasnd programatorul sa le foloseasca n functie de aplicatia dorita. Exista anumite actiuni standard care sunt folosite n interactiunea cu orice Bean. Un Bean extins, implementnd interfata Tag, devine un tag handler si poate fi folosit direct n pagina.
3.3.3. Comparatie JSP - ASP

ntre cele dou tehnologii exist mai multe asemanari, dar si deosebiri majore. Nu se poate spune care dintre cele doua tehnologii este mai puternica fiecare are punctele sale forte dar si puncte vulnerabile. Punctele comune ar fi: ASP foloseste obiecte ActiveX pentru o mai mare functionalitate iar JSP foloseste JavaBeans Att ASP ct si JSP sunt limbaje interpretate, ASP-ul este convertit n Pcod iar JSP-ul n bytecode. ASP-ul permite crearea de functii separate de cod iar JSP-ul poate utiliza clase si variabile declarate extern
Exista si anumite deosebiri: ASP foloseste ca limbaj Visual Basic Script pe cnd JSP este focalizat pe Java ASP-ul este deja un produs inclus n Internet Information Server al firmei Microsoft pe cnd JSP este suportat de servere mult mai puternice
Ce are n plus JSP: Limbajul Java este mult mai puternic dect Visual Basic Script sau Java Script n aplicatiile client-server Obiectele ActiveX sunt disponibile numai pe platforme Windows, Java este independenta de platforma
Un important motiv pentru care JSP este recomandat este datorita faptului c ASP-ul a mostenit principiile conform carora o pagin web e plina de scripturi. Acest model a fost usor de nvatat si s-a raspndit cu mare usurinta. Odata cu trecerea timpului nsa, s-a nteles ca nu acesta este modul n care se pot realiza aplicatii mari. Cu acest mod de gndire nu se puteau realiza componente reutilizabile. Pentru a contracara aceste dezavantaje, si pentru a putea crea cu usurinta componente reutilizabile pentru aplicatii WWW, au fost introduse componentele JavaBeans. A fost, de altfel, doar o problem de timp pna cnd tehnologia axata pe componente a cstigat batalia n dezvoltarea aplicatiilor Web. JSP a aparut ca fiind deja o platforma axata pe componente. Componentele pe care se bazeaza sunt componentele JavaBeans si Enterprise JavaBeans. Aplicatiile sunt create astfel nct, valorile, datele si informatiile returnate de aceste componente s poata fi ncadrate si aranjate n pagini HTML. JSP poate fi folosit att de catre programatorii Java avansati ct si de catre programatorii care n-au o experienta vasta n domeniul programarii Java deoarece acestia pot utiliza componentele pe care cei dinti le-au creat cu o foarte mare usurinta.
3.3.4. Structura lexicala standard si semantica JSP

3.3.4.1. Reguli generale de sintaxa
O pagina JSP contine elemente JSP si date n format standard . Elementele JSP sunt exemple de anumite tipuri cunoscute n container. Daca elementul defineste obiecte, semantica include obiectele definite si tipul lor. Dupa cum deja stim, exista trei tipuri de elemente JSP: directive, scripting, actions. Datele sablon reprezinta singurul tip de date necunosccute containerului JSP. Ele nu se interpreteaza, fiind transferate clientului sau altor componente de procesare.
3.3.4.2. Sintaxa elementelor JSP

Sintaxa elementelor JSP are la baza XML. Fiecare element are un tag de start (care include si numele elementului), eventual anumite atribute, un body optional, un tag de sfrsit, sau pot sa aiba un tag gol cu atribute de genul:
<my tag attr1="attribute value" .> body

</mytag>
sau,
<mytag attr1="attribute value" .>

Dupa cum se vede, valoarea atributelor se scrie ntre ghilimele sau apostroafe. De mentionat este faptul ca tag-urile JSP sunt case-sensitive, ca si n XML sau XHTML. Toate paginile JSP au un echivalent valid n XML. Elementele care folosesc sintaxa alternativa sunt de forma: <% .. %>. Toate elementele JSP care au tag-uri de start si stop distincte (si un body inclus) trebuie sa nceapa si sa se sfrseasca n acelasi fisier. Daca un element are un tag gol, este tratat ca si unul care are un tag de start, unul de stop si un body gol. Acestea se numesc elemente goale ( empty elements). Liniile goale (white spaces) nu sunt luate n considerare dar este indicat sa nu apara n program.
3.3.4.3. Prinderea erorilor

Exista doua etape logice n procesarea fisierelor sursa a paginilor JSP: Translatia (compilarea) din sursa JSP n fisier JSP page implementation class. Procesarea cererilor pentru fiecare client n parte de catre o instanta a JSP page implementation class.
Erorile pot sa apara n orice moment al acestui proces. n continuare vor fi prezentate metodele de tratare a acestora. 1. Erorile de translatie
Translatia fisierului sursa printr-un container JSP poate avea loc oricnd ntre desfasurarea initiala a paginii din mediul de rulare al containerului si receptia si procesarea unei cereri din partea unui client. Daca translatia se realizeaza naintea sosirii cererii din partea clientului, atunci procesarea si notificarea erorii este dependenta de implementare. n cazul protocolului HTTP ntlnim error status code 500 (Server Error). 2. Erori pe durata procesarii cererilor
De-a lungul procesarii cererilor clientilor pot apre o serie de erori arbitrare n fiecare body al JSP page implementation class sau n alte coduri (Java sau alte limbaje de programare) apelate din acestea. Erorile pot fi detectate folosind mecanismul de tratare a exceptiilor din Java pentru a semnala solicitantilor aparitia lor. Aceste exceptii pot fi prinse si tratate n cadrul fiecarui body al clasei JSP. Oricum, orice exceptie netratata lansata de un body este trimisa ntr-un error page URL specificat n JSP.
3.3.5. Containerul JSP
3.3.5.1. Modelul JSP

Asa cum s-a mai spus, o pagina JSP este executata de un container JSP, instalat pe serverul web. Containerul livreaza cererile clientului catre pagina JSP si rspunsurile acesteia napoi clientului. Semantica modelului aflat n spatele paginilor JSP este aceeasi ca si n cazul servletilor: o pagina descrie cum sa fie creat obiectul response din obiectul request pentru protocolul Servlet, cu posibilitatea de a crea si/sau folosi n proces alte obiecte. Tot aici pot fi indicate cum sunt tratate anumite evenimente (pt JSP1.1 numai init si destroy). Protocolul vzut din punctul de vedere al serverului Web Entitatea care proceseaza cererile si creaza raspunsurile trebuie sa se comporte ca si o clasa Java, care implementeaza protocolul descris de servlet. Un container JSP localizeaza mai nti o instanta a unei astfel de clase dupa care proceseaza cererile n concordanta cu protocolul sus - amintit. Uneori containerul trebuie sa creeze anumite clase dinamice din pagina sursa, nainte de a crea obiectul raspuns. Prin acestea, se defineste un contract ntre container si JSP page implementation class. Daca este folosit protocolul HTTP, contractul este descris de catre clasa HttpServlet. Protocolul vzut de catre autorul paginii JSP Un astfel de contract este definit si ntre container si pagina. Acest contract este generat automat prin folosirea metodei _jspService(). Aceasta descrie actiunile ce trebuie facute la ntlnirea unor metode cum ar fi init() sau destroy(). Constrngerile dintre JSP container si JSP page apar pentru ca clasa Servlet corespunzatoare paginii trebuie sa implementeze interfata HttpJspPage, pentru protocolul HTTP.
3.3.5.2. JSP Page Implementation class

Containerul JSP creaza o clasa de interpretare pentru fiecare pagina JSP n parte. Numele acesteia este dependent de container. Crearea acestei clase poate fi facuta de catre un container sau poate fi implicata o superclasa furnizata de catre programator, prin atributul extends din comanda jsp. Acest mecanism este destul de complicat, fiind recomandat sa se foloseasca cu multa atentie. Pentru rezolvarea cererilor va fi folosit protocolul Servlet si pot fi folosite o serie de alte clase aditionale, eexistente n acelasi pachet cu clasa de implementare pentru a fi portabil n orice container. API Contracts Contractul dintre un container JSP si o clasa Java de implementare a paginii JSP corespunde interfetei Servlet. Contractul dintre JSP container si JSP page este descris n cele ce urmeaza: jspInit() - Metoda este definita optional n pagina JSP. Metoda este invocata cnd pagina JSP este initializata. Cnd metoda este apelata, toate metodele in servlet, inclusiv getServletConfig() sunt disponibile. jspDestroy() - Metoda este definita optional n pagina JSP si este invocata naintea distrugerii paginii. _jspService(<ServletRequestSubtype>, <ServletResponseSubtype>) - Metoda nu poate fi definita n pagina JSP. Containerul JSP genereaza automat aceasta metoda, lund n considerare continutul paginii JSP. Metoda este invocata pentru fiecare cerere client.
Request and response parameters Dup cum s-a vzut mai sus, contractul dintre JSP conatiner si JSP page necesita anumiti parametri de cerere si raspuns. Tipul conventional al parametrului request (pe care aceste specificatii le numesc <ServletRequestSubtype>) este o interfata care extinde javax.servlet.ServletRequest. Interfata trebuie sa defineasca un contract dependent de protocol ntre container si clasa de implementare. n acelasi mod, pentru parametrul response este o interfat care extinde javax.servlet.ServletReponse. Contractul pentru HTTP este definit de catre interfetele javax.servlet.http.HttpServletRequest si javax.servlet.http.HttpServletResponse. Omiterea atributului extends - daca n directiva language lipseste acest atribut, containerul JSP poate genera orice alta clasa care sa satisfaca contractul descris mai sus. 1. Folosirea atributului extends duce la pastrarea numelui, specificat n acest atribut de catre clasa generata. Containerul JSP trebuie sa testeze daca superclasa furnizata implementeaza HttpJspPage daca protocolul
este HTTP sau JspPage, n caz contrar toate metodele din interfata Servlet sunt declarate final. In plus, este responsabilitatea autorului paginii JSP ca superclasa furnizata sa permita: Metoda service() din Servlet API sa invoce metoda jspService() Metoda init(ServletConfig) care pstreaza configuratiile, sa le faca diponibile prin getServletConfig(), apoi invoca jspInit(). Metoda destroy() invoca jspDestroy().
Este lansata o eroare de interpretare de catre container daca superclasa nu satisface aceste cereri. Containerul JSP stocheaza datele (daca este specificata aceasta optiune) ce vor fi trimise de la server catre client. Header-ele nu sunt trimise clientului dect la aparitia primei metode flush(). Ca urmare, nici o operatie care depinde de acestea (cum ar fi setContentType(), redirect(), error() ) nu este executata si header-ele nu sunt trimise. JSP1.1 include o clasa care stocheaza datele si trimite datele de iesire, numita javax.servlet.jsp.JspWriter. Clasa JspWriter este folosita n metoda _jspPageService ca n urmatorul exemplu:
import javax.servlet.jsp.JspWriter;
static JspFactory _jspFactory = JspFactory.getDefaultFactory();
_jspService(<SRequest> request, <SResponse> response)

Chiar si cu buffer-ul activat se poate folosi redirectarea metodelor dintr-un script prin invocarea directa a comenzii response.redirect(URL). Precompilarea O pagina care foloseste protocolul HTTP va receptiona cereri HTTP. Containerele JSP1.1 trebuie sa suporte un precompilation protocol simplu, precum si ctevareserved parameter names elementare. Sa nu se confunde protocolul de precompilare cu notiunea de compilare a unei pagini JSP ntr-un Servlet. Toate numele parametrilor request care ncep cu "jsp" sunt rezervati si nu pot fi folositi oricum, dect asa cum se specifica n specificatii. Toate paginile JSP trebuie sa ignore orice parametru care incepe cu "_jsp". O cerere catre o pagina JSP care contine un parametru cerere cu numele "jsp_precompile" este o precompilation request. Un astfel de parametru poate sa nu contina nici o valoare sau o valoare "true" sau "false". n toate cazurile cererile nu trebuie livrate paginii JSP. Intentia cererii de precompilare este aceea de a avertiza containerul sa precompileze pagina JSP n propria clasa de implementare. Acest lucru este dat de valoarea parametrului "true" sau fara valoare, cu mentiunea ca n aceste cazuri cererea poate fi doar ignorata. n exemplele de mai jos n liniile 1, 2 si 4 cererea nu va fi trimisa paginii, n 3 si 5 cererea va fi trimisa fara nici o modificare, iar n 6 este incorecta, genernd o eroare Server Error:
?jsp_precompile ?jsp_precompile="true"
?jsp_precompile="false"
?foogar="foobaz" & jsp_precompile="true" ?foobar="foobaz" & jsp_precompile="false" ?jsp_precompile="foo"
Valid JSP page O pagina JSP este valabila pentru o platforma Java daca si numai daca JSP page implementation class, mpreuna cu orice alta clasa definita de containerul JSP, este un program valid pentru platforma data. Toate numele de forma jsp_* si jspx_* n orice combinatie de caractere mari si mici sunt rezervate de catre specificatiile JSP. Sectiunea de declaratii este rezultatul concatenarii tuturor declaratiilor din pagina n ordinea n care ele vor aparea. Sectiunea de initializare defineste si initializeaza obiectele implicite disponibile paginii JSP. Sectiunea main permite o mapare ntre obiectele cerere si raspuns. Continutul segmentului (2) este format din scriptlets, expresii si text din pagina JSP. Aceste elemente sunt procesate secvential. O translatie pentru fiecare dintre ele se face dupa cum se indica mai jos, dependenta de tipul elementului: Template data este transformat ntr-un cod ce va fi plasat n stream-ul de iesire numit de catre variabila out. Toate spatiile goale sunt pastrate. Aceasta corespunde unei comenzi de forma: out.print(template); Un scriptlet este transformat ntr-un fragment de instructiuni Java. O expresie devine o comanda Java care nsereaza valoarea ei convertita la un String n stream-ul de iesire numit de catre variabila out. Forma sa este: out.print(expression); O actiune care defineste unul sau mai multe obiecte este tansformat n una sau mai multe declaratii variabile pentru aceste obiecte, mpreuna cu codul care le initializeaza. Singura actiune standard n JSP1.1 este jsp:useBean. Numele variabilei introduse este acela al atributului id iar tipul sau este cel al atributului class. De mentionat ca valoarea atributului scope nu afecteaza domeniul de vizibilitate al variabilei n programul respectiv, afectnd doar unde vor fi referintele aditionale la obiect, marcate de catre aceasta. O biblioteca de tag-uri ( Tag Library) separa anumite functii prin definirea unui (sub) limbaj care permite utilizarea mai usoara a acestora n pagini. Actiunile introduse de biblioteca pot fi folosite de catre programator explicit, prin scrierea manuala, sau implicit, prin folosirea unor unelte predefinite. Actiunile livrate ca si biblioteci de tag-uri sunt importate n pagina prin folosirea unei comenzi taglib si pot fi folosite printr-un prefix dat de comanda. O actiune poate creea obiecte noi, care pot fi trecute altor actiuni sau pot fi manipulate manual prin limbajul script. Bibliotecile de tag-uri sunt portabile, putnd fi folosite n orice JSP, indiferent de limbajul script folosit. Mecanismul extinderii tag-urilor descris n acest capitol are mai multe obiective: Portabilitate - o actiune trebuie sa poata fi folosita de catre orice container JSP Simplitate - sa fie ct mai usor de folosit pentru a putea fi accesibila chiar si utilizatorilor mai putin experimentati. Expresivitate - sa ofere o larga diversitate de actiuni (actiuni incuibarite, elemente script n cadrul body-urilor, etc.) Reutilizarea codului scris n alte limbaje script
Mecanismul de baza n definirea semanticii actiunii este acela de tag handler. Acesta este o clasa Java care implementeaza interfata Tag sau BodyTag. Clasa de implementare a paginii instantiaza (sau reutilizeaza) un obiect tag handler pentru fiecare actiune n pagina. Acesta este un obiect Java care implementeaza interfatajavax.servlet.jsp.tagext.Tag si este responsabil pentru interactiunea dintre JSP si obiectele de tip server-side. Exista doua interfete principale: Tag si BodyTag: Tag - defineste metodele de baza necesare n toate tag handlers; n plus mai sunt doStartTag() si doEndTag(). BodyTag - permite folosirea ul: doInitBody() si doAfterBody(). a doua metode aditionale atunci cnd handler-ul manipuleaza body-
Folosirea interfetelor simplifica utilizarea obiectelor Java existente si transformarea lor n tag handler. Alte clase de baza mai sunt: TagSupport si BodyTagSuport.
Actiuni simple
n multe cazuri handler-ul are nevoie doar de folosirea metodei doStartTag(), invocata cnd este ntilnit tag-ul de start. Aceasta metoda acceseaza atributele tag-ului si informatiile despre starea paginii. n mod similar este doEndTag(), doar ca aceasta este invocata cnd este ntilnit tag-ul de sfrsit. Rezultatul acesteia indica daca mai este evaluat sau nu ce a mai ramas din pagina. Un caz particular des ntlnit este folosirea unui body gol.
Actiuni cu body
n acest caz sunt invocate metodele doInitBody() si doAfterBody(), definite n interfata BodyTag. Astfel, evaluarea este fcuta pe baza rezultatelor returnate de metodele invocate, dupa cum urmeaza: Metoda doStartTag() este invocata prima ntotdeauna si returneaza o valoare de tip int care indica daca poate fi evaluat sau nu corpul actiunii. Daca da (este returnat EVAL_BODY_TAG), este creat un stream incuibarit de tip BodyContent si trimis obiectului de tip BodyTag prin setBodyContent. Dupa aceasta este invocata doInitBoody() si este evaluat corpul actiunii, al carui rezultat este pus n noul obiect de tip BodyContent creat. La sfrsit este invocata metoda doAfterBody(). Daca invocarea doStartTag() returneaza valoarea SKIP_BODY, corpul nu este evaluat. Metoda doBody() poate folosi obiectul bodyContext pentru diferite functii, cum ar fi conversia acestuia ntrun String si folosirea lui ca si argument sau filtrarea unor actiuni nainte de a le pune n stream-ul de iesire. Metoda doAfterBody() returneaza valoare care indica daca viitoarele reevaluari pot fi facute sau nu. Mai jos sunt prezentate cteva exemple simple care folosesc mecanismul tag extension.
Call functionality, no Body : este cel mai simplu exemplu, care doar colecteaza atributele si invoca anumite actiuni (singura de aici este foo): <x:foo att1="." att2="." att3="." />. n acest caz vom defini un tag handler FooTag care extinde TagSupport doar redefinind doStartTag. Aceasta va lua atributele si va interactiona cuPageContext. Call functionality, no Body, define Object: <x:bar id="mybar" att1="." att2="." att3="." />. Dupa aceasta linie obiectul mybar este disponibil pentru limbajul script. Descriptorul bibliotecii de tag-uri trebuie sa mentioneze o clasa TagExtraInfo care va fi folosita pentru a determina variabila ce va fi creata de aceasta actiune. Call functionality, define Object by Scope:
<x:bar att1="." att2="." att3="." > r> BODY
/ </x:ba
Template mechanism: n partea de lucru cu serverul exista o serie de mecanisme standard. Cel mai simplu dintre acestea ia un token si-l va nlocui cu un anumit text specificat dinainte (care poate fi schimbat usor). Tag Library O astfel de biblioteca este o colectie de actiuni care ncapsuleaza anumite functii comune ce vor fi folosite. Ea este facuta disponibila n pagina prin directiva taglib care identifica libraria printr-un URI (Universal Resource Identifier). URI poate fi orice adresa care poate identifica n mod unic o biblioteca. URI este asociat cu un fisier Tag Library Descriptor (TLD) si cu clasele tag handler. Packaged Tag Libraries Pentru a accepta o biblioteca mpachetata ntr-un pachet cum ar fi un fisier JAR sunt necesare asa numitele JSP tools. Fisierul JAR trebuie sa aiba un descriptor numit META-INF/taglib.tld. Location of Java classes Clasele tag handler (request time) si TagExtraInfo (translation-time) sunt clase Java. ntr-o aplicatie web ele se vor afla la o locatie standard pentru clasele Java: ori ntr-un fisier JAR, de exemplu, n cazul utilizarii serverului resin, pus n directorul WEB-INF/lib, ori n WEB-INF/classes. Comanda taglib
Aceasta declara daca pagina foloseste o biblioteca de tag-uri, identifica n mod unic libraria folosind URI si asociaza un tag prefix mai ales actiunilor din cadrul bibliotecii. Se considera eroare daca containerul JSP nu poate localiza biblioteca dup URI-ul dat sau daca instructiunea taglib apare dupa o actiune care foloseste prefixul. Descriptorul bibliotecii (TLD) TLD este un document XML care descrie o biblioteca de tag-uri. Acesta este folosit de catre container pentru a interpreta paginile care includ o comand taglibce desemneaza o anume biblioteca. TLD include informatii despre containerul JSP, despre biblioteca si despre fiecare actiune definita n biblioteca. Actiunile sunt definite prin nume clasa pentru tag handler-ul ei, informatii optionale despre clasa TagExtraInfo si informatii despre toate atributele sale. Fiecare atribut este mentionat explicit, cu indicatii daca este sau nu imputernicit (mandatory), daca poate accepta expresii de tip request-time, etc. Avantajul unui TLD este acela ca se pot citi informatii despre tools fara a fi nevoie de instantierea respectivului obiect sau de ncarcarea claselor. URI-ul care descrie biblioteca poate fi mapat ntr-un fisier TLD prin doua mecanisme, mapare implicita sau prin web.xml descris folosind elementul taglib. Localizare implicita implic daca nu exist nici un subelement taglib sa mapeze URI-ul folosit n taglib, descriptorul va cauta n locatia indicata implicit de URI. Aceasta regula se aplica doar pentru adrese locale pentru aplicatia curenta. Ex: <%@ taglib uri="tlds/Prlibrary_1_4.tld" prefix="x" %>. Mapare prin web.xml este descrisa folosind elementul taglib, care are doua subelemente, taglib-uri si tagliblocation. Deci: 1. taglib: este un subelement al aplicatiei web: <! element web-app . taglib* . >. Acest element are la rndul sau alte doua subelemente si un atribut: 2. <!ELEMENT taglib (taglib-uri, taglib-location ) > <ELEMENT taglib id ID #IMPLIED>
taglib-uri - descrie URI care identifica biblioteca folosita n aplicatie: <!ELEMENT taglib-uri (#PCDATA) > PCDATA ::= a URI spac, relative to the web.xml document.
3.
taglib-location - contine locatia unde poate fi gasita biblioteca. <!ELEMENT taglib-location (#PCDATA)> PCDATA ::= a resurce location, relative to the root of the Web Application, where to find the Tag Library Descriptor file
Folosirea adreselor URI permite folosirea numelor scurte n instructiunea taglib: <%@ taglib uri="myPRlibrary" prefix="x" %> Asamblarea aplicatiilor Web Ca parte a procesului de asamblare a aplicatiilor, Application Assembler-ul creaz un director WEB-INF/ cu subdirectoarele lib/ si classes/, plaseaza paginile, Servletii, clasele auxiliare, bibliotecile de tag - uri n pozitiile corespunzatoare, dupa care creaza WEB-INF/web.xml si le leag pe toate mpreuna. Librariile care au fost livrate n format standard pentru JSP tools pot fi puse direct n WEB-INF/lib. Asamblerul poate crea taglib-uri de intrare n web.xml pentru fiecare biblioteca folosita. Formatul descriptorului (TLD) taglib - este radacina documentului. Are doua elemente:
<!ATTLIST taglib
id ID #IMPLIED xmlns CDATA

#FIXED
*http://java.sun.com/j2ee/dtds/webjsptaglibrary_1_1.dtd >
Un element taglib are mai multe subelemente care definesc: tlibversion - descrie versiunea de biblioteca tag. Sintaxa este: <!ELEMENT tlibversion (#PCDATA) >, unde #PCDATA::= [0-9]* 0.3. jspversion - descrie versiunea JSP (n cazul nostru este 1.1) shortname - defineste un nume scurt, implicit, care poate fi folosit n paginile JSP pentru a crea nume cu anumite valori: <!ELEMENT shortname (#PCDATA) >, #PCDATA::=NMTOKEN. uri - defineste un URI public care identifica n mod unic versiunea curenta de biblioteca de tag-uri. Este recomandat ca URI sa fie un URL la descriptorul bibliotecii de tag - uri. info - defineste un text care descrie biblioteca tag. tag - defineste o actiune n biblioteca. Are un singur atribut: <!ATTLIST tag id ID #IMPLIED>. Un tag poate avea mai multe subelemente: tag class - defineste clasa tag handler implementnd interfata javax.servlet.jsp.tagext.Tag. Acest element este obligatoriu. Are sintaxa<! ELEMENT tagclass (#PCDATA) >, #PCDATA::= fully qualified Java class name. teilclass - defineste subclasa javax.servlet.jsp.tagext.TagExtraInfo pentru acest tag. Acest element este optional. bodycontent - furnizeaza o idee despre continutul corpului acestei actiuni. attribute - informatii despre un atribut al acestei actiuni. Are sinataxa: <!ELEMENT attribute (name, subelemente de forma: required?, rtextvalue?)>. Are trei
name - defineste numele tag-ului sau atributului definit. required - indica daca un atribut incuibarit este obligatoriu sau optional.
Are sintaxa: <!ELEMENT required (#PCDATA) >, #PCDATA::= true | false | yes | no. Valoarea implicita este "false". rtexprvalue - indica daca atributul incuibarit poate avea ca si valoare un scriptlet.
Tag Handlers Tag handler este un obiect de tip run-time server-side, creat pentru a usura evaluarea actiunilor pe durata executiei paginii. De fapt este o componenta server-side JavaBeans invizibila, dar care implementeaza o interfata aditionala pentru a indica un protocol run-time. Sunt doua interfete care descriu un handler: 1. 2. Tag este folosit pentru handler-e simple, care nu manipuleaza continutul din body (daca acesta exista); BodyTag este o extensie a Tag, care permite accesul la continut. n crearea unor handler-e noi pot fi folosite ca si clase de baza clasele TagSupport siBodyTagSupport. Un tag handler are anumite proprietti care sunt setate de catre containerul JSP (de obicei prin JSP page implementation class), prin diferite moduri: Obiectul pageControl, pentru pagini n care tag - ul este localizat. Tag handler - ul parent pentru actiuni inchise. Un tag handler poate avea anumite proprietati, cum are orice componenta Bean. Interfata Tag defineste contractul de baza pentru toate handler-ele. Proprietatile unui handler trebuie initializate nainte de folosirea acestuia. Este responsabilitatea containerului sa invoce metodele potrivite pentru initializarea acestor proprietati. Odata setate corect, aceste proprietati ramn valabile pentru instanta respectiva. Dupa initializare pot fi invocate metodele doStartTag() si doEndTag(). Daca toate invocarile handler-ului sunt complete, poate fi folosita metoda release(), care reseteaza toate proprietatile la o anume valoare nespecificata. Consideratii life-cycle n momentul executiei paginii se va folosi o instanta Tag disponibila, initializata cu un prefix si un nume, fara sa mai fie folosite de alte instante. Dupa aceasta va elibera instanta respectiva si o va face disponibila pentru refolosiri ulterioare. Acest procedeu reduce numarul instantelor dorite la un moment dat. Initializarea este corecta prin setarea proprietatilor pageContext, parent, tagData n aceasta ordine. Variabile script JSP suporta variabile script ce pot fi declarate printr-un script si pot fi folosite n altul. La fel, actiunile JSP pot fi folosite ca sa defineasca variabile, adica n elemente script sau n alte actiuni. De exemplu, actiunea standard jsp:useBean poate defini un obiect care va fi folosit mai trziu printr-o variabila script. MetodagetVariableInfo() este folosita pentru a furniza informatii despre fiecare variabila care va fi creata la request time cnd respectiva actiune este executata. Rezultatul acestei metode este o matrice avnd ca si valori obiecte VariableInfo. Fiecare obiect de genul acesta descrie o variabila script prin nume, tip, daca variabila este noua sau nu si care este domeniul su de vizibilitate. Valorile definite pentru domeniul de vizibilitate sunt: NESTED - daca variabila script este disponibila ntre tag-ul start si si tag-ul end al actiunii care l defineste AT_BEGIN - daca variabila este vizibila de la tag-ul start pn la sfrsitul paginii AT_END - variabila este vizibila dupa tag-ul end al actiunii care o defineste pna la sfrsitul paginii
Valoarea domeniului de vizibilitate stabileste care metode au sau nu efect asupra valorii variabilelor si daca, n lipsa altor informatii aditionale, este necesara sincronizarea.
Actiuni cooperante De multe ori este necesara cooperarea ntre doua actiuni n cadrul unei pagini, cum ar fi de exemplu o actiune care defineste un obiect server-side si una care vrea sa-l foloseasca. Pentru aceasta exista doua mecanisme de baza: id-uri si PageContent. Unul dintre mecanismele de cooperare ntre actiuni este de a da numele obiectului n cadrul
paginii. Astfel, prima actiune creaza si numeste obiectul n timp ce a doua foloseste numele pentru a returna obiectul. n implementarea JSP maparea dintre nume si valoare se face prin obiectul implicit pageContext. Acest obiect este transferat printr-o instanta handler, deci poate fi folosit pentru comunicarea informatiilor. Tot ce trebuie, este sa cunoastem numele sub care este stocata infomatia n pageContext. Stiva run-time O alternativa la comunicarea explicita a informatiei printr-un obiect este coordonarea explicita bazata pe domenii de vizibilitate sintactice. De exemplu, n fragmentul de program de mai jos, actiunea action trebuie s creeze un obiect server-side. Mai trziu, actiunea ncuibarit bar poate sa acceseze acest obiect. Obiectul nu este numit prin pageContext, el este gasit din cauza ca elementul action este cea mai apropiata instanta de tipul dorit:
<action> <bar/> </action>

Aceast facilitate este suportata de catre metoda statica findAncestorWithClass(Tag,Class) din Tag care utilizeaza o referint la tag-ul parinte tinut de catre fiecare instanta Tag n parte, care efectiv furnizeaza o stiv run-time. n foarte multe cazuri exista anumite constrngeri n legtura cu folosirea actiunilor, care daca nu sunt respectate determina lansarea unor exceptii catre utilizator. Informatii sintactice n TLD (Tag Library Descriptor)
TLD contine anumite informatii sintactice de baza. n mod particular, atributele sunt descrise incluznd numele lor, daca ele sunt obligatorii, sau dac sunt optionale permit expresii de tip request-time. n plus, atributul bodyContent poate fi folosit sa indice daca o actiune trebuie sa fie goala. Toate constrngerile descrise n TLD sunt obligatorii.
3.3.6. Comparatie JSP - Servleti

Desi JSP-urile pot fi folosite pentru majoritatea scopurilor, exista anumite situatii cnd servletii sunt mai indicati.
3.3.6.1. Generare de date binare

Servletii sunt potriviti pentru generarea de date binare ca de exemplu imagini sau continut special. Cererile pentru acel tip de continut sunt mapate la servleti care stiu sa genereze acel tip de continut, dar din punctul de vedere al clientului web, el cere o imagine normala. Singura presupunere facuta este ca clientul suporta formatul de imagine generat. Un exemplu comun pe Internet este un servlet care genereaza un grafic cu cotatiile la bursa cu date luate on-line dintr-o baza de date. Aceasta imagine este stocata n memorie si regenerata n fiecare minut. Astfel se salveaza timp si creste performanta att pentru ciclurile de executie ct si pentru accesul la fisiere.
3.3.6.2. Extinderea functionalitatii unui server web

Servletii sunt un mecanism portabil pentru extinderea functionalitatii unui server web. De exemplu, daca este nevoie sa fie suportat un nou format de date, se creaza un servlet care apoi este mapat pentru acel tip de date. Un bun exemplu este un servlet care extinde un server web pentru paginile JSP. Acest servlet parcurge toate fisierele care au extensia jsp si le compileaza n servleti. Acesti servleti rezultati sunt apoi executati de un container web si raspunsul rezultat este trimis la client. 3.3.6.3. Paralela pagini JSP - Servleti
Depinznd de componenta echipei de dezvoltare, de constrngerile de timp si de arhitectura aplicatiei, folosirea paginilor JSP si a servletilor poate diferi. Ambele tehnologi au avantaje si ar trebui folosite eficient. n unele cazuri nu exista o singura optiune si ramne la latitudinea managerului de proiect ce tehnologie va folosi. Servleti sunt unelte de programare ce se potrivesc cel mai bine la functii de nivel scazut care nu necesita modificari frecvente. Paginile JSP sunt un mod de legare a continutului dinamic si a logicii ntr - un mod centrat pe prezentare. Paginile JSP sunt capabile de a face diferenta ntre partea de prezentare, realizata n mare parte n HTML brut, iar partea logica de aplicatie, realizata de componentele JavaBeans si tag-urile personalizate. Chiar si paginile JSP pot fi folosite modular ca si componente reutilizabile.
3.3.7. Exemple
1. Extinderea unei aplicatii SMTP Client utiliznd Java Server Pages:
FormMail.htm
<HTML> <HEAD> <TITLE>MailForm</TITLE>

</HEAD>
<BODY bgcolor="#FFFFFF"> <form action="FormMail.jsp" method="POST"> <div align="center"><center><table border="0" cellpadding="2" cellspacing="0"> <tr> <td bgcolor="#0000FF"> </td> <td align="center" bgcolor="#0000FF"><font color="#80FF00" face="Trebuchet MS"><u>Form Mail Sending Example</u></font></td> <td align="center" bgcolor="#0000FF"><font color="#80FF00" face="Trebuchet MS"><u>Examples</u></font></td> </tr> <tr>
<td bgcolor="#000080"><font color="#00FFFF" face="Trebuchet MS">From</font></td> <td bgcolor="#008080"><font face="Trebuchet MS"><input type="text" size="20" name="from"></font></td> <td bgcolor="#008080"><font color="#80FF00" face="Trebuchet MS">joe@acme.com</font></td> </tr> <tr> <td bgcolor="#000080"><font color="#00FFFF" face="Trebuchet MS">To</font></td> <td bgcolor="#008080"><font face="Trebuchet MS"><input type="text" size="30" name="to"></font></td> <td bgcolor="#008080"><font color="#80FF00" face="Trebuchet MS">mary@acme.com</font></td> </tr> <tr> <td bgcolor="#000080"><font color="#00FFFF" face="Trebuchet MS">Subject</font></td> <td bgcolor="#008080"><font face="Trebuchet MS"><input type="text" size="40" name="subject"></font></td> <td bgcolor="#008080"><font color="#80FF00" face="Trebuchet MS">Hi There!</font></td> </tr>
<tr> <td bgcolor="#000080"><font color="#00FFFF" face="Trebuchet MS">Use Server</font></td> <td bgcolor="#008080"><font face="Trebuchet MS"><input type="text" size="40" name="server" value="localhost"></font></td> <td bgcolor="#008080"><font color="#80FF00" face="Trebuchet MS">acme.com</font></td> </tr> <tr> <td valign="top" bgcolor="#000080"><font color="#00FFFF" face="Trebuchet MS">Msg Body</font></td> <td bgcolor="#008080"><textarea name="msgbody" rows="20" cols="38"></textarea></td> <td bgcolor="#008080"> </td> </tr> <tr> <td bgcolor="#008080"> </td> <td align="center" bgcolor="#008080"><input type="submit" name="B1" value="Submit"></td> <td bgcolor="#008080"> </td> </tr> </table> </center></div>
</form> </BODY> </HTML>

FormMail.jsp
<%@ page import="javax.servlet.http.HttpUtils" %>

<%@ page import="java.util.*" %>
<%@ page import = "java.sql.*" %> <%@ page import = "java.io.*" %> <%@ page import= "sun.net.smtp.SmtpClient" %> <% String from,to,subject,msgbody,serverName; try
catch (Exception e)
%> Hold On A Moment while I try to Send Your Mail... <BR> <% out.flush(); try
catch (Exception e)
%> <BR>
<BR> <A HREF="FormMail.htm">Click here to send another!</A>

2. Afisarea unui element multimedia (imagine, sunet, secventa audio - video) citit de la un URL clar stabilit.
afisare.jsp
<%@ page import="javax.servlet.http.HttpUtils" %> <%@ page import="java.util.*" %> <%@ page import = "java.sql.*" %> <%@ page import = "java.io.*" %> <%@ page import = "myPackage.User81" %> <jsp:useBean id="bean81" scope="session" class="myPackage.User81" /> <jsp:setProperty name ="bean81" property="R1" /> <html> <head> <title>Afisare imagini / Rulare secvente audio-video</title> </head> <body background="/images/back.jpg"> <table border="0" cellpadding="4" width="179" height="32" background="/images/back.jpg"> <tr> <td width="76" align="left" bgcolor="#C0C0C0" height="1"> <p align="center"><b><font size="2"><a href="../../Managementul%20unei%20DB%20MM.htm"> Home Page</a></font></b></td> <td width="77" align="left" bgcolor="#C0C0C0" height="1"> <font size="2"><b><a href="../new_page_4.htm"
target="_self">Main Page</a></b></font></td> </tr> </table> <table border="0" cellpadding="4" width="100%" height="1" background="/images/back.jpg"> <tr> <td width="21%" align="left" bordercolor="#0099CC" bgcolor="#FFFFFF" height="1" background="/images/back.jpg"> <hr size="5" color="#0099CC"> <p align="center"><b> <font color="#0000FF"><font size="5">M</font><font size="4">anagementul </font><font size="5">U</font><font size="4">nei </font><font size="5">B</font><font size="4">aze de </font><font size="5">D</font><font size="4">ate </font><font size="5">M</font><font size="4">ultimedia</font></font></b> <p align="center"> </p> <form method="POST" action="user2.htm"> <% String nume = bean81.R1; String url = "http://193.226.17.8:7070/myRoot/MMFiles/"+nume; if ((nume.endsWith("jpg")) | (nume.endsWith("gif"))) else %> <center> <p align="right"><input type="submit" value="Submit" name="B1"></p> </center>
</form> <p align="center"> </p> </td> </tr> </table> <p> </p> <table border="0" cellpadding="4" width="100%" height="32" background="/images/back.jpg"> <tr> <td width="21%" align="left" bordercolor="#0099CC" bgcolor="#C0C0C0" height="1" background="/images/back.jpg"> <hr size="5" color="#0099CC"> <p align="left"><img border="0" src="/images/B5OV.GIF" width="36" height="40">   <img border="0" src="/images/B6OV.GIF" width="38" height="40"></td> </tr> </table> </body> </html>
User81.java package myPackage;
import java.awt.*; import java.util.*; public class User81 public int getIdFile(int i) public String readColoana(String tabel, String numeColoana, String id) public String readColoana(String tabel, String numeColoana, int
id) public String getR1() public void setR1(String R1) }

3. Introducerea numelui unui fisier multimedia ntr-o baza de date realizndu-se totodata transferul lui ntr-un subdirector pe masina unde ruleaza serverul web, dupa vizualizarea continutului acestui fisier.
insert_file.htm
<html> <head> <title>Title </title> </head> <body background="/images/back.jpg"> <table border="0" cellpadding="4" width="100%" height="1" background="/images/back.jpg"> <tr> <td width="21%" align="left" bordercolor="#0099CC" bgcolor="#FFFFFF" height="1" background="../../images/back.jpg"> <hr size="5" color="#0099CC"> </td> </tr> </table> <p align="center"><b> <font color="#0000FF"><font size="5">M</font><font size="4">anagementul </font><font size="5">U</font><font size="4">nei </font><font size="5">B</font><font size="4">aze de </font><font size="5">D</font><font size="4">ate </font><font size="5">M</font><font
size="4">ultimedia</font></font></b> <p align="center"><b><font size="4">Introducerea informatiilor in baza de date </font></b></p> <p align="center"> </p> <form method="POST" action="insert_file.jsp"> <p Completati campurile de mai jos cu informatile care se vor dori a fi introdusa in baza de date.</p> <p align="left" style="margin-bottom: -13"> </p> <p align="left" style="margin-bottom: -13"> </p> <center> <table border="0" cellpadding="4" width="50%"> <tr> <td width="33%"> Nume Fisier </td> <td width="33%"> <INPUT TYPE="file" name="F1"> </td> <td width="34%"> Ex: xxx.gif, xxx.mpg, etc.</td> </tr> <tr> <td width="33%">Informatii</td> <td width="33%"> <textarea rows="8" name="S1" cols="50"></textarea></td> <td width="34%"> Ex: Reprezinta "poza" autorului acestui web site</td> </tr> <tr>
<td width="33%"> </td> <td width="33%"> </td> <td width="34%"><input type="submit" value="Submit" name="B1"></td> </tr> </table> </center> </form> <p align="center"> </p> <p> </p> <table border="0" cellpadding="4" width="100%" height="32" background="/images/back.jpg"> <tr> <td width="21%" align="left" bordercolor="#0099CC" bgcolor="#C0C0C0" height="1" background="/images/back.jpg"> <hr size="5" color="#0099CC">
<p align="left"><img border="0" src="/images/B5OV.GIF" width="36" height="40">   <img border="0" src="/images/B6OV.GIF" width="38" height="40"></td>
</tr>
</table>
</body> </html>
insertFile.jsp
<%@ page import="javax.servlet.http.HttpUtils" %> <%@ page import="java.util.*" %> <%@ page import = "java.sql.*" %> <%@ page import = "java.io.*" %>
<%@ page import = "myPackage.Bean3" %> <jsp:useBean id="bean3" scope="session" class="myPackage.Bean3" /> <html> <head> <title>Fereastra de Vizualizare</title> </head> <body background="/images/back.jpg"> <table border="0" cellpadding="4" width="179" height="32" background="/images/back.jpg"> <tr> <td width="76" align="left" bgcolor="#C0C0C0" height="1"> <p align="center"><b><font size="2"><a href="../../Managementul%20unei%20DB%20MM.htm"> Home Page</a></font></b></td> <td width="77" align="left" bgcolor="#C0C0C0" height="1"> <font size="2"><b><a href="../new_page_4.htm" target="_self">Main Page</a></b></font></td> </tr> </table> <table border="0" cellpadding="4" width="100%" height="1" background="/images/back.jpg"> <tr> <td width="21%" align="left" bordercolor="#0099CC" bgcolor="#FFFFFF" height="1" background="/images/back.jpg"> <hr size="5" color="#0099CC"> <p align="center"><b> <font color="#0000FF"><font size="5">M</font><font size="4">anagementul </font><font
size="5">U</font><font size="4">nei </font><font size="5">B</font><font size="4">aze de </font><font size="5">D</font><font size="4">ate </font><font size="5">M</font><font size="4">ultimedia</font></font></b> <p align="center"> </p> <form method="POST" action="CadruPrincipal.htm"> <% String nume = bean3.getName(); String complet = bean3.F1; String url = "http://193.226.17.8:7070/myRoot/MMFiles/"+nume; if ((nume.endsWith("jpg")) | (nume.endsWith("gif"))) else %> <center> <p align="right"><input type="submit" value="Submit" name="B1"></p> </center> </form> <p align="center"> </p> </td> </tr> </table> <% bean3.setMMFiles(); ftpClient client = new ftpClient();
client.getFis(bean3.getName(), "myLoginID", "myPassword") %> <p> </p> <table border="0" cellpadding="4" width="100%" height="32" background="/images/back.jpg"> <tr> <td width="21%" align="left" bordercolor="#0099CC" bgcolor="#C0C0C0" height="1" background="/images/back.jpg"> <hr size="5" color="#0099CC"> <p align="left"><img border="0" src="/images/B5OV.GIF" width="36" height="40">   <img border="0" src="/images/B6OV.GIF" width="38" height="40"></td> </tr> </table> </body> </html>
ftpClient.java
package myPackage; import sun.net.ftp.*; import sun.net.*; import java.io.*; public class ftpClient extends FtpClient os.close(); } catch (java.io.IOException e) } }
Bean3.java
package myPackage; import java.awt.*; import java.util.*; public class Bean3 public String getF1() public void setF1(String F1) public String getS1() public void setS1(String S1) public boolean validate() if (S1.equals("")) return allOk; } public String getName() // scrierea informatiei in tabelul MMFiles al DB public void setMMFiles() }

Tehnologia JSP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tehnologia JSP

Uploaded by

Copyright:

Available Formats

Tehnologia JSP

<HTML> <BODY> <% out.println("HELLO JSP WORLD"); %> </BODY> </HTML>

<%@ directive %>

3.3.1.1. Directiva page

3.3.1.2. Directiva include

<%@ include file="relativeURLspec" %>

3.3.1.3. Directiva taglib

<%@ taglib uri="tagLibraryURI" prefix="tagPrefix" %>

<jsp:include page="urlSpec" flush="true" />

<jsp:include page="urlSpec" flush="true"> </jsp:include>

<jsp:forward page="relativeURLspec" />

<jsp:forward page=relativeURLspec"> </jsp:forward>

<jsp:plugin type="pluginType" code="classFile" codebase="relativeURLpath"> <jsp:params> ... </jsp:params> </jsp:plugin>

3.3.2. Semantica JSP

<%@ directive *%>

3.3.2.2. Compilarea JSP

3.3.2.3. Obiecte si domenii de vizibilitate

3.3.2.4. Instructiuni si actiuni

<mytag attribute = "attribute value" .>

<%@ directive .%>

3.3.2.6. Obiecte si variabile

3.3.2.7. Script-uri, actiuni si elemente beans

3.3.3. Comparatie JSP - ASP

3.3.4. Structura lexicala standard si semantica JSP

3.3.4.2. Sintaxa elementelor JSP

<my tag attr1="attribute value" .> body

<mytag attr1="attribute value" .>

3.3.4.3. Prinderea erorilor

3.3.5. Containerul JSP

3.3.5.1. Modelul JSP

3.3.5.2. JSP Page Implementation class

_jspService(<SRequest> request, <SResponse> response)

?foogar="foobaz" & jsp_precompile="true" ?foobar="foobaz" & jsp_precompile="false" ?jsp_precompile="foo"

<x:bar att1="." att2="." att3="." > r> BODY

id ID #IMPLIED xmlns CDATA

<action> <bar/> </action>

3.3.6. Comparatie JSP - Servleti

3.3.6.1. Generare de date binare

3.3.6.2. Extinderea functionalitatii unui server web

<HTML> <HEAD> <TITLE>MailForm</TITLE>

</form> </BODY> </HTML>

<%@ page import="javax.servlet.http.HttpUtils" %>

<BR> <A HREF="FormMail.htm">Click here to send another!</A>

id) public String getR1() public void setR1(String R1) }

You might also like