JavaServer Pages programozóknak

Átírás

1 JavaServer Pages programozóknak Írta: Mika Péter szeptember. Minden jog fenntartva. Tartalomjegyzék 1. BEVEZETÉS A JSP ÉS ELŐNYEI A JSP ELEMEI DIREKTÍVÁK A page direktíva Az include direktíva A taglib direktíva SCRIPT-ELEMEK Deklarációk Script-részletek Kifejezések Implicit objektumok AKCIÓK A standard akciók A <jsp:usebean> akció A <jsp:setproperty> akció A <jsp:getproperty> akció A <jsp:include> akció A <jsp:forward> akció A <jsp:plugin> akció A <jsp:param> akció Saját elemkönyvtárak készítése Elemkönyvtárak használata Egyszerű elemek készítése A törzsüket is feldolgozó elemek készítése Scriptváltozók bevezetése Egymásbaágyazott elemek készítése Bevezetés A JavaServer Pages (a továbbiakban az egyszerűség kedvéért JSP) a Java szervletekhez hasonlóan egy klienstől érkező kérés alapján valamilyen szöveges, leggyakrabban HTML vagy XML formátumú dokumentum dinamikus, szerveroldali előállítására szolgáló technológia, a Java 2 Enterprise Edition (J2EE) része. A Sun hivatalos JSP-vel foglalkozó oldalai a címen érhetők el, innen letölthető a teljes specifikáció, valamint a szintaxist összefoglaló syntax card. (Ez utóbbi különösen jó szolgálatot tehet.) A JSP a szabad szoftverek szellemiségéhez közel álló módon, a Java Community Process keretein belül fejlődik, széles iparági támogatással övezve. Az írás pillanatában a legújabb elfogadott specifikáció az 1.1-es, ami a Servlet API 2.2-es verziójára épül. Ez felülről 1

2 kompatibilis a korábbi 1.0-ás változattal, ami viszont teljesen eltér az előzetes, 0.92 számmal kiadott változattól. (Óvakodjunk az erre épülő termékektől!) Sajnos a specifikáció meglehetősen nehezen olvasható, nyomdahibákban gazdag, helyenként az implementáció részleteibe veszik, helyenként pedig elhallgatja a nyilvánvaló megvalósítás hátterét. Az alábbiakban ezért a JSP előnyeinek rövid összefoglalása után bemutatom a nyelvi elemeket, és egy-két gyakorlati példán keresztül illusztrálom a használatukat. A szervletekkel való kapcsolat jóval szorosabb, mint azt a JSP-ről szóló prospektusok sejtetni engedik, ezért úgy vélem, nem nélkülözhető a szervletek bizonyos szintű ismerete, így a továbbiakban építeni is fogok ezekre az ismeretekre. A szervletekről magyarul a oldalon, illetve a Nyékyné et al.: Java 2 útikalauz programozóknak (ELTE TTK, 1999) című könyvben olvashatunk. A JSP kipróbálásához szükség van egy ún. JSP container-t tartalmazó web- vagy alkalmazáskiszolgálóra. Ehhez a referencia implementáció gyanánt is szolgáló Tomcat-et ajánlom, melyet az Apache project keretében fejlesztenek, és ingyenesen letölthető a címről. A Tomcat egy 100%-ig Javában írt webkiszolgáló, mely szervletek és JSP oldalak futtatására is képes, és mind önállóan, mind más webkiszolgálóknak (Apache, IIS, Netscape) bedolgozva is működtethető. Telepítése (egyszerű bemásolása) után a /bin könyvtárban levő startup script segítségével indítható, és az ugyanitt található shutdown nevű scripttel állítható le. A 3.1 és újabb változatokban a dokumentumhierarchia gyökere a /webapps/root/ könyvtár, mely (alapbeállításként) a címen érhető el. A webszerver teljes forrása mellett a Tomcathez megkapjuk a szervlet és a JSP API-k (javax.servlet.*) JavaDoc dokumentációját, ezt sem kell tehát külön letölteni. Jelen írás szerzője biztos benne, hogy munkája nem mentes sem a hibáktól, sem a hiányosságoktól, így köszönettel fogad minden korrekciót és kiegészítést, továbbá szívesen segít minden, a szervletekkel, a JSP-vel és a Tomcattel összefüggő kérdés megválaszolásában. címe pmika@ludens.elte.hu 2. A JSP és előnyei A JSP oldalak jó megközelítéssel visszájukra fordított szervleteknek tekinthetők: míg a szervletek esetén Java kódban elrejtve szerepelnek a szöveget a kimenetre író utasítások, addig a JSP-nél éppen ellenkezőleg, a rögzített szöveg közé rejtve szerepelnek az oldal tartalmát módosító utasítások. A JSP oldalak tehát inline kódot tartalmazó HTML/XML oldalaknak tekinthetők, ami azért is fontos, mert így az oldal ASP-re vagy JSP-re felkészített webszerkesztő programokkal is manipulálható. A JSP előnyei elsősorban az olyan oldalaknál mutatkoznak, amelyek relatíve sok fix szöveget, és kevés kódot tartalmaznak. A Sun mérnökeinek egyik bevallott célja a JSP megalkotásával az volt, hogy elrejtsék a szervletek írásának nehézségeit a programozásban kevéssé jártasak elől azáltal, hogy szétválasztják az oldal programozási részét a tartalomtól és a designtól. Ez utóbbit ugyanis manapság általában külön tartalomkészítők és webdesignerek készítik, számukra a JSP egyszerű, XML-szerű elemeken keresztül biztosít hozzáférést a szerveroldali komponensekhez (JavaBeans, EJB), elrejtve előlük a tényleges programkódot. A prezentációs- és az alkalmazáslogika ezen szétválasztása a JSP legnagyobb előnye a szervletekhez képest: nem csak munkamegosztást tesz lehetővé, de izolációt is jelent, ugyanis így nem keveredik az oldal tartalma a programkóddal. A kettő így külön-külön fejleszthető a véletlen felülírás veszélye nélkül. Ahhoz hogy megérthessük a JSP és a szervletek közti kapcsolatot, nézzük meg mi is történik egy egyszerű JSP oldalra vonatkozó kérés kiszolgálásakor. Készítsünk egy szokványos szöveges filet a minden programozó szívét megdobogtató Hello World! szöveggel, majd 2

