o nazwie zawartosc, oznaczający miejsce, w którym powinna zostać wyświetlona właściwa zawartość strony. Plik HTML, który zostanie wykorzystany do wygenerowania zawartości aplikacji „Narzędzia” jest przedstawiony w przykładzie 17.7. Przykład 17.7. Plik zawartości aplikacji „Narzędzia” <TITLE>Lista narzędzi
Strona główna
Hosting
Mechanizmy
|
| <SPAN ID="tytul">Lista narzędzi |
<SPAN ID="tytul2">Lista narzędzi do tworzenia zawartości
<SPAN ID="opis"> Bez narzędzi, ludzie nie są niczym więcej niż zwierzętami. I to dość słabymi. Poniżej przedstawiono listę opartych na serwletach narzędzi do tworzenia zawartości, które można wykorzystać w celu wzmocnienia się."
<SPAN ID="nazwaNarz">Jakaś nazwa narzędzia <SPAN ID="stanNarz">(Nowość!) http://narzedzia.com
<SPAN ID="komentarzNarz"> Tutaj komentarz na temat narzędzia.
|
|
Strona Główna Hosting Mechanizmy
|
Powyższy plik wygląda bardzo podobnie do szablonu, ale wartości obszarów zablokowanych zostały wymienione na realistyczne i wypełniono obszar zawartości pewnymi prototypowymi rekordami. Oto sposób wykorzystania tego pliku: programowo pobrane zostaną jego kluczowe elementy (tytuły, opis i prototypowy rekord), po czym zostaną one skopiowane i umieszczone w pliku szablonu w celu utworzenia ostatecznej wersji strony. Po co wykorzystywać dwa pliki? Czy nie jest możliwe po prostu bezpośrednie zmodyfikowanie pliku widoknarz.html? Jest to możliwe, ale szablon wykorzystywany jest po to, by w przypadku przyszłego uaktualnienia nagłówka, paska bocznego lub stopki konieczne było uaktualnienie jedynie pliku szablon.html i zmiana ta została uwidoczniona na wszystkich stronach. Innymi słowy, szablon narzuca ogólny wygląd strony. Plik widoknarz.html jest wykorzystywany jedynie w kluczowych częściach. Pliki HTML są poddawane kompilacji XMLC przy pomocy poniższych poleceń. Mogą wystąpić ostrzeżenia, ponieważ HTML w nich zawarty nie jest prawidłowym XML: % xmlc –class Szablon –keep –methods szablon.html % xmlc –class WidokNarz –keep –methods widoknarz.html
Następnie można utworzyć serwlet który działa jako klasa manipulacyjna. Jest on przedstawiony w przykładzie 17.8. Przykład 17.8.
Klasa manipulacyjna aplikacji „Narzędzia” import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*;
import org.w3c.dom.*; import org.w3c.dom.html.*;
import org.enhydra.xml.io.DOMFormatter;
public class WidokNarzSerwlet extends HttpServlet {
private Narzedzie[] narzedzia;
public void init() throws ServletException { // Załadowanie danych narzędzi w init w celu uproszczenia String plikNarz = getInitParameter("plikNarz"); // z web.xml if (plikNarz == null) { throw new ServletException( "Plik danych narzędzi musi być określony jako parametr inicjacji plikNarz "); } log("Ładowanie narzędzi z " + plikNarz); try { narzedzia = Narzedzie.ladujNarzedzia(plikNarz); if (narzedzia.length == 0) { log("Nie odnaleziono narzędzi w " + plikNarz); } else { log(narzedzia.length + " narzędzi znaleziono w " + plikNarz); } } catch (Exception w) { throw new ServletException(w); } }
public void doGet(HttpServletRequest zad, HttpServletResponse odp) throws ServletException, IOException { odp.setContentType("text/html"); PrintWriter wyj = odp.getWriter();
// Utworzenie drzewa DOM dla pełnego dokumentu Szablon szablon = new Szablon();
// Utworzenie drzewa DOM przechowującego wewnętrzną zawartość
WidokNarz widoknarz = new widokNarz();
// Pobranie prototypowego rekordu narzędzia HTMLDivElement rekord = widoknarz.getElementRekord();
// Pobranie odwołania do punktu wstawiania
dla listy narzędzi
HTMLDivElement punktWstaw = szablon.getElementZawartosc(); Node przodekWstaw = punktWstaw.getParentNode();
// Ustawienie tytułów i opisu // Usunięcie danych z pliku widoknarz.html String tytul = ((Text)widoknarz.getElementTytul().getFirstChild()).getData(); String ttul2 = ((Text)widoknarz.getElementTytul2().getFirstChild()).getData(); String opis = ((Text)widoknarz.getElementOpis().getFirstChild()).getData(); szablon.setTitle(tytul);
// tytuł strony
szablon.setTextTytul(tytul); // element oznaczony „tytul” template.setTextTytul2(tytul2); template.setTextOpis(opis);
// element oznaczony „tytul2”
// element oznaczony „opis”
// Pętla nad narzędziami, dodanie nowego rekordu dla każdego for (int i = 0; i < narzedzia.length; i++) { Narzedzie narzedzie = narzedzia[i];
widoknarz.setTextNazwaNarz(narzedzie.nazwa); widoknarz.setTextToolKomentarz(narzedzie.komentarz);
if (narzedzie.czyNowy(45)) { widoknarz.setTextToolStan(" (Nowość!) "); } else if (narzedzie.czyUaktualniony(45)) { widoknarz.setTextToolStan(" (Uaktualnienie!) "); } else { widoknarz.setTextToolStan(""); }
HTMLAnchorElement lacze = toolview.getElementLaczeNarz(); lacze.setHref(narzedzie.domURL); Text laczeTekst = widoknarz.createTextNode(narzedzie.domURL); lacze.replaceChild(laczeTekst, lacze.getLastChild());
// importNode() to DOM Level 2 przodekWstaw.insertBefore(szablon.importNode(rekord, true), null); }
// Usunięcie obszaru zablokowanego
przodekWstaw.removeChild(punktWstaw);
// Wyświetlenie dokumentu DOMFormatter formatuj = new DOMFormatter();
// może być poprawiony
formatuj.write(szablon, out); } }
Metoda init() serwletu pobiera dane narzędzi z pliku określonego w parametrze inicjacji plikNarz, przy pomocy klasy Narzedzie z rozdziału 14, „Szkielet Tea”. Ciekawe działanie następuje w metodzie doGet(). Tworzone są egzemplarze dokumentów Szablon i WidokNarz. Następnie odnajdywany jest prototypowy rekord narzędzia w WidokNarz oraz punkt wstawiania dla rekordów narzędzie w Szablon. Następnie odczytywane są tytuły i opis z dokumentu WidokNarz, po czym wartości te zostają skopiowane do Szablon. W pętli for dokonywana jest obsługa zadania tworzenia listy rekordów narzędzi. Dla każdego narzędzia do prototypowego rekordu przypisane zostają odpowiednie wartości — na początku nazwa i komentarz, po czym łącze. Po zmodyfikowaniu rekordu zostaje on dodany do szablonu w punkcie wstawiania. W DOM węzły przypisane są do dokumentu, który je utworzył, tak więc zastosowana zostaje metoda importNode() w celu udostępnienia rekordu przesuwanego z dokumentu WidokNarz do Szablon. Metoda importNode() wykonuje głębokie kopiowanie (ponieważ przekazano jej jako drugi argument true), tak więc każda iteracja pętli for dodaje inna kopię zawartości rekordu. Po zakończeniu pętli for punkt wstawiania zostaje usunięty z szablonu i dokument jest wyświetlany klientowi. Podczas uruchamiania powyższego serwletu należy pamiętać, że metoda importNode() jest nowością w DOM Level 2, tak więc, aby mógł on zostać uruchomiony, serwer musi posiadać ścieżkę klas zawierającą DOM Level 2 przed wszystkimi klasami DOM Level 1. Archiwum xmlc.jar zawiera DOM Level 2, tak więc można pomyśleć, że nie ma żadnego problemu, ale niektóre serwery (włączając w to Tomcat 3.2) posiadają w swojej domyślnej ścieżce implementację DOM Level 1 pomagającą w odczytywaniu plików web.xml. Aby powyższy serwlet mógł pracować na takich serwerach konieczna jest edycja ścieżki klas serwera w celu upewnienia się, że plik XMLC xmlc.jar znajduje się przed własnymi bibliotekami XML serwera. (Tomcat 3.2 automatycznie ładuje pliki JAR w porządku alfabetycznym, tak więc konieczna może okazać się zmiana nazw plików JAR.) Jednym z problemów związanych z XMLC jest przedstawiony przez powyższy przykład fakt, że warunkowo dołączane bloki tekstu, których zawartość może się zmieniać, podobnie jak uwagi (Nowość! i Uaktualnienie!) mogą sprawiać trudności przy dołączaniu do strony, ponieważ szablon może zadeklarować tylko jeden możliwy blok tekstu do dołączenia. W powyższym przykładzie oczywiste jest, że kod Javy wie więcej niż powinien na temat tworzenia uwag. Miłą własnością XMLC jest automatyczne umieszczanie kodów ucieczkowych przed znakami specjalnymi takimi jak <, > i & podczas wyświetlania ich do klienta, ponieważ wtedy narzędzie dokonujące wyświetlenia może bez problemu rozpoznać, co jest strukturą, a co zawartością. Ta wiedza o strukturze dokumentu umożliwia również mechanizmowi formatującemu na wykonywanie zaawansowanych zadań takich jak modyfikacja wszystkich łączy w celu zakodowania identyfikatorów sesji, chociaż ta konkretna własność nie została jeszcze wprowadzona. Strona wygenerowana przez powyższy serwlet wygląda identycznie jak strona utworzona przez przykłady Tea, albo WebMacro.
W niniejszym rozdziale: •
Wykorzystywanie JavaServer Pages
•
Zasady działania
•
Wyrażenia i deklaracje
•
Instrukcje
•
JSP i JavaBeans
•
Dołączenia i przekazania
•
Aplikacja „Narzędzia”
•
Biblioteki własnych znaczników
Rozdział 18.
JavaServer Pages JavaServer Pages, znana powszechnie jako JSP, to technologia utworzona przez Sun Microsystems, blisko związana z serwletami. JSP była jedną z pierwszych prób utworzenia ogólno dostępnego systemu tworzenia zawartości opartego na serwletach. Osoby od dawna zajmujące się serwletami mogą pamiętać, że JSP została przedstawiona po raz pierwszy na wiosnę 1998 — na tyle wcześnie, by pierwsze wydanie niniejszej książki mogło zawierać krótki samouczek testowej wersji 0.91 JSP. Oczywiście JSP zmieniła się bardzo od tego czasu. W tym rozdziale opisana zostanie JSP 1.1, opierająca się na Servlet API 2.2. Podobnie jak w przypadku serwletów, Sun udostępnia specyfikację JSP (utworzoną przez grupę ekspertów składającą się z niezależnych producentów i osób), po czym inni producenci konkurują w swoich implementacjach tego standardu. Różnica pomiędzy JSP i innymi technologiami opartymi bezpośrednio na serwletach polega na tym, że JSP jest specyfikacją, nie produktem i wymaga wsparcia ze strony serwera. Większość producentów kontenerów serwletów zapewnia tę obsługę, między innymi Tomcat, w którym mechanizm JSP nosi nazwę Jasper. JSP jest podstawowym składnikiem Java 2, Enterprise Edition (J2EE). Jednym z głoszonych celów JSP (cytat ze specyfikacji) jest „umożliwienie oddzielenia zawartości dynamicznej i statycznej”. Innym celem jest „umożliwienie tworzenia stron WWW, które zawierają elementy dynamiczne w łatwy sposób, ale z maksymalną mocą i elastycznością”. JSP spełnia dobrze oba te zadania. Jednak, zgodnie z kwestią „maksymalnej mocy” przy tworzeniu JSP, autor strony JSP zawsze posiada całkowitą kontrolę nad systemem, i w związku z tym można powiedzieć, że JSP umożliwia oddzielenie zawartości od grafiki, ale nie wymusza jej ani nie narzuca, jak to się dzieje w przypadku jej alternatyw. Jest to zjawisko podobne do tego, że C++ umożliwia projektowanie obiektowe, ale nie promuje tego doskonałego sposobu tak mocno, jak to się dzieje w przypadku Javy.
JSP jest również technologią bardzo elastyczną, i istnieje wiele sposobów jej wykorzystania. Jednym z nich jest „skrótowy” sposób tworzenia serwletów — programista serwletów, dobrze znający Javę, może umieścić kod Javy bezpośrednio na stronie JSP, zamiast pisać kompletny serwlet — co daje ułatwienia takie jak wyeliminowanie wywołań wyj.println(), umożliwienie bezpośredniego wskazywania na pliki JSP i wykorzystanie własności autokompilacji JSP, Jednak poprzez tworzenie strony JSP zamiast serwletu programista traci pełny kontakt z kodem oraz możliwość kontroli prawdziwego środowiska uruchomieniowego (np. rozszerzanie com.oreilly.servlet.CacheHttpServlet lub tworzenie wyniku binarnego (obrazka)). Z tego powodu najlepiej jest pozostawić prawdziwe kodowanie zwykłym serwletom, a strony JSP wykorzystać przede wszystkim do tworzenia logiki prezentacyjnej. Nawet podczas zastosowania stron JSP jedynie do logiki prezentacyjnej, można je wykorzystać na wiele sposobów. Jednym z nich jest użycie komponentów JavaBeans osadzonych na stronie. Innym tworzenie własnych znaczników wyglądających jak HTML, ale będących tak naprawdę punktami zaczepienia do wspomagającego kodu Javy. Jeszcze innym jest wysyłanie wszystkich żądań do serwletu, który wykonuje logikę biznesową, po czym przesyła żądanie do JSP tworzącej stronę przy pomocy mechanizmu RequestDispatcher. Technika ta jest często nazywana architekturą Model 2, która to nazwa pochodzi od specyfikacji JSP 0.92. Istnieją również inne mechanizmy noszące dziwne nazwy takie jak Model 1½, Model 2½, czy Model 2+1. Niemożliwe jest wskazanie najlepszej techniki stosowania JSP. W niniejszym rozdziale opisane zostaną różne sposoby wykorzystania JSP, począwszy od „skrótu do serwletu” a skończywszy na własnych znacznikach. Opis będzie krótki, ale powinien dostarczyć podstaw do porównania JSP z jej alternatywami. Nie zostaną opisane wszystkie opcje architektury, a zamiast tego nacisk zostanie położony na szczegóły techniczne. Opcje architektury i większa ilość informacji na temat JavaServer Pages jest dostępna na stronie głównej JSP pod adresem http://java.sun.com/products/jsp („ściąga” składni jest dostępna pod adresem http://java.sun.com/products/jsp/syntax.pdf) oraz w książce „JavaServer Pages” autorstwa Hansa Bergstena (O'Reilly).
Wykorzystywanie JavaServer Pages Najbardziej podstawową funkcją JSP jest umożliwienie bezpośredniego umieszczenia kodu serwletu w statycznym pliku HTML1. Każdy blok kodu serwletu (nazywany skryptletem) jest ograniczany otwierającym znacznikiem <% i zamykającym %>. Wykorzystywanie skryptletu ułatwia kilka predefiniowanych zmiennych. Sześć najpopularniejszych to: HttpServletRequest request Żądanie serwletu. HttpServletResponse response Odpowiedź serwletu. javax.servlet.jsp.JspWriter out Urządzenie wyświetlające, stosowane podobnie jak PrintWriter, posiadające jednak inną charakterystykę buforowania. HttpSession session Sesja użytkownika. ServletContext application Aplikacja WWW. javax.servlet.jsp.PageContext pageContext Obiekt wykorzystywany przede wszystkim do rozdzielania implementacji serwera, ale często wykorzystywany bezpośrednio do współdzielenia zmiennych pomiędzy stronami JSP i wspomagającymi elementami i znacznikami. 1
Przed rozpoczęciem opisu warto zauważyć, że umieszczanie kodu Javy na stronie JSP jest uważane za działanie w złym stylu. Uważane za lepsze zaawansowane zastosowania JSP zostaną opisane w dalszej części rozdziału.
Można dostrzec, że klasy JSP umieszczone są w pakiecie javax.servlet.jsp. Przykład 18.1 przedstawia prostą stronę JSP wyświetlającą spersonalizowane „Witaj” przy pomocy predefiniowanych zmiennych request i out. Jeżeli posiada się serwer obsługujący JavaServer Pages i pragnie się przetestować tę stronę, należy umieścić plik w podkatalogu katalogu macierzystego dokumentów serwera i zapamiętać ją z rozszerzeniem .jsp. Zakładając, że strona została zapamiętana jako witaj1.jsp, dostęp do niej można uzyskać pod URL-em http://serwer:port/witaj1.jsp lub, jeżeli plik zostanie umieszczony w ścieżce kontekstowej jsp, URL będzie wynosił http://serwer:port/jsp/witaj1.jsp. Przykład 18.1. Powitanie przy pomocy JSP <TITLE>Witaj
<% if (request.getParameter("nazwa") == null) { out.println("Witaj świecie"); } else { out.println("Witaj, " + request.getParameter("nazwa")); } %>
Przykładowy wynik uruchomienia powyższego programu przedstawiony jest na rysunku 18.1. Rysunek 18.1. Powitanie przy pomocy JavaServer Pages
Zasady działania Jak działa JSP? Poza obszarem widoczności serwer automatycznie tworzy, kompiluje, ładuje i uruchamia specjalny serwlet tworzący zawartość strony, jak przedstawiono na rysunku 18.2. Można myśleć o tym specjalnym serwlecie jak o serwlecie roboczym, działającym w tle. Statyczne części strony HTML są tworzone przez serwlet roboczy przy pomocy ekwiwalentów wywołań wyj.println(), podczas gdy części
dynamiczne są dołączane bezpośrednio. Na przykład, serwlet przedstawiony w przykładzie 18.2 mógłby być serwletem roboczym dla witaj1.jsp działającym na serwerze Tomcat2.
Rysunek 18.2. Generowanie stron JavaServer Pages Przykład 18.2. Generowany automatycznie serwlet roboczy dla witaj1.jsp import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.jsp.*; import javax.servlet.jsp.tagext.*; import java.beans.*; import java.io.*; import java.util.*; import org.apache.jasper.runtime.*; import org.apache.jasper.*;
public class _0002fwitaj_00031_0002ejspwitaj1_jsp_0 extends HttpJspBase {
static { } public _0002fwitaj_00031_0002ejspwitaj1_jsp_0( ) { }
2
Osoby zainteresowane zobaczeniem prawdziwego kodu źródłowego serwletu dla strony JSP, w większości przypadków mogą odnaleźć go w tymczasowym katalogu określonym w atrybucie kontekstu javax.servlet.context.tempdir (proszę zobaczyć rozdział 4, „Pobieranie informacji”. Kiedy odnajdzie się prawdziwe źródło serwletu można zobaczyć, że jest ono o wiele bardziej skomplikowane niż to przedstawione w tym miejscu.
private static boolean _jspx_inited = false;
public final void _jspx_init() throws JasperException { }
public void _jspService(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
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=ISO-8859-1"); pageContext = _jspxFactory.getPageContext(this, request, response, "", true, 8192, true);
application = pageContext.getServletContext(); config = pageContext.getServletConfig(); session = pageContext.getSession(); out = pageContext.getOut();
// HTML // begin [file="C:\\ witaj1.jsp";from=(0,0);to=(4,0)] out.write("\r\n<TITLE>Witaj\r\n\r\n
\r\n"); // end // begin [file="C:\\ witaj1.jsp";from=(4,2);to=(11,0)]
if (request.getParameter("nazwa") == null) { out.println("Witaj œwiecie"); } else { out.println("Witaj, " + request.getParameter("nazwa")); } // end // HTML // begin [file="C:\\ witaj1.jsp";from=(11,2);to=(14,0)]
out.write("\r\n
\r\n\r\n"); // end
} catch (Exception ex) { if (out != null && out.getBufferSize() != 0) out.clearBuffer(); if (pageContext != null) pageContext.handlePageException(ex); } finally { if (out != null) out.flush(); if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext); } } }
Kiedy wyświetla się stronę JSP po raz pierwszy można zauważyć, że jej wywołanie zabiera pewną ilość czasu. Jest to czas potrzebny serwerowi na stworzenie i skompilowanie serwletu roboczego, co zostało nazwane karą pierwszej osoby. Następne żądania powinny następować ze zwykłą szybkością, ponieważ serwlet może ponownie wykorzystać serwlet w pamięci. Jedynym wyjątkiem jest zmiana pliku .jsp, co serwer rozpoznaje podczas wykonywania następnego żądania tej strony, po czym rekompiluje serwlet działający w tle. Jeżeli kiedykolwiek wystąpi błąd kompilacji, można spodziewać się, że serwer zakomunikuje go w pewien sposób, zazwyczaj poprzez stronę zwracaną klientowi i/lub dziennik zdarzeń serwera.
Wyrażenia i deklaracje Oprócz skryptletów, JavaServer Pages pozwala na umieszczanie kodu na stronie przy pomocy wyrażeń i deklaracji. Wyrażenie JSP rozpoczyna się znacznikiem <%=, a kończy %>. Każde wyrażenie Javy pomiędzy tymi dwoma znacznikami jest oceniane, jego wynik konwertowany do łańcucha String, a tekst dołączany bezpośrednio do strony. Technika ta eliminuje nieporządek wywołania wyj.println(). Na przykład, <%= buu => dołącza wartość zmiennej buu. Deklaracja rozpoczyna się od <%!, a kończy na %>. Pomiędzy tymi znacznikami można umieścić dowolny kod serwletu, który powinien pozostać poza metodą usługową serwletu. Zadeklarować można zmienne statyczne lub egzemplarzowe, albo też zdefiniować nowe metody. Przykład 18-3 przedstawia stronę JSP, która wykorzystuje deklarację do zdefiniowania metody pobierzNazwa() oraz wyrażenie ją wyświetlające. Komentarz na początku pliku pokazuje, że komentarze JSP oznaczane są znacznikami <%-- i --%>. Przykład 18.3. Powitanie przy pomocy deklaracji JSP <%-- witaj2.jsp --%> <TITLE>Witaj
Witaj, <%= pobierzNazwa(request) %>
<%! private static final String DOMYSLNA_NAZWA = "świecie";
private String pobierzNazwa(HttpServletRequest zad) { String nazwa = zad.getParameter("nazwa"); if (nazwa == null) return DOMYSLNA_NAZWA; else return nazwa; } %>
Powyższy kod JSP zachowuje się identycznie jak witaj1.jsp. Specjalne metody jspInit() i jspDestroy() mogą zostać zaimplementowane wewnątrz deklaracji. Są one wywoływane przez metody init() i destroy() serwletu działającego w tle i dają stronie JSP możliwość zadeklarowania kodu, który powinien zostać wykonany podczas inicjacji i niszczenia. Strona JSP nie może omijać standardowych metod init() i destroy(), ponieważ metody te są ostatecznie deklarowane przez serwlet roboczy.
Instrukcje Instrukcja JSP pozwala stronie JSP na kontrolowanie pewnych aspektów jej serwletu roboczego. Instrukcje mogą zostać wykorzystane do nakazania serwletowi roboczemu ustawienia jego typu zawartości, importowania pakietu, kontroli buforowania wyświetlania i zarządzania sesją, rozszerzania różnych superklas oraz specjalnej obsługi błędów. Instrukcja może nawet określać wykorzystanie języka skryptowego innego niż Java. Składnia instrukcji musi zawierać jej nazwę oraz parę nazwa-wartość atrybutu, a całość musi być zwarta pomiędzy znacznikami <%@ i %>. Cudzysłowy zamykające wartość atrybutu są obowiązkowe: <%@ nazwaInstrukcji nazwaAtrybutu="wartoscAtrybutu" %>
Instrukcja page pozwala JSP na kontrolowanie generowanego serwletu poprzez ustawienie specjalnych atrybutów wymienionych poniżej: contentType Określa typ zawartości generowanej strony. Na przykład: <%@ page contentType="text/plain" %>
Domyślnym typem zawartości jest text/plain; charset=8859_1. import Określa listę klas i pakietów, które tworzony serwlet powinien importować. Większa ilość klas może zostać określona w formie listy rozdzielonej przecinkami. Na przykład: <%@ page import="java.io.*,java.util.Hashtable" %>
Domyślna, ukryta i zawsze dostępna lista klas to java.lang.*,javax.servlet.*,javax.servlet.http.*,javax.servlet.jsp.*. buffer Określa minimalną wymaganą wielkość bufora odpowiedzi w kilobajtach, podobnie do metody serwletu setBufferSize(). Wartość powinna zostać zapisana w formie ##kb. Specjalna wartość none wskazuje, że zawartość powinna zostać przekazana bezpośrednio do odpowiedniego PrintWriter w ServletResponse (który może, ale nie musi przekazać zawartość klientowi). Na przykład: <%@ page buffer="12kb" %>
Domyślna wartość wynosi 8kb. autoFlush Określa, czy bufor powinien być opróżniany, kiedy jest pełny, czy zamiast tego powinien zostać wywołany wyjątek IOException. Wartość true wskazuje na opróżnianie, false na wyjątek. Na przykład:
<%@ page autoFlush="true" %>
Wartość domyślna wynosi true. session Wskazuje, że strona pragnie posiadać dostęp do sesji użytkownika. Wartość true umieszcza w zakresie zmienną session i może ustawić cookie klienta zarządzające sesją. Na przykład: <%@ page session="false" %>
Wartość domyślna wynosi true. errorPage Określa stronę, którą należy wyświetlić, kiedy na stronie wystąpi Throwable, które nie zostanie przechwycone przed dotarciem do serwera. Okazuje się to przydatne, ponieważ nie jest trudno wykonać operacje try i catch na blokach podczas tworzenia stron JSP. Na przykład: <%@ page errorPage="blad.jsp" %>
Domyślne zachowanie zależy od implementacji. Ścieżka jest względna wobec kontekstu, tak więc nie trzeba się przejmować dodawaniem właściwej ścieżki kontekstu. Celem może być JSP, ale nie jest to konieczne. Jeżeli cel jest serwletem, może on pobrać Throwable jako atrybut kontekstu javax.servlet.jsp.jspException. isErrorPage Wskazuje, że strona została zaprojektowana jako cel errorPage. Jeżeli wartość wynosi true, strona może uzyskać dostęp do ukrytej zmiennej o nazwie exception w celu odczytania Throwable. language Określa język skryptowy wykorzystany w częściach strony zawierających kod. Zastosowany język musi na tyle dobrze współpracować z Javą, aby uwidocznić potrzebne obiekty Javy środowisku skryptu. Na przykład: <%@ page language="javascript" %>
Domyślna wartość wynosi java, jest to jedyny język rekomendowany przez specyfikację.
Wykorzystanie instrukcji Przykład 18.4 przedstawia stronę JSP noszącą nazwę bladRob.jsp, która wykorzystuje kilka instrukcji. Po pierwsze ustawia atrybut session dyrektywy page na false, ponieważ strona nie wykorzystuje obiektu sesji i w związku z tym nie istnieje potrzeba, by serwer tworzył sesję. Następnie ustawia atrybut errorPage na /bladBierz.jsp, tak więc jeżeli na stronie wydarzy się niewyłapany wyjątek, strona bladBierz.jsp będzie obsługiwać wyświetlanie komunikatu o błędzie. Główna część strony jest prosta. Wyzwala ona wyjątek w celu wywołania zachowania errorPage. (Powód wykorzystania sprawdzenia if zostanie opisany później.) Przykład 18.4. Zły chłopiec <%-- bladRob.jsp --%>
<%@ page session="false" %>
<%-- Wyłączenie niepotrzebnych cookies --%>
<%@ page errorPage="/bladBierz.jsp" %>
<%-- Ogólna strona obsługująca błędy --%>
<%-- A teraz wywołanie błędu --%> <% if (System.currentTimeMillis() > 0) { throw new Exception("uups"); } %>
Strona bladBierz.jsp jest przedstawiona w przykładzie 18.5. Ustawia ona instrukcję strony isErrorPage na true w celu wskazania, że ta strona obsługuje błędy, oraz wykorzystuje atrybut import w celu zaimportowania klas com.oreilly.servlet. JSP wykorzystuje skryptlet do ustawienia kodu stanu odpowiedzi na 500, po czym tworzy zawartość strony przy pomocy nazwy klasy wyjątku, jego ścieżkę oraz wiadomość sugerującą kontakt z administratorem WWW w celu zgłoszenia problemu. Przykład 18.5. A oto i problem... <%-- bladBierz.jsp --%>
<%@ page isErrorPage="true" %> <%@ page import="com.oreilly.servlet.*" %>
<% response.setStatus(500); %>
<TITLE>Błąd: <%= exception.getClass().getName() %>
<%= exception.getClass().getName() %>
Wystąpił błąd podczas tworzenia oryginalnego WWW
<%= ServletUtils.getStackTraceAsString(exception) %>
<% String name = request.getServerName(); %> Proszę skontaktować się z
">webmaster@<%= name %> w celu zgłoszenia błędu.
Podczas każdego żądania bladRob.jsp wywoływany jest wyjątek, kontrola jest przekazywana do bladBierz.jsp, który wyświetla elegancką stronę informującą o błędzie. Proszę zobaczyć rysunek 18.3.
Rysunek 18.3. Własna strona błędów
Tak więc dlaczego w bladRob.jsp występuje wywołanie System.currentTime Millis()? Bierze się to z faktu, że strony JSP muszą przechowywać wszystkie puste miejsca z tekstu dokumentu. Pozwala to na wykorzystanie JSP do tworzenia nie tylko HTML, ale także XML, w którym puste miejsca mogą być niezwykle ważne. Niestety zachowanie wszystkich pustych miejsc oznacza, że prosty skryptlet: <% throw new Exception("uups"); %>
musi wygenerować kod w celu wyświetlenia nowej linii po wywołaniu błędu — kod, który nigdy nie zostanie osiągnięty! Kompilacja tego skryptu na Tomcat-cie, generuje następujący komunikat o błędzie. org.apache.jasper.JasperException: unable to compile class for JSPC: \engines\jakarta-tomcat\work\localhost_8080%2Fjsp\ -0001fbladRob_0002ejspbladRob-jsp-3.java:75: Statement not reached. out.write("\r\n"); ^
Poprzez dodanie sprawdzenia, czy System.currentTimeMillis() jest większe niż zero, kompilator przyjmuje, że istnieje możliwość, że wyjątek nie zostanie wywołany i w związku z tym nie wystąpi błąd kompilacji. Podobne problemy mogą pojawiać się w przypadku wyrażeń return i throw wewnątrz skryptletów. Tak naprawdę istnieje wiele sztuczek powiązanych z wykorzystaniem skryptletów w JSP. Jeżeli przypadkowo napisze się skryptlet zamiast wyrażenia (poprzez pominięcie znaku równości), zadeklaruje statyczną zmienną wewnątrz skryptletu (gdzie zmienne te nie są dozwolone), zapomni przecinka (nie są konieczne w wyrażeniach, ale konieczne w skryptletach) lub napisze się cokolwiek nie będącego idealnym kodem Javy, przypuszczalnie otrzyma się dziwny komunikat o błędzie, ponieważ kompilator działa na wygenerowanym kodzie Javy, nie na pliku JSP. Aby zademonstrować problem, proszę wyobrazić sobie, że w pliku bladBierz.jsp <%= nazwa %> zostało zastąpione przez <% nazwa %>. Tomcat wygeneruje wtedy następujący błąd: org.apache.jasper.JasperException: unable to compile class for JSPC: \engines\jakarta-tomcat\work\localhost_8080%2Fjsp\ -0001fbladRob_0002ejspbladRob-jsp-3.java:91: Class name not found. name ^
Usunięcie błędu podobnego do przedstawionego powyżej często wymaga od programisty przyjrzenia się generowanemu kodowi w celu rekonstrukcji powodu błędu.
Unikanie kodu Javy na stronach JSP Skryptlet, wyrażenia i deklaracje umożliwiają umieszczanie kodu Javy na stronie JSP. Są to narzędzia o dużej mocy, jednak ich wykorzystywanie nie jest polecane. Nawet w rękach doświadczonego programisty umieszczanie kodu na stronie jest programowaniem „nieświeżym”. Tworzy się kod Javy, ale nie bezpośrednio. W przypadku wystąpienia błędu ciężko jest go zdiagnozować z powodu dodatkowej niejasności. Sytuacja staje się jeszcze gorsza, kiedy mechanizm ten wykorzystuje nowicjusz. Osoby nie będące programistami muszą nauczyć się Javy chociaż w pewnym stopniu, a Java nie jest zaprojektowana jako język skryptowy, nie jest też przeznaczona dla takich osób. Język taki jak JavaScipt — prostszy mniej ścisły i lepiej znany przez projektantów WWW — mógłby być lepszym rozwiązaniem, ale obsługa JavaScriptu nie jest czynnością standardową i w związku z tym jej implementacja nie jest popularna. Ostatnią kwestią jest projekt. Jeżeli projektanci i programiści pracują nad tym samym plikiem, tworzy się wąskie gardło i dodatkowa możliwość wystąpienia błędu. Zawartość i grafika powinny być od siebie oddzielone. Aby to umożliwić i usunąć kod Javy ze strony, Java pozwala na zastosowanie JavaBeans i bibliotek własnych znaczników. Poniżej opisane zostaną JavaBeans.
JSP i JavaBeans Jedną z najbardziej interesujących i potężnych metod wykorzystania JavaServer Pages jest współpraca z komponentami JavaBeans. JavaBeans to klasy Javy zaprojektowane do wielokrotnego wykorzystania, a nazwy ich metod i zmiennych tworzone są według pewnej konwencji, która daje im dodatkowe możliwości. Mogą one być osadzane bezpośrednio na stronie Javy przy pomocy znacznika <jsp:useBean>, czyli działania nazywanego przez JSP akcją. Komponent JavaBean może wykonywać dobrze zdefiniowane zadanie (zapytanie bazy danych, łączenie się z serwerem poczty, utrzymywanie informacji na temat klienta itp.), którego wynik jest dostępny stronie JSP poprzez proste metody dostępu. Większa ilość informacji na temat JavaBeans znajduje się pod adresem http://java.sun.com/bean i w książce „Developing JavaBeans” autorstwa Roberta Englandera (O'Reilly). Różnica pomiędzy komponentem JavaBeans osadzonym na stronie JSP i każdą inną dodatkową klasą wykorzystywaną przez wygenerowany serwlet jest taka, że serwer WWW może traktować JavaBeans osadzone na stronie w specjalny sposób. Na przykład, serwer może automatycznie skonfigurować komponent (zwłaszcza zmienne egzemplarza) przy pomocy wartości parametrów w żądaniu klienta. Innymi słowy, jeżeli żądanie zawiera parametr nazwa, a serwer odkryje poprzez introspekcję (technikę, w której metody i zmienne klasy Javy mogą zostać określone programowo w czasie uruchomienia), że komponent posiada parametr nazwa i metodę ustawNazwe(String nazwa), serwer może automatycznie wywołać pobierzNazwe() z wartością parametru nazwa. Nie jest konieczne wykorzystanie metody getParameter(). Serwer może także automatycznie zarządzać zakresem komponentu. Komponent może zostać przypisany do konkretnej strony (gdzie jest wykorzystany raz i zniszczony), konkretnego żądania (podobne do zakresu strony poza tym, że komponent może przetrwać wewnętrzne wywołania dołączenia i przekazania), sesji klienta (w którym komponent jest automatycznie udostępniany, kiedy tan sam klient połączy się ponownie) lub aplikacji (w którym to zakresie ten sam komponent jest udostępniany całej aplikacji WWW).
Osadzanie komponentu Bean Komponenty są osadzane na stronie JSP przy pomocy akcji <jsp:useBean>. Posiada ona następującą składnię (zależną od wielkości liter, cudzysłowy obowiązkowe): <jsp:useBean> id="nazwa" scope="page|request|session|application" class="nazwaKlasy" type "nazwaTypu">
Ustawione mogą być następujące atrybuty akcji <jsp:useBean>:
id Określa nazwę komponentu. Jest to klucz pod którym komponent jest przechowywany, jeżeli jego zakres rozciąga się poza stronę. Jeżeli egzemplarz komponentu zapamiętany pod podaną nazwą już istnieje w zakresie strony, egzemplarz ten zostaje wykorzystany na stronie. W pozostałych przypadkach tworzony jest nowy komponent. Na przykład: id="preferencjeUzyt"
scope Określa zakres widoczności komponentu. Wartość musi wynosi page, request, session lub application. Jeżeli page, zmienna jest tworzona jako zmienna egzemplarza. Jeżeli request, zmienna jest przechowywana jako atrybut żądania; jeżeli session, komponent przechowywany jest w sesji użytkownika, a jeżeli application, w kontekście serwletu. Na przykład: scope="session"
Domyślną wartością jest page. class Określa nazwę klasy komponentu. Jest ona wykorzystywana przy pierwszym tworzeniu komponentu. Nazwa klasy musi być podana w pełnej formie. Na przykład: class="com.firma.sledzenie.PreferencjeUzytImpl"
Atrybut class nie jest potrzebny, jeżeli komponent istnieje już w aktualnym zakresie, ale ciągle musi wystąpić atrybut type pozwalający na stworzeni obiektu odpowiedniego typu. Jeżeli wystąpi problem ze stworzeniem danej klasy, strona JSP zgłasza wyjątek InstatiationException. type Określa typ komponentu, który powinien zostać pobrany z systemu, wykorzystywany do utworzenia obiektu po pobraniu z żądania, sesji lub kontekstu. Wartość typu powinna zostać podana w pełnej formie superklasy lub interfejsu dla klasy aktualnej. Na przykład: type="com.firma.sledzenie.PreferencjeUzyt"
Jeżeli typ nie zostanie określony, domyślna wartość jest równa atrybutowi class. Jeżeli typ nie pasuje do prawdziwego typu obiektu, strona JSP zgłasza wyjątek ClassCastException. beanName Atrybut class może zostać zastąpiony atrybutem beanName. Różnica między nimi jest taka, że beanName wykorzystuje Beans.instatiate() do utworzenia egzemplarza komponentu, który poszukuje zserializowanej wersji komponentu (pliku .ser) przed utworzeniem egzemplarza od zera. Pozwala to na wykorzystanie komponentów prekonfigurowanych. Proszę przejrzeć dokumentację Javadoc dla Beans.instatiate() w celu uzyskania większej ilości informacji. Na przykład: BeanName="com.firma.sledzenie.PreferencjeUzytImpl"
Główna część elementu <jsp:useBean> — wszystkie informacje pomiędzy znacznikiem otwierającym <jsp:useBean> a zamykającym — jest interpretowane po utworzeniu komponentu. Jeżeli komponent nie zostanie utworzony (ponieważ w danym zakresie odnaleziono istniejący egzemplarz), wtedy część ta jest ignorowana. Na przykład: <jsp:useBean id="preferencje" class=com.firma.sledzenie.PreferencjeUzytImpl"> Jeżeli ten napis jest widoczny, to utworzono nowy komponent! <jsp:useBean>
Jeżeli nie jest konieczne umieszczenie głównej części, może zostać wykorzystany skrót XML dla pustego znacznika />: <jsp:useBean id="preferencje" class=com.firma.sledzenie.PreferencjeUzytImpl" />
Kontrola parametrów komponentu Akcja <jsp:setProperty> umożliwia parametrom żądania automatyczne (poprzez introspekcję) ustawianie właściwości komponentów osadzonych na stronie. Daje to komponentom automatyczny dostęp do parametrów żądania bez konieczności wywoływania getParameter(). Własność ta może zostać wykorzystana na kilka sposobów. Po pierwsze: <jsp:setProperty name="nazwaKomponentu" property="*" />
Powyższa linia określa, że dowolny parametr żądania o tej samej nazwie i typie, co własność komponentu, powinien zostać wykorzystany do ustawienia tej własności komponentu. Na przykład, jeżeli element posiada metodę ustawWielkosc(int wielkosc) oraz żądanie posiada parametr wielkosc o wartości 12, serwer automatycznie wywoła komponent.ustawWielkosc(12) na początku obsługi żądania. Jeżeli wartość parametru nie może zostać przekonwertowana na właściwy typ, parametr jest ignorowany. (Proszę zauważyć, że pusta wartość parametru łańcuchowego jest traktowana tak, jakby parametr nie istniał, i pusta wartość łańcucha nie zostanie przypisana własności String). Proszę zauważyć, że akcja wykorzystuje skrót XML dla pustego znacznika. Jest to bardzo ważne. Specyfikacja JSP wymaga od wszystkich akcji JSP by posiadały one właściwą formę XML, nawet kiedy są umieszczone w plikach HTML. Poniżej przedstawiono drugi sposób wykorzystania <jsp:setProperty>: <jsp:setProperty name="nazwaKomponentu" property="nazwaWlasnosci" />
Powyższa linia nakazuje ustawienie danej własności, jeżeli istnieje parametr żądania o tej samej nazwie i typie. Na przykład, aby ustawić własność wielkosc, a nie żadną inną, należy wykorzystać następującą akcję: <jsp:setProperty name="preferencje" property="wielkosc" />
Oto trzeci sposób wykorzystania <jsp:setProperty>: <jsp:setProperty name="nazwaKomponentu" property="nazwaWlasnosci" param="nazwaParam" />
Powyższa linia nakazuje ustawienie danej własności, jeżeli występuje parametr żądania o danej nazwie i tym samym typie. Pozwala to parametrowi o pewnej nazwie na ustawianie własności o nazwie innej. Na przykład, aby ustawić własność wielkosc przy pomocy parametru wielkoscCzcionki: <jsp:setProperty name="preferencje" property="wielkosc" param="wielkoscCzcionki" />
Poniżej przedstawiono ostatni sposób wykorzystania: <jsp:setProperty name="nazwaKomponentu" property="nazwaWlasnosci" value="stala" />
Powyższa linia kodu nakazuje nadanie danej własności danej wartości, która zostanie przekonwertowana do właściwego typu, jeżeli okaże się to konieczne. Na przykład, aby ustawić domyślną wielkość na 18 z pominięciem parametru: <jsp:setProperty name="preferencje" property="wielkosc" value="18" /> <jsp:setProperty name="preferencje" property="wielkosc" param="wielkoscCzcionki" />
Zaawansowani użytkownicy powinni wiedzieć, że atrybut value nie musi być stałą; może on zostać określony poprzez wyrażenie, przy pomocy mechanizmu nazywanego wyrażeniem atrybutu czasu uruchomienia. Na przykład, aby upewnić się, że wielkość nigdy nie spadnie poniżej 6: <jsp:setProperty name="preferencje" property="wielkosc" param="wielkoscCzcionki"/> <jsp:setProperty name="preferencje" property="wielkosc" value="<%= Mat.maks(6, preferencje.pobierzWielkosc()) %>" />
Natomiast akcja <jsp:getProperty> dostarcza mechanizmu służącego do odczytywania wartości własności bez konieczności wykorzystywania kodu Javy na stronie. Jego zastosowanie jest podobne do <jsp:setProperty>: <jsp:getProperty name="nazwaKomponentu" property="nazwaWlasnosci" />
Powyższa linia nakazuje dołączenie w jej miejscu wartości danej własności do danego komponentu. Jest ona dłuższa niż wyrażenie, ale pozwala na uniknięcie umieszczania kodu Javy na stronie. Wybór pomiędzy <jsp:getProperty> a wyrażeniem jest kwestią osobistego gustu. Proszę zauważyć, że <jsp:getProperty>, bezpośrednio osadza wartość własności, tak więc jeżeli zawiera ona znaki traktowane przez HTML jako specjalne, może to powodować problemy. Projekt Apache Struts pozwala na rozwiązanie tego problemu przy pomocy własnego znacznika <property>, co zostanie opisane w dalszej części tego rozdziału.
Powitania przy pomocy komponentu Przykład 18.6 przedstawia zastosowanie komponentu JavaBeans na stronie JSP. Strona ta wyświetla „Witaj” przy pomocy WitajKomp. Przykład 18.6. Powitanie przy pomocy JavaBean <%-- witaj3.jsp --%>
<%@ page import="WitajKomp" %>
<jsp:useBean id="witaj" class="WitajKomp"> <jsp:setProperty name="witaj" property="*" />
<TITLE>Witaj
Witaj, <jsp:getProperty name="witaj" property="nazwa" />
Jak można dostrzec, wykorzystanie komponentu JavaBeans na stronie JavaServer Pages może zredukować ilość kodu umieszczoną na stronie. Klasa WitajKomp zawiera logikę określającą nazwę użytkownika, a strona JSP działa jedynie jako szablon. Kod WitajKomp jest przedstawiony w przykładzie 18.7. Plik jego klasy powinien zostać umieszczony w standardowym katalogu klas wspierających (WEB-INF/classes). Przykład 18.7. Klasa WitajKomp public class WitajKomp { private String nazwa = "świecie";
public void ustawNazwe(String nazwa) { this.nazwa = nazwa; }
public String pobierzNazwe() { return nazwa; } }
Jest to chyba najprostszy możliwy komponent. Posiada pojedynczą własność nazwa ustawianą przy pomocy ustawNazwe(), a odczytywaną przy pomocy pobierzNazwe(). Domyślną wartością nazwa jest świecie, ale kiedy nadchodzi żądanie zawierające parametr nazwa, własność jest automatycznie ustawiana przez serwer przy pomocy wywołania ustawNazwe(). W celu przetestowana mechanizmu, proszę obejrzeć stronę http://serwer:port/witaj3.jsp. Powinien pojawić się wynik podobny do przedstawionego na rysunku 18.4.
Rysunek 18.4. Powitanie przy pomocy JavaServer Pages we współpracy z komponentem JavaBeans
Istnieje jedna kwestia, na którą należy zwrócić uwagę: na niektórych serwerach (włączając w to Tomcat 3.2), jeżeli istnieje komponent o zakresie session lub application, a implementacja klasy komponentu zostanie zmieniona, w późniejszych żądaniach może pojawić się ClassCastException. Wyjątek ten pojawia się, ponieważ kod generowanego serwletu musi wywołać egzemplarz komponentu, który pobierany jest z sesji lub aplikacji, a typ starego komponentu przechowywany w sesji lub aplikacji nie pasuje do spodziewanego typu nowego komponentu. Najprostszym rozwiązaniem jest ponowne uruchomienie serwera.
Dołączenia i przekazania Poprzez połączenie instrukcji i akcji, JSP umożliwia obsługę dołączeń i przekazań. Istnieją dwa typy dołączeń i jedno przekazań. Pierwszym dołączeniem jest instrukcja include: <%@ include file="SciezkaDoPliku" %>
Powyższe dołączenie następuje w czasie tłumaczenia, co oznacza, że następuje podczas tworzenia serwletu działającego w tle. Cała zawartość zewnętrznego pliku jest dołączana tak, jak gdyby była bezpośrednio umieszczona na stronie JSP. Programiści C mogą dostrzec jej bliskie podobieństwo do #include. Ścieżka do pliku jest zakotwiczona w katalogu macierzystym kontekstu (tak więc /indeks.jsp odnosi się do index.jsp aktualnej aplikacji WWW), a ścieżka nie może sięgać poza katalog macierzysty kontekstu (proszę nie próbować ../../../innyKontekst). Zawartość wewnątrz pliku jest zazwyczaj fragmentem strony, nie całą stroną, tak więc można pomyśleć o zastosowaniu rozszerzenia pliku .inc lub .jin w celu wskazania tego faktu. Poniższa strona JSP wykorzystuje kilka instrukcji dołączenia w celu utworzenia strony ze zbioru elementów (elementy nie są pokazane): <%@ include file="/naglowek.html" %> <%@ include file="obliczNazwe.inc" %> Witaj, <%= nazwa %> <%@ include file="/stopka.html" %>
Skąd pochodzi zmienna nazwa? Jest ona tworzona przez plik obliczNazwe.inc. Ponieważ zawartość dołączanego pliku jest dołączana bezpośrednio, nie występuje oddzielenie zakresu zmiennej. Drugim typem dołączenia jest akcja <jsp:include>: <jsp:include page="sciezkaDoZasobuDynamicznego" flush="true" />
Powyższe dołączenie następuje w czasie żądania. Nie jest to surowe dołączenie takie, jak w instrukcji include; zamiast tego serwer uruchamia określony zasób dynamiczny i dołącza jego wynik do zawartości wysyłanej do klienta. Niewidocznie akcja <jsp:include> generuje kod, który wywołuje metodę include() RequestDispatcher, tak więc do <jsp:include> stosują się te same zasady wykonania, co do include() — dołączana strona musi być dynamiczna, nie może ustawiać kodu stanu, nie może ustawiać żadnych nagłówków, a ścieżka strony jest zakotwiczona w katalogu macierzystym kontekstu3. Wymagany jest atrybut flush, który w JSP 1.1 musi być ustawiony na true. Wskazuje to na konieczność opróżnienia bufora
3
Istnieje jedna drobna różnica pomiędzy metodą include() i akcją <jsp:include> — metoda include() wymaga, żeby ścieżka do strony rozpoczynała się od /. Akcja <jsp:include> dodatkowo zezwala na względne ścieżki takie, jak ../indeks.jsp, tak długo, jak ścieżka nie wychodzi poza aktualny kontekst.
odpowiedzi przed dołączeniem. Zważywszy na możliwości Servlet API 2.2, wartość false nie może być obsługiwana; spodziewane jest, że JSP 1.2 utworzone na podstawie Servlet API 2.3 będzie zezwalać na wartość false. Jako przykład, poniższa akcja <jsp:include> dołącza zawartość generowaną przez wywołanie strony powitanie.jsp. Strona powitanie.jsp może wyglądać podobnie do witaj1.jsp poza tym, że pożądane może być usunięcie otaczającego kodu HTML sprawiającego, że witaj1.jsp jest kompletną stroną HTML. <jsp:include page="/powitanie.jsp" />
Akcja <jsp:include> może opcjonalnie zawierać w swojej głównej części dowolną ilość znaczników <jsp:param>. Znaczniki te dodają parametry do dołączanego żądania. Na przykład, poniższa akcja przekazuje powitaniu domyślną nazwę: <jsp:include page="/powitanie.jsp"> <jsp:param name="domyslnaNazwa" value="Nowy użytkownik" />
JSP może także przekazywać żądanie przy pomocy akcji <jsp:forward>: <jsp:forward page="sciezkaDoZasobuDynamicznego" />
Przekazanie powoduje przejęcie kontroli obsługi żądania przez konkretny zasób. Tak jak w przypadku akcji <jsp:include> jest ono wykonywane w czasie żądania i jest oparte na metodzie forward() RequestDispatcher. Stosowane są zasady wykorzystania forward() — w czasie przekazania cały zbuforowany wynik zostaje wyczyszczony, a jeżeli stało się to wcześniej, system zgłasza wyjątek. Poniższa akcja przekazuje żądanie specjalnej stronie, jeżeli użytkownik nie jest zalogowany: <% if (session.getAttribute("uzyt") == null { %> <jsp:forward page="/logowanie.jsp" /> <% } %>
Akcja <jsp:forward> również przyjmuje znaczniki <jsp:param>.
Aplikacja „Narzędzia” W tym momencie, znając już zasady dołączeń i osadzania JavaBeans na stronach JSP, można wykorzystać te własności do stworzenia aplikacji wyświetlającej narzędzia. Na stronie JSP zostanie osadzony komponent dający stronie dostęp do informacji na temat narzędzi i pozwalający na traktowanie strony jako przeglądarki tych danych. Przykład 18.8 przedstawia stronę JSP o nazwie widoknarz.jsp. Przykład 18.8. Aplikacja przeglądająca narzędzia przy pomocy JSP <%-- widoknarz.jsp --%>
<% String tytul = "Lista narzędzi"; String tytul2 = "Lista narzędzi do tworzenia zawartości"; String opis = "
Bez narzędzi, ludzie nie są niczym więcej niż zwierzętami. " + I to dość słabymi. Poniżej przedstawiono listę opartych na " + serwletach narzędzi do tworzenia zawartości, które można " + wykorzystać w celu wzmocnienia się.";
%>
<%@ include file="/naglowek.jsp" %>
<%@ page session="false" %> <%@ page errorPage="/bladBierz.jsp" %>
<jsp:useBean id="narzkomp" class="NarzKomp" scope="application"> <jsp:setProperty name="narzkomp" property="plikNarz" value='<%= application.getInitParameter("plikNarz") %>' />
<% Narzedzie[] narzedzia = plikNarz.pobierzNarz(request.getParameter("stan"));
for (int i = 0; i < narzedzia.length; i++) { Narzedzie narzedzie = narzedzia[i]; %>
<%= narzedzie.nazwa %>
<% if (narzedzie.czyNowy(45)) { %> (Nowość!) <% } else if (narzedzie.czyUaktualniony(45)) { %> (Uaktualniony!) <% } %>
"><%= narzedzie.domURL %>
<%= narzedzie.komentarz %>
<% } %>
<%@ include file="/stopka.jsp" %>
Na początku wewnątrz skryptletu, jako łańcuchy String, definiowane są tytuły i opis strony. Następnie wykorzystana jest instrukcja include w celu dołączenia standardowej zawartości nagłówka z pliku naglowek.jsp oraz standardowej zawartości stopki (na końcu pliku) z pliku stopka.jsp. Instrukcja include umieszcza zawartość plików nagłówka i stopki do pliku podczas fazy tłumaczenia, tak więc zmienne tytul, tytul2 i opis są widoczne wewnątrz dołączanych plików, i plik naglowek.jsp wykorzystuje te zmienne. Pliki naglowek.jsp i stopka.jsp są przedstawione w przykładach 18.9 i 18.10. Przykład 18.9. Plik naglowek.jsp <%-- naglowek.jsp --%> <%-- Zależy od obecności zmiennych tytul, tytul2 i opis --%>
<TITLE><%= tytul %>
