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:

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 într-un 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 tip class

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 atât continut cât 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:

Î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 câteva 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:

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:

uri: referentiaza un URI care în mod unic numeste un set de taguri.
prefix: defineste prefixul folosit pentru a distinge o instanta a tag-ului particularizat.

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 câteva actiuni standard:

<jsp:useBean> instantiaza un obiect de tip JavaBean având 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 într-un String pregatind-o pentru afisare

<jsp:include> furnizeaza un mecanism pentru a include resurse statice si dinamice în pagina JSP curenta. Are sintaxa:

sau

<jsp:forward> permite ca un motor JSP sa comunice runtime, cererea curenta catre o resursa statica, Servlet sau alt JSP. Actiunea se termina efectiv când se termina executia paginii curente. Are sintaxa:

sau

<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:

Un exemplu simplu de pagina JSP care combina Script HTML si Beans este cel de mai jos, care afiseaza numele de login al clientului când acesta solicita o pagina prin intermediul unui form HTML:

Pagina contine comenzi sablon, întâlnite în orice pagina HTML si câteva elemente JSP, subliniate. Raspunsul este creat pe baza comenzilor HTML. Când 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, returnând 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 câteva declaratii, comenzi standard (fixed template), actiuni (action instances) cel mai frecvent încuibarite si elemente script. Când 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 server-side. Pe lânga 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 stream-ului 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:

Î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 aplicându-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 câteva 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 script-urilor 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 pâna atunci întâlnirea 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 cînd language are ca parametru java.

session: indica faptul ca pagina implica prezenta unei sesiuni http. Daca valoarea este "true", atunci implicit variabila "session" de tipul javax.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 buffer-ului 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. Ramâne de mentionat ca obiectul Throwable este transferat catre error page implementation prin 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 când 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, având un tag de start, un body si un tag de sfârsit:

Sintaxa unei instructiuni:

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 sfârsit, 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 putând 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, lasând programatorul sa le foloseasca în functie de aplicatia dorita. Exista anumite actiuni standard care sunt folosite în interactiunea cu orice Bean. Un Bean extins, implementând 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

Atât ASP cât 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 când JSP este focalizat pe Java

ASP-ul este deja un produs inclus în Internet Information Server al firmei Microsoft pe când JSP este suportat de servere mult mai puternice

Ce are în plus JSP:

Limbajul Java este mult mai puternic decât 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 raspândit 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 gândire 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 pâna când tehnologia axata pe componente a câstigat 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 încât, valorile, datele si informatiile returnate de aceste componente sǎ poata fi încadrate si aranjate în pagini HTML.

JSP poate fi folosit atât de catre programatorii Java avansati cât si de catre programatorii care n-au o experienta vasta în domeniul programarii Java deoarece acestia pot utiliza componentele pe care cei dintâi 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 sfârsit, sau pot sa aiba un tag gol cu atribute de genul:

sau,

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 sfârseasca î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.

Erorile de translatie

Translatia fisierului sursa printr-un container JSP poate avea loc oricând î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 întâlnim error status code 500 (Server Error).

Erori pe durata procesarii cererilor

De-a lungul procesarii cererilor clientilor pot apǎre 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 rǎspunsurile 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 vǎzut 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 întâi 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 vǎzut 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 întâlnirea unor metode cum ar fi     init() sau destroy().

Constrângerile 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 când pagina JSP este initializata. Când 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, luând în considerare continutul paginii JSP. Metoda este invocata pentru fiecare cerere client.

Request and response parameters

Dupǎ cum s-a vǎzut 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.

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 pǎstreaza 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 decât 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:

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 câteva reserved 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, decât 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, generând o eroare Server Error:

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, afectând 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, putând 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 cât 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 interfata javax.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 a doua metode aditionale atunci când handler-ul manipuleaza body-ul: doInitBody() si doAfterBody().

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 când 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 când este întilnit tag-ul de sfârsit. Rezultatul acesteia indica daca mai este evaluat sau nu ce a mai ramas din pagina. Un caz particular des întâlnit este folosirea unui body gol.

Actiuni cu body

În acest caz sunt invocate metodele doInitBody() si doAfterBody(), definite în interfata BodyTag. Astfel, evaluarea este fǎcuta 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 sfârsit 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 într-un 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 câteva 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 cu PageContext.

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:

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ǎ taglib ce 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 taglib-location. Deci:

taglib: este un subelement al aplicatiei web: <! element web-app . taglib* . >. Acest element are la rândul sau alte doua subelemente si un atribut:

<!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.

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:

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 implementând 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, required?, rtextvalue?)>. Are trei subelemente de forma:

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:

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 si BodyTagSupport. Un tag handler are anumite proprietǎti 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 ramân 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 târziu printr-o variabila script. Metoda getVariableInfo() este folosita pentru a furniza informatii despre fiecare variabila care va fi creata la request time când respectiva actiune este executata. Rezultatul acestei metode este o matrice având 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 sǎu 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 pânǎ la sfârsitul paginii

AT_END - variabila este vizibila dupa tag-ul end al actiunii care o defineste pâna la sfârsitul 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 târziu, 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:

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 constrângeri în legǎtura 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 incluzând 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 constrângerile descrise în TLD sunt obligatorii.

3.3.6. Comparatie JSP - Servleti

Desi JSP-urile pot fi folosite pentru majoritatea scopurilor, exista anumite situatii când 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 atât pentru ciclurile de executie cât 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

Depinzând de componenta echipei de dezvoltare, de constrângerile 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 ramâne 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

Extinderea unei aplicatii SMTP Client utilizând Java Server Pages:

Afisarea unui element multimedia (imagine, sunet, secventa audio - video) citit de la un URL clar stabilit.

Introducerea numelui unui fisier multimedia într-o baza de date realizându-se totodata transferul lui într-un subdirector pe masina unde ruleaza serverul web, dupa vizualizarea continutului acestui fisier.