3 mentsük el a webkiszolgáló gyökérkönyvtárába hello.jsp néven. Ha most a böngészőnkkel megpróbáljuk lekérni ezt a dokumentumot, akkor a háttérben következők történnek: 1. A kliens elküldi a kérést a szervernek 2. A web- vagy alkalmazásszerver a.jsp kiterjesztés alapján felismeri, hogy egy JSP filera vonatkozik a kérés, így továbbítja azt a JSP containernek, ami lehet a webkiszolgáló része, vagy külön plug-in. 3. Mivel ez volt az adott dokumentumra vonatkozó első kérés, a JSP fordító (ami a Tomcat esetén Jasper névre hallgat) a.jsp forrásból sorról-sorra haladva előállítja a neki megfelelő java szervlet forrását. 4. A java kódot a javac fordítóval lefordítja egy.class fileba. (Ezért szükséges, hogy a J2SE-beli tools.jar része legyen a CLASSPATH-nak.) 5. Inicializálja a szervletet, majd a szervlet a kérést megkapva előállítja az oldal végleges szövegét. 6. Ami aztán eljut a klienshez. A trükk tehát egész egyszerűen annyi, hogy a JSP egyszerűbb, szövegvezérelt formátumából egy specializált fordító szervlet kódot készít, és valójában ez szolgálja ki a kérést. Ez a plusz fordítás természetesen többletterhet, és lassabb válaszidőt jelent, de csak az első kérés kiszolgálásakor jelentkezik, a további kérések ugyanis már egyenesen a szervlethez továbbítódnak. (Van mód az oldal előfordítására is, így már az első kérés kiszolgálása sem lesz lassabb: ehhez a kérés paraméterei között szerepelnie kell egy jsp_precompile nevűnek üres vagy true értékkel. Az ilyen kérés nem továbbítódik az oldalnak.) Milyen szervlet készült a mi fileunkból? Tomcat esetén a forrás megtalálható a /work könyvtárban, _0002fhello_0002ejsphello_jsp_0.java (vagy hasonló) néven: // import public class _0002fhello_0002ejsphello_jsp_0 extends HttpJspBase static public _0002fhello_0002ejsphello_jsp_0( ) private static boolean _jspx_inited = false; public final void _jspx_init() throws JasperException public void _jspservice(httpservletrequest request, HttpServletResponse throws IOException, ServletException response) JspFactory _jspxfactory = null; PageContext pagecontext = null; HttpSession session = null; ServletContext application = null; ServletConfig config = null; JspWriter out = null; Object page = this; String _value = null; try if (_jspx_inited == false) _jspx_init(); _jspx_inited = true; _jspxfactory = JspFactory.getDefaultFactory(); response.setcontenttype("text/html;charset=8859_1"); 3

4 pagecontext = _jspxfactory.getpagecontext(this, request, response, "", true, 8192, true); application = pagecontext.getservletcontext(); config = pagecontext.getservletconfig(); session = pagecontext.getsession(); out = pagecontext.getout(); // HTML // begin [file="e:\\tomcat\\webapps\\root\\hello.jsp";from=(0,0);to=(1,0)] out.write("hello World!\r\n"); // end catch (Exception ex) if (out.getbuffersize()!= 0) out.clearbuffer(); pagecontext.handlepageexception(ex); finally out.flush(); _jspxfactory.releasepagecontext(pagecontext); Látható, hogy az oldal tényleges szövegét a szervletek service metódusához hasonló _jspservice metódusban lévő sor, az out.write("hello World!\r\n"); állítja elő. Technikailag ez az osztály az absztrakt HttpJspBase osztály leszármazottja, aminek pedig a szintén absztrakt HttpServlet a szülője, innen hát a szervletes örökség. Mint látni fogjuk, a JSP oldal szövegébe helyezett Java kódrészletek változatlanul, egy az egyben bekerülnek a belőle készített szervlet-forrás szövegébe, így a JSP is megőrzi a szervletek egyik nagy előnyét: tetszőleges Java API (pl. a JDBC, az RMI, a JavaMail stb) vagy saját Java osztály meghívható. A szervletes kapcsolatnak köszönhető az is, hogy a JSP-k és a szervletek kiválóan kiegészíthetik egymást: egy JSP oldal könnyen átadhat egy kérést egy szervletnek vagy fordítva (forward), vagy pedig beillesztheti a végeredménybe egy másik szervlet vagy JSP eredményét (include) így egészen bonyolult rendszerek építhetők ki. (A JSP ezt annyiban is segíti, hogy a kimenet (JspWriter osztály) pufferelt, így hiba vagy abortálás esetén az oldalrészlet nem kerül elküldésre.) A jellegzetes architektúrákat illetően lásd a Sun Blueprint Design Guidelines for the J2EE negyedik fejezetét (The Web Tier). A JSP apró, de hasznos többletszolgáltatása a szervletekhez képest, hogy amennyiben kivétel lép fel a feldolgozás alatt lévő oldalon, akkor a kérést a kivétel (java.lang.throwable típusú) objektumával egyetemben átadja a megadott hibakezelő oldalnak, aminek ezért szintén JSP-nek kell lennie. Nem csalódik egyébként, aki arra tippel, hogy ezt a fenti példa catch blokkjában szereplő pagecontext.handlepageexception(ex); sor végzi. A JavaServer Pages értékelésekor nem szabad megfeledkeznünk a Microsoft hasonló igényt kielégítő technológiájáról, az Active Server Pagesről (ASP). Mivel a kettő összevetését már többen is megtették, itt most csak két olyan weblapot ajánlanék, amelyeken részletesen olvashatunk a témáról: az egyik az ASPToday, a másik a JSPInsider. Ez utóbbi oldalon előfizethetünk a JSPBuzz hírlevélre is, mely kétheti rendszerességgel ismerteti az egyre táguló JSP-univerzum eseményeit. 4

5 3. A JSP elemei A gyakorlatban minden sokkal egyszerűbb, mint ahogy az a fenti leírásból tűnhet, a JSP oldal szerzője ugyanis ideális esetben soha nem találkozik az oldalból készülő szervlettel, a JSP elemeivel pedig elvileg minden megoldható, ami szervletekkel. Miket tartalmazhat tehát egy JSP oldal? Az oldalban néhány kivételtől eltekintve- tetszőleges számban és tetszőleges helyen előfordulhatnak JSP nyelvi elemek, melyek háromfélék lehetnek: direktívák, script-elemek, és akcióelemek. Minden olyan literál, amit a JSP fordító nem ismer fel, a whitespaceket is megőrizve egy az egyben bekerül az előállított oldal szövegébe. A JSP saját elemeinek egy rész XML-szerű tag, egy része viszont a könnyebb gépelhetőség kedvéért az XML konvencióktól eltérő, egyszerűbb jelölést használ. Éppen ezért a JSP oldalak nem XML dokumentumok, noha létezik egy szabványos átírás, mellyel az XML specifikációnak is megfelelő formára hozhatók. (Lásd a specifikáció hetedik fejezetét.) A JSP nyelvi elemeire is igaz ugyanakkor, hogy a kis- és a nagybetűk különbözőnek számítanak. Fontos különbség azonban, hogy a JSP-nek saját kommentje van, ennek formája a következő: <%-- Ez egy JSP komment --%> Ez a fajta komment használatos magának a JSP oldalnak a kommentálására, mert az így megjelölt szövegrészek nem kerülnek bele az előállított oldalba, ellentétben például az XML kommentekkel, amik rendes szövegként továbbadódnak a kliensnek. (Aki aztán vagy felhasználja a kommenteket, vagy sem.) A kommentálás egy harmadik lehetséges módja, hogy az oldalban használt scriptnyelv kommentjeit használjuk, ezek értelemszerűen szintén nem adódnak tovább. 3.1 Direktívák A direktívák a JSP containernek szóló utasítások, közös jellemzőjük, hogy <%@ direktiva-nev attr1= ertek1 attr2= ertek2 %> alakúak, és nem módosítják az előállított oldal szövegét A page direktíva Mint azt a neve is sugallja, a page direktívával az egész oldalra vonatkozó jellemzőket állíthatjuk be. A page direktíva a fordítási egységben (ami az adott oldal és az include direktívával beillesztett oldalak egésze) akárhányszor és akárhol előfordulhat, de az import kivételével minden attribútumnak csak egyszer adhatunk értéket. Az attribútumok és lehetséges értékeik a következők: language: A script-részletekben, kifejezésekben, és deklarációkban használt programozási nyelv neve. Az 1.1-es specifikáció a JSP containerek számára csak a java érték elfogadását teszi kötelezővé, csak erre az esetre vonatkozóan tartalmaz előírásokat, és egyben ez az alapértelmezés is. (Noha a specifikáció terminológiáját követve scriptekről beszélek, itt nem JavaScriptről, hanem a "valódi" Javáról van szó!) Érdemes megemlíteni, hogy létezik egy, az IBM Bean Scripting Frameworkjén (BSF) alapuló kezdeményezés, amelynek révén akkor is használhatunk más nyelven (Netscape Rhino (Javascript), VBScript, Perl, Tcl, Python, 5

6 NetRexx, Rexx) írt kódrészleteket, ha a JSP container ezt közvetlenül nem támogatja. További információkért lásd a Jakarta Taglibs alprojektet. extends: Megadja, hogy a JSP oldalból készült osztály melyik osztálynak legyen a leszármazotta. Lehetőleg ne használjuk, mivel a Java egyszeres öröklődése miatt ezzel erősen korlátozzuk a JSP fordító lehetőséget. (Lásd a specifikáció fejezetét a tekintetben, hogy mit kell tudnia saját szülőosztálynak.) import: Ezzel az attribútummal az oldalból készülő szervlet import listáját egészíthetjük ki, aminek a specifikáció szerint eleve tartalmaznia kell a java.lang.*, javax.servlet.*, javax.servlet.jsp.* és a javax.servlet.http.* csomagokat. (Ennél többet is tartalmazhat, lásd a Hello, World! példát.) Az attribútum értéke (language="java" esetén) Java típusok, illetve csomagok vesszővel elválasztott listája. session: true vagy false értéke adja meg, hogy az oldalban akarunk-e sessiont használni. Az alapbeállítás a true, ilyenkor használhatjuk a session implicit változót. Az implicit változókról lásd buffer: Ezen attribútum értéke szabja meg az implicit out változó pufferelésének módját: none esetén nincs pufferelés, minden közvetlenül kiíródik a ServletResponse PrintWriter objektumára, ha pedig egy pufferméretet adunk meg (xxxkb), akkor minden egy pufferbe íródik, mielőtt elküldésre kerülne. Az alapértelmezés 8kb. autoflush: Amennyiben pufferelést kértünk eldönti, hogy mi történjen a puffer megtelése esetén. Az alapértelmezett true beállítás esetén a puffer automatikusan ürül, ha megtelik, false esetén ilyenkor exception váltódik ki. (Ez utóbbi például akkor lehet hasznos, ha a kliens maga is alkalmazás, és nem egy böngésző.) isthreadsafe: Ezzel adhatjuk meg, hogy oldalunk fel van-e készítve arra, hogy egyszerre több kérést szolgáljon ki párhuzamosan, vagy sem. Az alapértelmezett true esetén a JSP container egyszerre több kérést is átadhat az oldalnak, míg false választása esetén a kérések sorbaállítódnak, és egyenként kapja meg őket az oldal. (A gyakorlatban ennek megvalósítása a javax.servlet.singlethreadmodel interface implementálásával zajlik.) info: Ennek segítségével adhatjuk meg az oldal rövid leírását, a Servlet.getServletInfo megfelelője. errorpage: A bevezetőben említett kivételkezelési mechanizmus része: annak a JSP oldalnak az URL-je, amelyikhez az oldalban esetleg fellépő java.lang.throwable osztályú kivételt továbbítani szeretnénk. Ennek gyakorlati megvalósítása is elég triviális: a kivételkezelő oldal a kivételt a ServletRequest objektum javax.servlet.jsp.jspexception nevű paramétereként kapja meg. iserrorpage: A kivételkezelő oldal esetén állítsuk az értékét true-ra, és akkor a megkapott kivétel elérhetővé válik az implicit exception változón keresztül. contenttype: Megadja az oldal MIME típusát és karakterkódolását, "TYPE" vagy "TYPE;charset=CHARSET" formátumban. Az alapértelmezés "text/html;charset=iso ". Mivel a dokumentumtípust egy direktíva határozza meg, ezért dinamikusan nem állítható. Ha ilyesmit szeretnénk, akkor célszerű egy olyan JSP oldalt készíteni, amelyik a kérés paraméterei alapján a megfelelő típusú dokumentumot előállító szervletre/jsp oldalra irányítja a kérést Az include direktíva Az include direktíva adott file (nem feltétlenül JSP) fordítás előtti beillesztésére szolgál. A beillesztés statikus, a megadott file byteról bytera másolódik be. (Dinamikus, minden egyes kérés kiszolgálásakor kiértékelődő beillesztés a jsp:include akció-elemmel lehetséges. Lásd 6

7 ) A specifikáció szerint a JSP implementációk nem kötelesek automatikusan újrafordítani az oldalt az include file megváltozásakor. A direktíva egyetlen attribútuma a file, értéke egy filera mutató relatív URL A taglib direktíva A JSP által felismert akció-elem készlet kibővíthető saját tagekkel, melyek könyvtárakba rendezhetők (custom tag library). A taglib direktíva segítségével adhatjuk meg a JSP fordító számára, hogy hol keresse a saját elemeinket definiáló tag library descriptor-t. A direktívának még az első saját elem előfordulása előtt szerepelnie kell. Két attribútuma közül a uri adja meg az elemkönyvtárat azonosító szimbolikus vagy tényleges URI-t, a prefix pedig azt a prefixet, amit egy kettősponttal elválasztva a saját elemeink neve elé kell majd tennünk, ahhoz, hogy hivatkozni tudjunk rájuk, pl. <prefix:nev attrnev="ertek" /> vagy <prefix:nev attrnev="ertek" > törzs </ prefix:nev> A prefixek célja a névterek szétválasztása, amire azért van szükség, mert egy oldalba taglib direktívákkal tetszőleges számú elemkönyvtárat "importálhatunk". A saját elemkönyvtárak készítéséről bővebben lásd a fejezetet. 3.2 Script-elemek A JSP 1.1 specifikáció háromféle script-elemet definiál: használhatunk deklarációkat, script-részleteket, és kifejezéseket. Mivel mindhárom az oldal scriptnyelvén alapul, ezért ezek pontos jelentése függ a használt nyelvtől is. Továbbiakban csak a Java esetéről lesz szó. A scriptelemek szintaxisa megtévesztésig hasonló: <%! deklaráció %> <% script-részlet %> <%= kifejezés %> Deklarációk A deklaráció elnevezés kissé megtévesztő, mert változókat deklarálni script-részletek belsejében is lehet, metódusokat viszont nem. Ennek magyarázata az, hogy míg a script részleteket a JSP fordító a készülő szervlet _jspservice metódusába, az aktuális helyre teszi, addig a deklarációk a szervlet metódusain kívülre másolódnak, tehát osztály szintű változókat, illetve metódusokat hoznak létre. Deklaráció révén van lehetőségünk a szervlet init, illetve destroy metódusának átdefiniálására. Ehhez deklarálnunk kell a jspinit, illetve jspdestroy metódusokat. (A szervletek init és destroy metódusával ellentétben egyik sem engedi meg exception dobását.) Más szervlet metódust nem definiálhatunk át, továbbá foglaltak a jsp, _jsp, 7

8 jspx és _jspx kezdetű metódusnevek, így természetesen _jspservice nevű metódust sem deklarálhatunk Script-részletek Az előzőekben elmondottak alapján a script-részletek (scriptlet-ek) egy az egyben bekerülnek a _jspservice metódus forrásába, mégpedig a JSP oldalban elfoglalt helyüknek megfelelő helyre. A script-részletek tetszőlegesen keveredhetnek az oldal szövegével, de egybeolvasva őket az adott nyelven értelmes kódot kell, hogy kapjunk. Érdemes megnézni a specifikáció példáját: <%@ page import="java.util.calendar" %> <% if (Calendar.getInstance().get(Calendar.AM_PM) == Calendar.AM) %> Kellemes delelottot! <% else %> Kellemes delutant! <% %> a kapott kód _jspservice metódusa, melyet az áttekinthetőség kedvéért megtisztítottam a fordító (Tomcat/Jasper 3.2 beta) kommentjeitől: public void _jspservice(httpservletrequest request, HttpServletResponse throws IOException, ServletException response) JspFactory _jspxfactory = null; PageContext pagecontext = null; HttpSession session = null; ServletContext application = null; ServletConfig config = null; JspWriter out = null; Object page = this; String _value = null; try if (_jspx_inited == false) _jspx_init(); _jspx_inited = true; _jspxfactory = JspFactory.getDefaultFactory(); response.setcontenttype("text/html;charset=8859_1"); pagecontext = _jspxfactory.getpagecontext(this, request, response, "", true, 8192, true); application = pagecontext.getservletcontext(); config = pagecontext.getservletconfig(); session = pagecontext.getsession(); out = pagecontext.getout(); out.write("\r\n\r\n"); if (Calendar.getInstance().get(Calendar.AM_PM) == Calendar.AM) out.write("\r\nkellemes delelottot!\r\n"); else out.write("\r\nkellemes delutant!\r\n"); out.write("\r\n"); catch (Exception ex) if (out.getbuffersize()!= 0) out.clearbuffer(); pagecontext.handlepageexception(ex); finally out.flush(); 8

9 _jspxfactory.releasepagecontext(pagecontext); Jól látszik, hogy az általunk írt kód egy az egyben bemásolódott, és közéékelődtek a JSP fordító által előállított egyéb programsorok, amik itt kivétel nélkül out.write hívások Kifejezések A kifejezések olyan script-nyelvi elemek, amelyeket a fordító String típusra hozhat, és közvetlenül a kimenetre írhat. Az eddigiek alapján könnyen rájöhetünk, hogy a Java esetén ez hogyan zajlik: a <%= és a záró %> közti részt a JSP fordító egy out.write hívás paramétereként használja. Például: Az ido jelenleg <%= System.currentTimeMillis () %> milliszekundum (UTC). JSP sorból az alábbi három Java kódsor áll elő: out.write("az ido jelenleg "); out.print( System.currentTimeMillis () ); out.write(" milliszekundum (UTC).\r\n\r\n"); A típuskonverzió sikertelensége esetén a fordításkor hibaüzenetet kapunk, vagy a futtatáskor ClassCastException váltódik ki Implicit objektumok A programozó munkáját megkönnyítendő a JSP oldalba írt script-részletekben és kifejezésekben használhatók az előre deklarált ún. implicit objektumok. (Ez természetesen azt is jelenti, hogy ilyen nevű változókat külön már nem deklarálhatunk.) Többségük a szervletekkel foglalkozók számára már bizonyára közel sem ismeretlen. Az egyes osztályok adattagjainak és metódusainak tekintetében ajánlott a javax.servlet.* és alcsomagjai dokumentációjának tanulmányozása. Röviden összefoglalva: Név Típus Rövid leirás request javax.servlet.servletrequest vagy valamely leszármazottja pl. javax.servlet.httprequest A kérés objektuma. Figyelem: a jsp kezdetű kérés-paraméternevek response javax.servlet.servletresponse vagy valamely leszármazottja pl. javax.servlet.httpresponse foglaltak! A válasz objektuma. (Figyelem: tilos közvetlenül a kimenetre írni! Helyette az out implicit objektumot kell használni.) pagecontext javax.servlet.jsp.pagecontext A JSP központi objektuma, összefogja a névtereket (page, request, session, application), lásd 9

10 az első példát. Saját akciók definiálásakor kap jelentős szerepet. session javax.servlet.http.httpsession A session objektuma. Csak HTTP protokoll és session="true" esetén deklarált. Lásd application javax.servlet.servletcontext A szervlet környezetét jelképező objektum, az eltérő elnevezés ellenére megegyezik a getservletcontext visszaadott értékével. out javax.servlet.jsp.jspwriter A JSP oldal kimenete, a ServletRequest PrintWriter objektuma helyett a programozónak is ide kell írni minden, a kliensnek szánt szöveget. Fontos tudni, hogy az akciók törzsének feldolgozása során egy ideiglenes kimenetre mutat. config javax.servlet.servletconfig A szervlet ServletConfig objektuma, megegyezik a getservletconfig visszatérési értékével. page java.lang.object Az oldalt megvalósító szervlet objektuma, Java esetén megegyezik a this értékével. exception java.lang.throwable Hibakezelő oldal (iserrorpage="true") esetén a fellépett kivétel objektuma. Lásd A script-elemek használatának demonstrálására nézzünk egy gyakori problémát: az oldal látogatottságát mérő számláló készítését. A JSP eszközeivel a triviális megoldás az, hogy deklarálunk egy osztályszintű változót, amit minden kérés kiíráskor növelünk egyszer: <%! private int counter; %> A szamlalo allasa: <%= counter++ %> A megvalósítás hibája, hogy a számláló értéke elvész, ha megváltoztatjuk az oldalt (például mert változik a szöveg vagy a design), és az oldalt újra kell fordítani. Célszerű tehát eltárolni a számláló értékét az alkalmazás-környezetben (application context), hiszen ez túléli az alkalmazás egyes szerveleteinek megsemmisítését és újraindítását: <%! public final static String counterkey = "mypage_counter"; 10

11 private int counter; public void jspinit () ServletContext context = getservletcontext (); Object storedobject = context.getattribute (counterkey); if (storedobject!= null) try counter = ((Integer) storedobject).intvalue (); catch (Exception e) System.err.println ("Invalid counter object in application scope."); %> public void jspdestroy () ServletContext context = getservletcontext (); context.setattribute (counterkey, new Integer (counter)); A szamlalo tarolt erteke: <%= (Integer) application.getattribute (counterkey) %> A szamlalo mostani allasa: <%= counter++ %> A felültdefiniált init és destroy metódusokban történik a tárolt érték lekérdezése, illetve az új érték elmentése. Ezekben a metódusokban még nem hivatkozhatunk az implicit application objektumra, mert az implicit objektumok csak a _jspservice eljárás törzsében deklarálódnak. A megoldás továbbfejleszthető az oldalszámláló állásának perzisztens tárolásával (fileban, adatbázisban stb.), ekkor a számláló értéke a szerver leállása esetén sem veszik el. 3.3 Akciók Az eddig leírtak alapján bizonyára a tisztelt Olvasóban is felmerült már a kétség: mi szükség van a JSP-re, ha -azon túl, hogy kényelmesebben szerkeszthető- lényegében a szervletek egyfajta átírása? Hogy fogja beváltani azt a bevezetőben még hozzá fűzött reményt, hogy segítségével a Javában, vagy általában a programozásban kevéssé jártasak is kezelhessenek különféle szerveroldali komponenseket? A választ kisebb részben a JSP saját akciói adják, az igazi előrelépést ezen a téren mégis az 1.1-es specifikáció jelentette. Ekkor jelent meg a JSP nyelvi kiterjesztésének a lehetősége: a programozók saját akciókat definiáló custom tag librarykat írhatnak, egyszerű elemek mögé rejtve a máskülönben az oldalban terpeszkedő kódrészleteket. A saját akciók mögött egy-egy Java osztály áll, mely felhasználhatja, és általában fel is használja az attribútumok értékeit valamint az implicit objektumok (például a kérés) paramétereit, és ezek alapján valamilyen szerveroldali feladatot végez el, ír a kimenetre, esetleg új script-változókat is definiál. Az akciók a kód elrejtésén túl a kód újrafelhasználásában is fontos szerepet játszanak, mivel a JSP más elemeihez hasonlóan egy oldalon belül is azonos vagy eltérő paraméterezéssel- tetszőlegesen sokszor felhasználhatók. A standard és saját akciók (actions) használata nem programozói lelkületűek számára sem jelenthet gondot, hiszen XML-szerű szintaxist követnek. (Standard akciók esetén a prefix jsp, saját akcióinkhoz a taglib direktíva révén választhatunk prefixet. Lásd 3.1.3) Az akciók által használt szintaxist azért neveztem XML-szerűnek, mert némileg bővebb annál: lehetőséget ad arra, hogy bizonyos attribútumok értékeként kifejezést adjunk meg, amelyik csak futásidőben értékelődik ki. 11

12 3.3.1 A standard akciók A <jsp:usebean> akció A jsp:usebean akció többféle funkciót egyesít, emiatt sajnos sem a szintaxisa, sem a használata nem nevezhető triviálisnak. Lényege, hogy megpróbálja megkeresni a megadott névtérben (scope) megadott néven (id) szereplő objektumot, és az oldal script nyelve számára szintén id néven elérhetővé tenni, type típusúra kényszerítve. (Az id attribútum tehát kettős szerepet játszik és az adott script-nyelv változó-elnevezési konvencióinak is meg kell felelnie!) Használható ugyanakkor objektumok, illetve JavaBeanek példányosítására is, ugyanis ha a keresés nem jár sikerrel, akkor a class vagy a beanname attribútumok alapján megkísérli példányosítani az adott osztályt, elhelyezi a kapott objektumot a scope névtérben és az id értékeként megadott néven a scriptnyelv számára is elérhetővé teszi az új objektumot. Kötelező értéket adni az id attribútumnak, valamint a type és a class attribútumok közül legalább az egyiknek. Az id a keresett, illetve deklarálandó változó neve, a scope lehetséges értékei pedig a következők: page request session application A nevezett objektumot az oldal javax.servlet.jsp.pagecontext objektumában keresi, illetve az új objektumot ott tárolja. Az ilyen objektumok élettartama az oldal egyetlen lefutásának ideje. Ez a scope alapértelmezett értéke is egyben. Az objektumot a kérés javax.servlet.servletrequest objektumában keresi, illetve az új objektumot abban tárolja el. Az ilyen objektumok élettartama a kérés kiszolgálásának befejezéséig tart. (Forward vagy include használata esetén ez eltérhet a page scope élettartamától!) Az objektumot a felhasználóhoz kötödő javax.servlet.http.httpsession objetumban keresi, illetve az új objektumot ott tárolja el. A session élettartama a session lejártával, a session érvénytelenítésével, vagy az alkalmazás terminálásával ér véget. Az objektumot az egész web-alkalmazáshoz tartozó javax.servlet.servletcontext objektumban keresi, illetve az új objektumot ott tárolja el. Az ilyen objektumok élettartama megegyezik az egész web-alkalmazás élettartamával. Fontos, hogy distributable web-alkalmazás esetén minden JVM külön ServletContextet használ, így a globális adatok megosztására valamilyen más mechanizmust (pl. adatbázist) kell használni. A type és a class értéke Java osztálynév lehet (nem kötelezően JavaBean!), a beanname értéke egy, a java.beans.beans osztály instantiate metódusával példányosítható JavaBean neve kell hogy legyen. Nem adható meg egyszerre beanname és class, és ha a type és a class is meg van adva, akkor a class a Java szabályai szerint értékül adható kell, hogy legyen type-nak. A beanname értéke futásidőben kiértékelődő kifejezés is lehet. 12

13 A teljes káoszt megelőzendő érdemes a specifikációból pontosan is idézni a jsp:usebean teljes hatásmechanizmusát: 1. Az id és a scope alapján megpróbálja megkeresni az adott objektumot az adott névtérben. 2. Az oldal scriptnyelvében deklarál egy változót id néven és type típussal, amennyiben ez utóbbi definiált, különben pedig class típussal. 3. Ha az objektumot megtalálta az adott néven és az adott hatókörrel, akkor típuskényszerítéssel type típusúra hozza és értékül adja a létrehozott változónak. (Ha a típuskényszerítés sikertelen, akkor java.lang.classcastexception lép fel, és a jsp:usebean feldolgozása véget ér.) A jsp:usebean elem törzse eldobódik, és ezzel az elem feldolgozása véget ér. 4. Ha az objektum nem volt megtalálható, és se a class, se a usebean attribútum nem volt megadva, akkor egy java.lang.instantionexception kivétel dobásával a feldolgozás véget ér. 5. Ha az objektum nem volt megtalálható, és a class attribútum értékeként megadott osztály rendelkezik nyilvános, argumentum nélküli konstruktorral, akkor példányosítja, az új objektumot értékül adja a script-változónak, és elhelyezi a scope által meghatározott névtérben, majd a 7. pontnál folytatja. Ha a megadott osztály nem példányosítható (absztrakt, interface, vagy nincs megfelelő konstruktora), akkor a feldolgozás egy java.lang.instantionexception dobásával ér véget. 6. Ha az objektum nem volt megtalálható, és a beanname attribútum adott, akkor meghívja a java.beans.beans osztály instantiate metódusát a szervlet ClassLoaderével és a megadott névvel. Amennyiben sikerrel jár, akkor az előzőhöz hasonlóan az új objektumot értékül adja a script-változónak, és elhelyezi a scope által meghatározott névtérben, majd a 7. pontnál folytatja. 7. Ha a jsp:usebean törzse nem üres, akkor feldolgozza. A törzsben lévő script-elemek számára az új változó már elérhető. A jsp:usebean két jellemző felhasználására álljon itt két példa. Az egyik eset, amikor valamelyik névtérben eltárolt, már meglévő objektumot szeretnénk scriptből is elérhetővé tenni. Ilyenkor az id és scope attribútumokon kívül csak a type-nak kell értéket adni. <jsp:usebean id="vect" scope="request" type="java.util.vector" /> Ebben az esetben a vect nevű java.util.vector típusú objektumnak szerepelnie kell a kérés paraméterei között, ellenkező esetben hibát kapunk. Az ebből a sorból generált kód (Tomcat/Jasper 3.2 beta): // begin [file="e:\\tomcat\\webapps\\root\\hello.jsp";from=(0,0);to=(0,65)] java.util.vector vect = null; boolean _jspx_specialvect = false; synchronized (request) vect= (java.util.vector) pagecontext.getattribute("vect",pagecontext.request_scope); if (vect == null) throw new java.lang.instantiationexception ("bean vect not found within scope "); if(_jspx_specialvect == true) // end // begin [file="e:\\tomcat\\webapps\\root\\hello.jsp";from=(0,0);to=(0,65)] 13

14 A jsp:usebean másik gyakori alkalmazása, amikor egy új objektumot szeretnénk létrehozni. Az id és scope attribútumok mellett ilyenkor vagy a class-nak vagy beanname-nek és a type-nak kell szerepelnie: <jsp:usebean id="vect" scope="request" class="java.util.vector" /> vagy <jsp:usebean id="vect" scope="request" type="java.util.list" beanname="java.util.vector" /> A Tomcat/Jasper 3.2 beta némileg meglepő módon a kettőből azonos kódot készít, azzal a különbséggel, hogy az utóbbi esetben a type értékét felhasználja típuskonvertálásra: // begin [file="e:\\tomcat\\webapps\\root\\hello.jsp";from=(0,0);to=(0,91)] java.util.list vect = null; boolean _jspx_specialvect = false; synchronized (request) vect= (java.util.list) pagecontext.getattribute("vect",pagecontext.request_scope); if ( vect == null ) _jspx_specialvect = true; try vect = (java.util.list) Beans.instantiate(this.getClass().getClassLoader(), "java.util.vector"); catch (Exception exc) throw new ServletException (" Cannot create bean of class "+"java.util.vector"); pagecontext.setattribute("vect", vect, PageContext.REQUEST_SCOPE); if(_jspx_specialvect == true) // end // begin [file="e:\\tomcat\\webapps\\root\\hello.jsp";from=(0,0);to=(0,91)] // end A <jsp:setproperty> akció A jsp:usebean akcióval, vagy script-elemmel létrehozott beanek tulajdonságainak beállítását szolgálja a jsp:setproperty akció. Két kötelező attribútuma a name, és a property, előbbi a kérdéses bean neve (ami megegyezik a jsp:usebean id attribútumának értékével, ha azzal hoztuk létre), utóbbi a beállítandó tulajdonság neve. A property értékeként megadható "*" is, ez esetben minden olyan property értéke automatikusan beállítódik a megfelelő setproperty () metódussal, amelyikhez a ServletRequest objektumban azonos néven tárolva van valamilyen nemüres érték. (Ez jól használható formok paramétereit tároló beanek feltöltésére). Ugyanez a mechanizmus játszódik le egyetlen propertyvel, ha a property értékeként egy konkrét property nevét adjuk meg, és nem írunk harmadik attribútumot. Mindkét esetben konvertálódik a requestben tárolt érték, ha szükséges. Harmadik attribútumként megadható a param, amit akkor kell használni, ha a ServletRequest-ben a property nevétől eltérő kulccsal van tárolva az érték. Végül, de nem utolsó sorban a value paraméter megadásával tetszőleges, akár futásidőben számolt értéket is adhatunk az adott propertynek. Összefoglalva a lehetséges szintaxisok: <jsp:setproperty name="beannev" property="*" /> 14

15 <jsp:setproperty name="beannev" property="propertynev" /> <jsp:setproperty name="beannev" property="propertynev" param="parameternev" /> <jsp:setproperty name="beannev" property="propertynev" value="ertek" /> A <jsp:getproperty> akció A jsp:getproperty, mint a neve is mutatja, a jsp:setproperty párja: a jsp:usebean akcióval, vagy valamilyen script-elemmel létrehozott bean valamely tulajdonságának a lekérdezésére szolgál. A name attribútum értékeként megadott névvel rendelkező bean property nevű tulajdonságát kérdezi le a megfelelő getproperty () metódussal, és írja ki a println metódusnak megfelelő konverzió után a JSP oldal szabványos kimenetére (azaz az implicit out objektumba). Példa jsp:setproperty és jsp:getproperty használatára: <jsp:usebean id="date" class="java.util.date" /> A date altal tarolt ido <jsp:getproperty name="date" property="time" /> ms (UTC). <% Thread.sleep (10); %> <jsp:setproperty name="date" property="time" value="<%= System.currentTimeMillis () %>" /> A date altal tarolt ido a beallitas utan <jsp:getproperty name="date" property="time" /> ms (UTC). Az első sorban az alapértelmezett "page" hatókörrel létrehozunk egy date nevű, java.util.date osztályú objektumot, a második sorban lekérdezzük ennek time nevű tulajdonságát. Majd a harmadik sorban elaltatjuk a szervletet 10 ms ideig, a negyedikben pedig a jsp:setproperty segítségével frissítjük a date által tárolt időt. Végül újra lekérdezzük a most beállított attribútum értékét, ami ha a futtató környezet elég gyors volt éppen 10 milliszekundummal nagyobb értéket eredményez A <jsp:include> akció A komplex JSP oldalak -önmagukban is funkcionális- egységekre bontásának legfontosabb eszköze a jsp:include akció: segítségével az oldal adott pontján beilleszthetjük egy másik szervlet vagy JSP oldal futásának eredményét. Az include direktívához hasonlóan a jsp:include akcióval is lehetséges statikus erőforrások beszúrása, lényeges különbség viszont, hogy míg a direktívában megjelölt file a fordítás előtt kerül be az oldal szövegébe (így a benne levő JSP elemek is érvényre jutnak), az akcióval beszúrt statikus file viszont a kérés kiszolgálásakor, utólag illesztődik bele a készülő oldal szövegébe. A jsp:include leggyakoribb felhasználása mégis a szervletek/jsp oldalak eredményének a beszúrása: az akció hatására ilyenkor kiűrítődik a puffer, majd meghívódik a RequestDispatcher osztály include metódusa, aminek visszatérése után folytatódik az oldal feldolgozása. Így a meghívott szervletre, illetve JSP oldalra az include metódusra érvényes korlátozások vonatkoznak, azaz nem állítgathatja sem a válasz headerjeit, sem a response code-ot. (Az ezzel probálkozó utasításokat a container figyelmen kívül hagyja.) További megszorítás, hogy jsp:include nem szerepelhet más akció (standard vagy saját) törzsében, az out implicit objektum ugyanis ilyenkor nem az oldal JspWriter objektumára mutat. A jsp:include kötelező page attribútumának kell értékül adni a beillesztendő erőforrás relatív URL-jét, ami lehet kifejezés futásidejű eredménye is, a szintén kötelező flush attribútum értéke minden esetben true kell, hogy legyen. Az elem törzsében lehetnek jsp:param akciók, ekkor a kérés kiegészül az ezekben megadott paraméterekkel, mielőtt a kívánt erőforrásnak 15

16 átadódna. (Ezeknek az értékeknek precedenciájuk van a hasonló kulccsal tárolt értékekkel szemben, de a visszatérés után törlődnek a kérésből.) A szintaxis tehát a következő: <jsp:include page="url" flush="true"/> vagy <jsp:include page="url" flush="true"> <jsp:param name="nev" value="ertek" /> </jsp:include> A <jsp:forward> akció A feladatmegosztás másik eszköze a jsp:forward akció, melynek révén a kérést továbbadhatjuk egy másik statikus erőforrásnak, szervletnek, vagy JSP oldalnak. Leggyakoribb alkalmazása egy olyan architektúra, amelyben egy ún. front component (szervlet vagy JSP) vizsgálja meg a beérkező kérést, majd annak paraméterei függvényében továbbítja azt valamelyik JSP oldalnak. (Például ha a kérés egy bejelentkezés adatait tartalmazta, és a bejelentkezés sikeres, akkor az ezt igazoló oldalnak adódik át a kérés, ha pedig sikertelen, akkor ismét a bejelentkező adatait rögzítő oldal kapja meg a kérést). A jsp:forward elem feldolgozásakor a puffer tartalma törlődik, ha pedig nem volt pufferelve az oldal, és már írt a kimenetre, akkor java.lang.illegalstateexception váltódik ki. A kérés továbbítása után az oldal feldolgozása véget ér. A jsp:forward egyetlen paramétere a page, aminek az erőforrás relatív URL-jét kell értékül, ez lehet valamilyen kifejezés futásidejű kiértékelésének eredménye is. Az elem törzsében lehetnek jsp:param akciók, ekkor a kérés kiegészül az ezekben megadott paraméterekkel, mielőtt továbbítódna. (Ezeknek az értékeknek precedenciájuk van a hasonló kulccsal tárolt értékekkel szemben.) A szintaxis tehát igen egyszerű: <jsp:forward page="url" /> vagy <jsp:forward page="url" > <jsp:param name="nev" value="ertek" /> </jsp:forward> A <jsp:plugin> akció A jsp:plugin már nem szorosan a JSP funkcióihoz kötődik, inkább felcsillant valamit a saját akciók lehetőségeiből: beilleszti az oldal szövegébe azt a megjegyezhetetlenül bonyolult HTML-kódot, ami ahhoz kell, hogy a böngésző letöltse egy applet vagy bean indításához szükséges plug-int, és lefutassa azt. A type attribútum értéke "applet" vagy "bean" adja meg a futtatandó komponens típusát, a szintén kötelező code és codebase, illetve az opcionális name, title, align, archive, width, height, hspace, vspace attribútumok a HTML specifikáció szerintiek. A jreversion jelzi a futtatáshoz szükséges JRE verziószámát, alapértelmezés szerinti értéke 1.1. Az opcionális nsplugin és iepluginurl attribútumok adják meg a letöltendő plugin URL-jét Netscape Navigator és Internet Explorer esetén, ezek alapértelmezése implementációfüggő. A jsp:plugin elem törzsében lehet egy paraméterek nélküli 16

17 jsp:params elem, ennek a törzsében kell elhelyezni a futtatandó applet paramétereit beállító jsp:param elemeket. A jsp:plugin tartalmazhat továbbá egy jsp:fallback nevű, attribútumokkal szintén nem rendelkező elemet, ami azt a HTML szöveget adja meg, amit a böngésző a plug-in sikertelen futtatása esetén jelenít meg. Egy példa a J2SE MoleculeViewer appletjének felhasználásával: <html> <head> <title> Molecule Viewer </title> </head> <body> <jsp:plugin type="applet" code="xyzapp.class" codebase="/" width="300" height="300"> <jsp:params> <jsp:param name="model" value="models/hyaluronicacid.xyz" /> </jsp:params> <jsp:fallback> <b> Unable to start plugin! </b> </jsp:fallback> </jsp:plugin> </body> </html> A <jsp:param> akció A jsp:param a jsp:include, jsp:forward, és jsp:plugin akciók törzsében szerepelhet, célja kulcs-érték párok egymáshoz rendelése, az akciók paraméterezése. Két kötelező attribútuma a name és a value, ez utóbbi értéke kifejezés is lehet Saját elemkönyvtárak készítése és használata A JSP legújabb és legígéretesebb területe a saját akció-elemek, illetve elemkönyvtárak (custom tag library) készítése. Egyben ez a terület, ahová manapság a legtöbb fejlesztés összpontosul. Szükség is van rá, mivel a technikai megvalósítás meglehetősen bonyolultra sikeredett: a specifikáció kiötlői egy újabb réteget vontak a már amúgy is a sokadik absztrakciós szintet jelentő JSP oldalak fölé. Ez persze egészen addig nem jelent gondot, amíg nem szembesülünk a hibakeresés szépségeivel Amilyen nehéz téma a saját tag-ek készítése, olyan könnyű a felhasználásuk, mint azt rövidesen látni fogjuk. Ennek a kettősségnek az oka az, hogy a specifikáció írói a szerveroldalon ténykedő programozóknak szánták az elemkönyvtárak készítésének feladatát, az internetes tartalmak szerzőinek pedig az elemek felhasználását. A kitalálók reménye az, hogy a szerveroldali termékek készítői saját elemkönyvtáraikon keresztül nyújtanak majd hozzáférést a termékeik funkcionalitásához, illetve hogy aki hasznos, gyakori problémát megoldó elemet készít az az internet révén megosztja azt a programozói közösséggel, és így ez a mechanizmus a JSP kód megosztásának és újrafelhasználásának globális eszköze lehet. Ezt segíti az elemkönyvtárak kettős hordozhatósága: az oldal programozási nyelvétől függetlenül, tetszőleges készítőtől származó JSP containerben felhasználhatóak. Mielőtt egy mély lélegzetvételt követően fejest ugranánk az elemkönyvtárak készítésének és felhasználásának rejtelmeibe, érdemes megemlíteni egy alternatív megoldást, a Resin servlet/jsp container által támogatt XML Template Pages (XTP) technológiát. Bár új nevet kapott, ez lényegében az XSL egy innovatív felhasználása, ennek segítségével helyettesítik be az XML dokumentumban elhelyezett saját elemeket JSP kóddal. Előnye az egyszerűbb 17

18 programozhatóság (a saját elemek kódja is JSP), hátránya az, hogy összetett, nehezen átlátható, hibakeresési szempontból problémás, kísérleti stádiumban lévő technológia. Az XTP-ről bővebben a Caucho web-oldalain lehet olvasni. Az alábbi fejezetek példáinak forráskódja letölthető innen: További munkák a JSP elemkönyvtárak készítéséről: Szervlet és JSP témakörben az egyik legjobb munka Marty Hall idén megjelent könyve, a Core Servlets and JavaServer Pages. Ennek tizennegyedik fejezete példákon keresztül mutatja be a saját elemek készítését. Az egyetlen nem tárgyalt téma az új script változók bevezetése. Szintén erősen gyakorlatorientált mű Magnus Rydin internetes <taglib:tutorial/>-ja Elemkönyvtárak használata Könnyű helyzetben vagyunk, ha készen kapunk vagy az internetről, például a jsptags.com oldalról vagy a Jakarta project taglibs alprojectjéből töltünk le egy adott célra szolgáló elemkönyvtárat. Ilyenkor mindenképp meg kell, hogy kapjuk az elemkönyvtár tulajdonságait leíró.tld kiterjesztésű tag library descriptor-t, és az elemek funkcióját megvalósító Java osztályokat.class fileok, vagy egy.jar kiterjesztésű archívum formájában. (A TLD a jar file /meta-inf alkönyvtárában is lehet.) Általában kapunk külön használati utasítást is a könyvtár mellé, de a megfelelően megírt TLD-nek is tartalmaznia kell a felhasználáshoz szükséges összes információt, érdemes tehát megismerkedni vele. A TLD egy egyszerű szerkezetű XML dokumentum, mely a JSP containernek, a JSP-t ismerő szerkesztőeszközöknek, és a könyvtárat saját kezűleg felhasználóknak szolgál információkkal a könyvtárról és a benne szereplő elemekről. Példaként nézzünk egy egyszerű TLD filet, ami ugyan csak egyetlen akció-elemet ír le (amit a későbbiekben el is fogunk készíteni), de a TLD-k összes lehetséges elemének használatát bemutatja: <?xml version="1.0" encoding="iso "?> <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" " <taglib> <tlibversion>1.0</tlibversion> <jspversion>1.1</jspversion> <shortname>tutorial</shortname> <uri> <info>jsp Taglib peldakonyvtar</info> <tag> <name>greeting</name> <tagclass>tags.greetingtag</tagclass> <teiclass></teiclass> <bodycontent>empty</bodycontent> <info> Napszaktol fuggo koszontest illeszt az oldal szovegebe. A verbose parameter 'true' erteke eseten a pontos idot is kiirja. Alapertelmezett erteke 'false'. </info> <attribute> <name>verbose</name> <required>false</required> <rtexprvalue>false</rtexprvalue> </attribute> </tag> 18

19 </taglib> A file az XML dokumentum fejléccel kezdődik. A legkülső elem a taglib, ennek törzsében a következő elemek lehetnek: tlibversion: a könyvtár verziószáma, a könyvtár fejlődésének a nyomonkövetésére szolgál. jspversion: a könyvtár által igényelt JSP verzió száma. Jelenleg csak az 1.1 érték érvényes. Opcionális. shortname: a könyvtár rövid neve, ez lehet például a könyvtár készítője által ajánlott prefix (amit a taglib direktívának lehet megadni). A JSP specifikáció ennek konkrét felhasználását nem említi, mindenesetre lehetőleg ne tartalmazzon whitespace-t, és ne kezdődjön aláhúzással vagy számjeggyel. uri: egy olyan nyilvános URI, amelyik egyértelműen azonosítja a könyvtárat a verziószámmal egyetemben. Érdemes megjegyezni, hogy a JSP specifikáció jelenlegi verziója nem használja ezt az értékét. (A taglib direktívának megadott URI tehát nem kell, hogy megegyezzen ezzel.) Opcionális. info: a könyvtár általános leírása. Opcionális. tag: Egy saját elem leírása, ilyenből a könyvtárban tetszőleges számú lehet. name: A saját akció neve. Ezt a nevet kell majd a prefix után írni az elemre való hivatkozáskor. tagclass: Az elemkezelő (tag handler) Java osztály neve. teiclass: Az elemről kiegészítő információkat szolgáltató, TagExtraInfo-tól származtatott osztály neve. Jelenleg csak új változókat bevezető elemeknél használatos. Opcionális. bodycontent: Az elem törzsének lehetséges tartalma. Három lehetséges értéke: tagdependent, JSP, illetve empty. Az első eset azt jelöli, amikor az elem törzse valamilyen egyéni formátumban van (az elem maga dolgozza fel a törzset), a második esetben az elem törzse is JSP (a JSP fordító dolgozza fel a törzset), a harmadik esetben az elem törzse üres kell legyen. (Hibajelzést kapunk, ha másként használjuk.) Opcionális, alapértelmezése JSP. info: az elem funkciójának szöveges leírása, érdemes beleírni az attribútumok szerepét is. attribute: Az elem egy attribútumának a leírása. Természetesen ebből is több lehet. name: Az attribútum neve. required: true, false, yes, vagy no értéke mutatja, hogy kötelező-e megadni az attribútumot. Opcionális, alapértelmezése false. rtexprvalue: true, false, yes, vagy no aszerint, hogy az attribútum értéke lehet-e futásidőben számított kifejezés eredménye. Opcionális, alapértelmezése false. A könyvtár használatához a következőket kell tennünk. A web-alkalmazásunk /web-inf könyvtárában hozzunk létre egy web-alkalmazás leírót web.xml néven, vagy a meglévő web.xml filehoz adjunk hozzá egy taglib elemet. (A szervleteket/jsp oldalakat használó websiteok tulajdonságait definiáló web-alkalmazás leíróról bővebben a Servlet specifikációban olvashatunk.) Példaként álljon itt egy egyszerű web.xml: <?xml version="1.0" encoding="iso "?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" " <web-app> 19

20 <taglib> <taglib-uri> <taglib-location>/web-inf/tutorial.tld</taglib-location> </taglib> </web-app> Ennek a taglib elemnek csak két aleleme lehet. A taglib-uri, ami valós vagy szimbolikus URI is lehet, az elemkönyvtárat azonosítja a JSP container számára, ezért a könyvtárat használó oldalak taglib direktíváinak uri attribútumai ezt az értéket kell, hogy kapják. A taglib-location adja meg a TLD file tényleges helyét, ez a specifikáció szerint a /web-inf könyvtárban kell, hogy legyen. A.class fileokat ezek után helyezzük a /web-inf/classes könyvtárba, illetve a Java konvenciók szerint a megfelelő alkönyvtárába (a példában ez a /web-inf/classes/tags), ha.jar fileban vannak, akkor tegyük a.jar filet a /web-inf/lib könyvtárba. (Lehet a könyvtár egyik része külön fileokban, a másik része pedig.jar fileban.) Ezek után már nincs más hátra, mint hogy felhasználjuk az új elemeket a saját oldalunkban. Egy példa a fenti tutorial nevű könyvtár használatára: <%@ page language="java" %> <%@ taglib uri=" prefix="tutorial" %> <html> <head> <title>tag library pelda 1</title> </head> <body> <tutorial:greeting verbose="true" /> </body> </html> A JSP fordító a taglib direktíva uri attribútuma alapján fogja megkeresni a web.xml fileban az elemkönyvtárhoz tartozó leíró helyét, majd a leíró alapján leellenőrzi, hogy helyesen használtuk-e az elemeket, végül befordítja a készülő szervlet kódjába azokat a hívásokat, amelyek az elemkezelő (tag handler) Java osztály megfelelő metódusait aktivizálják. (Ha a web.xml fileban nem volt megegyező URI, akkor relatív URI esetén megpróbálja közvetlenül az uri attribútum alapján megkeresni a könyvtárleírót. Ezt a lehetőséget azonban nem ajánlott kihasználni, mert csökkenti az átláthatóságot.) Egyszerű elemek készítése Ha már kitaláltuk, hogy mit is tud majd a megálmodott elem, és milyen attribútumai lesznek, majd ezek alapján megírtuk a TLD-t, akkor már nincs más hátra, mint hogy megírjuk az elemnek szánt feladatokat elvégző elemkezelőt. Az elemkezelő egy Java osztály kell legyen, pontosabban egy megadott tulajdonságokkal (property-kkel) rendelkező JavaBean, ami közvetve vagy közvetlenül megvalósítja a javax.servlet.jsp.tagext csomag Tag, vagy BodyTag interface-ét. Ha csak nincsenek különleges igényeink, célszerű az ugyanebben a csomagban található TagSupport, illetve BodyTagSupport osztályt kiterjeszteni, ezek ugyanis implementálják a Tag, illetve a BodyTag interface-t, így már csak az egyes eljárásaikat kell az igényeink szerint felüldefiniálni. (Ezen kívül kényelmi metódusokkal is szolgálnak, erről később.) A TagSupport osztályt célszerű kiterjeszteni, ha a saját akciónknak nincs törzse, vagy lehet törzse, de azt vagy egy az egyben felhasználjuk, vagy egy az egyben kidobjuk. (Ilyenkor 20