JavaServer Pages (JSP) är en standard Java-tillägg som definieras ovanpå servlettillägg. Syftet med JSP är att göra det lättare att skapa och hantera dynamiska webbsidor.

Som tidigare nämnts stöder den fria Tomcat-implementeringen från jakarta.apache.org automatiskt JSP.

JSP låter dig kombinera HTML-webbsidor med delar av Java-kod i samma dokument. Java-koden är inslagen i speciella taggar som talar om för JSP-behållaren att den ska använda koden för att generera ett enstaka dokument eller en del av det. Fördelen med JSP är att du kan innehålla ett enda dokument som representerar både sidan och Java-koden som ingår i den. Nackdelen är att den som underhåller sidan JSP behöver ha erfarenhet av både HTML och Java (visuella JSP-sidbyggare förväntas dock över tid).

Första gången JSP:n laddas, laddas den av JSP-behållaren (som vanligtvis är associerad med, eller en del av, webbservern), sedan genereras servletkoden, som måste markeras med JSP-taggar, automatiskt, kompilerade och laddade i servletbehållaren. Den statiska delen av HTML-sidan skapas genom att skicka ett statiskt objekt av typen String till metoden write(). Den dynamiska delen ingår direkt i servleten.

Från och med då, så länge som den ursprungliga JSP-sidan inte modifieras, kommer den att bete sig som om den vore en statisk HTML-sida associerad med servleten (dock genereras all HTML-kod faktiskt av servleten). Om du ändrar källkoden för en JSP kommer den automatiskt att kompileras och laddas om nästa gång sidan efterfrågas. Naturligtvis, på grund av denna dynamik, kommer du att se ett långsamt svar för den första JSP-åtkomsten. Men eftersom JSP vanligtvis används mycket oftare än den ändras, kommer du vanligtvis inte att känna effekten av denna fördröjning.

Strukturen för en JSP-sida är en korsning mellan en servlet och en HTML-sida. JSP-taggar börjar och slutar med en vinkelparentes, precis som HTML-koder, men taggarna innehåller också procenttecken, så alla JSP-taggar betecknas så här:

Det inledande procenttecknet kan följas av andra tecken som anger den exakta typen av JSP-kod i taggen.

Här är ett extremt enkelt JSP-exempel som använder ett standard Java-biblioteksanrop för att få aktuell tid i millisekunder, som sedan divideras med 1000 för att få tiden i sekunder. Eftersom JSP-uttrycket används (<%=), результат вычислений преобразуется в строку, а затем поместится в сгенерированную Web страницу:

//:! c15:jsp:ShowSeconds.jsp< html >< body > < H1 >Tiden i sekunder är:<%= System . currentTimeMillis ()/ 1000 %> ///:~

I den här bokens JSP-exempel betyder ett utropstecken i den första "kommentarraden" att den första och sista raden inte kommer att inkluderas i själva kodfilen som är placerad i bokens källträd.

När en klient gör en begäran till en JSP-sida måste webbservern konfigureras för att vidarebefordra begäran till JSP-behållaren, som sedan anropar sidan. Som nämnts tidigare, första gången en sida begärs genereras komponenterna som anges på sidan, och en eller flera servlets kompileras av JSP-behållaren. I exemplet ovan kommer servleten att innehålla konfigurationskoden för HTTPServletResponse-objektet, som producerar ett PrintWriter-objekt (som alltid kallas ut), och sedan slå på timingen med ett mycket kort uttalande, men den genomsnittliga HTML-programmeraren/webbdesignern är inte har erfarenhet av att skriva sådan kod.

Implicita objekt

Servlets inkluderar klasser som tillhandahåller praktiska verktyg som HttpServletRequest, HttpServletResponse, Session etc. Objekt av dessa klasser är inbyggda i JSP-specifikationen och är automatiskt tillgängliga för användning i din JSP utan att skriva ytterligare rader kod. De implicita JSP-objekten beskrivs i tabellen nedan.

implicita variabler	Skriv (javax.servlet)	Beskrivning	Synlighetsområde
begäran	Protokollberoende undertyp av HttpServletRequest	Förfrågan som ringde till tjänsten.	begäran
svar	Protokollberoende undertyp av HttpServletResponse	Svar på en förfrågan.	sida
sidaKontext	jsp.PageContext	Sidkontexten som kapslar in implementeringsspecifika funktioner och ger bekvämlighetsmetoder och tillgång till namnutrymmet för denna JSP.	sida
session	Protokollspecifik http.HttpSession undertyp	Sessionsobjektet som skapades för klientens begäran. Se Session-objektet för en servlet.	session
Ansökan	ServletContext	Servletkontext erhållen från servletkonfigurationsobjektet (till exempel getServletConfig(), getContext().	app
ut	jsp.JspWriter	Ett objekt som skriver till utgångsströmmen.	sida
config	ServletConfig	ServletConfig för denna JSP.	sida
sida	java.lang.Object	En instans av den här sidans implementeringsklass som hanterar den aktuella begäran.	sida

Omfattningen av varje objekt kan variera avsevärt. Till exempel har sessionsobjektet ett omfång som är större än en sida eftersom det kan sträcka sig över flera klientförfrågningar och sidor. Ett applikationsobjekt kan tillhandahålla tjänster till en grupp JSP-sidor som tillsammans representerar en webbapplikation.

JSP-direktiv

Direktiv är meddelanden till JSP-behållaren och betecknas med "@"-symbolen:

<% @ directive { attr = "value" }* %>

Direktiven skickar ingenting till utgångsströmmen, men de är viktiga för att ställa in sidans JSP-attribut och container JSP-beroenden. Till exempel, raden:

<% @ page language = "java" %>

berättar att skriptspråket som används på JSP-sidan är Java. Faktum är att JSP-specifikationen bara beskriver skriptsemantiken för språkattribut som motsvarar "Java". Syftet med detta direktiv är att bygga in flexibilitet i JSP-tekniken. I framtiden, om du väljer ett annat språk, säg Python (ett bra val för skript), bör ett sådant språk ha stöd för Java Run-time Environment, vilket exponerar Java-teknikobjektmodellen för skriptmiljön, särskilt för den implicita miljön. variabler definierade ovan, egenskaperna hos JavaBeans och offentliga metoder.

De viktigaste direktiven är siddirektiven. De definierar flera sidattribut och hur dessa attribut interagerar med JSP-behållaren. Dessa attribut inkluderar: language, extends, import, session, buffer, autoFlush, isThreadSafe, info och errorPage. Till exempel:

<% @ page session = "true" import =" java . util .*" %>

Denna rad indikerar först och främst att den här sidan kräver deltagande i en HTTP-session. Eftersom vi inte har ställt in ett språkdirektiv, är JSP-behållaren som standard Java och en implicit skriptspråkvariabel som kallas session av typen javax.servlet.http.HttpSession. Om direktivet skulle använda false, skulle den implicita sessionsvariabeln inte vara tillgänglig. Om sessionsvariabeln inte är definierad är den som standard "true".

Importattributet beskriver de typer som är tillgängliga för skriptmiljön. Detta attribut används på samma sätt som i programmeringsspråket Java, det vill säga en kommaseparerad lista över normala importsatser. Den här listan importeras av sidans översatta JSP-implementering och är tillgänglig för skriptmiljön. Låt oss återigen säga att detta för närvarande bara definieras om språkdirektivets värde är "java".

JSP-skriptelement

När du har använt direktiv för att skapa en skriptmiljö kan du använda skriptelement. JSP 1.1 har tre skriptspråkselement - deklaration, skriptlet och uttryck. En deklaration deklarerar element, scriptlets är fragment av instruktioner och uttryck är kompletta språkuttryck. I JSP börjar varje skriptelement med "<%". Синтаксис каждого из них:

<%! declaration %> <% scriptlet %> <%= expression %>

Mellanslag efter "<%!", "<%", "<%=" и перед "%>" krävs inte.

Alla dessa taggar är baserade på XML; du kan till och med säga att en JSP-sida kan mappas till ett XML-dokument. Motsvarande syntax för skriptelementen ovan kan vara:

< jsp : declaration >deklaration < jsp : scriptlet >skriptlet < jsp : expression >uttryck

Dessutom finns det två typer av kommentarer:

<%-- jsp comment --%>

Det första formuläret låter dig lägga till kommentarer till JSP-källkoden som inte kommer att visas i någon form på HTML-sidan som skickas till klienten. Naturligtvis är den andra formen av kommentarer inte JSP-specifik – det är bara en vanlig HTML-kommentar. Det intressanta är att du kan bädda in JSP-kod i en HTML-kommentar och resultatet kommer att visas på den resulterande sidan.

Deklarationer används för att deklarera variabler och metoder i ett skriptspråk (för närvarande endast i Java) som används på en JSP-sida. Deklarationen måste vara ett komplett Java-uttryck och kan inte producera någon utdata till utdataströmmen. I Hello.jsp-exemplet nedan är deklarationerna för variablerna loadTime, loadDate och hitCount kompletta Java-uttryck som deklarerar och initierar nya variabler.

//:! c15:jsp:Hello.jsp<%-- Den här JSP-kommentaren kommer inte att visas i den genererade HTML-koden --%> <%-- Detta är ett JSP-direktiv: --%> <%@ page import="java.util.*" %> <%-- Denna förklaring: --%> <% ! long loadTime = System.currentTimeMillis (); Date loadDate = new Date (); int hitCount = 0 ; %> <%-- De följande raderna är resultatet av JSP-uttryck som infogats i den genererade HTML-koden; "="-tecknet indikerar ett JSP-uttryck --%>

Den här sidan har laddats<%= loadDate %>

Hej världen! Dess<%= new Date () %>

Här är ett objekt:<%= new Object () %>

Den här sidan har varit uppe<%= (System.currentTimeMillis ()- loadTime )/ 1000 %>sekunder

Sidan har nåtts<%= ++ hitCount %>gånger sedan dess<%= loadDate %>

<%-- "Scriptlet" som skriver på serverkonsolen och på klientsidan. Observera att du måste sätta ";": --%> <% System.out.println ("Goodbye" ); out.println ("Cheerio" ); %> ///:~

När du kör det här programmet kommer du att se att variablerna loadTime, loadDate och hitCount håller sina värden mellan sidträffar, så de är tydligt fält och inte lokala variabler.

I slutet av exemplet finns ett scriptlet som skriver "Goodbye" till webbserverns konsol och "Cheerio" till JspWriters implicita utdataobjekt. Ett scriptlet kan innehålla vilken kod som helst som är giltiga Java-instruktioner. Skriplet exekveras under förfrågningsbearbetning. När alla scriptletfragment i en given JSP kombineras i den ordning som de visas på JSP-sidan, måste de producera en giltig sats definierad för Java-programmeringsspråket. Huruvida scriptlet kommer att producera utdata till utdataströmmen eller inte beror bara på scriptletkoden. Du bör vara medveten om att ett scriptlet kan agera på objekt som är synliga för det.

JSP-uttryck kan hittas varvat med HTML i mittsektionen av Hello.jsp. Uttryck måste vara kompletta Java-instruktioner som utvärderas, gjuts till en sträng och skickas till utdata. Om resultatet av instruktionen inte kan kastas till en sträng (String), kommer en ClassCastException att kastas.

Extrahera fält och värden

Följande exempel liknar det som visades tidigare i servletsektionen. Första gången sidan visas upptäcker den att du inte har några fält och returnerar en sida som innehåller formuläret med samma kod som i servletexemplet, men i JSP-format. När du skickar ett formulär med fält ifyllda till samma JSP-URL, upptäcker sidan fälten och renderar dem. Detta är en trevlig teknik eftersom den låter dig få två sidor, en som innehåller ett formulär som användaren kan fylla i, och den andra innehåller svarskoden för den här sidan, i en enda fil, vilket underlättar skapande och underhåll.

//:! c15:jsp:DisplayFormData.jsp<%-- Hämta data från ett HTML-formulär. --%> <%-- Denna JSP genererar också ett formulär. --%> <%@ page import="java.util.*" %>

DisplayFormData

<% Enumeration flds = request.getParameterNames (); if (! flds.hasMoreElements ()) { // Нет полей %>

<% for (int i = 0 ; i < 10 ; i ++) { %>fält<%= i %> :
<% } %>

<% } else { while (flds.hasMoreElements ()) { String field = (String ) flds.nextElement (); String value = request.getParameter (field ); %>

<%= field %> = <%= value %>

<% } } %>

///:~

Den mer intressanta egenskapen med detta exempel är att det visar hur scriptlet-kod kan blandas med HTML-kod även vid den punkt där HTML genereras inuti en Java-loop. Detta är särskilt användbart för att bygga former av alla slag, annars skulle det vara nödvändigt att infoga repetitiv HTML-kod.

JSP-sidattribut och omfattning

När du tittar igenom HTML-dokumentationen för servlets och JSP:er hittar du en funktion som rapporterar information om den servlet eller JSP som för närvarande körs. Följande exempel visar några av dessa data.

//:! c15:jsp:PageContext.jsp<%-- Visa sidkontextattribut--%> <%-- Observera att du kan inkludera vilken mängd kod som helst i scriptlet-taggar --%> <%@ page import="java.util.*" %> Server namn:<%= config.getServletName () %>
Servlet-behållare stöder servletversion:<% out.print (application.getMajorVersion () + "." + application.getMinorVersion ()); %>
<% session.setAttribute ("My dog" , "Ralph" ); for (int scope = 1 ; scope <= 4 ; scope ++) { %>

Omfattning:<%= scope %>

<% Enumeration e = pageContext.getAttributeNamesInScope(omfattning); while (e.hasMoreElements()) (out.println("\t

" + e.nextElement() + "

" ); } } %>

///:~

Det här exemplet visar också hur man använder inline HTML och skriver till ut för att skapa en HTML-sida som ett resultat.

Den första informationen producerar namnet på servleten, som troligen bara kommer att vara "JSP", men det beror på din implementering. Du kan också bestämma den aktuella versionen av servletbehållaren med hjälp av applikationsobjektet. Och slutligen, efter att sessionsattributet har ställts in, visas "attributnamnen" i det normala omfånget. Du använder vanligtvis inte scope i de flesta JSP:er; de visas här helt enkelt för att lägga till intresse för detta exempel. Det finns tre scope-attribut: page scope (scope 1), request scope (scope 2), session scope (scope 3 - bara ett element är tillgängligt här - det är "Min hund" som läggs till precis innan loopen) och scope application (scope) 4) baserat på ServletContext-objektet. Det finns en ServletContext för varje "webbapplikation" i varje Java-maskin. ("Webbapplikation" är en uppsättning servlets och innehåll installerat under en viss delmängd av server-URL:er, såsom /catalog. De installeras med en konfigurationsfil.) I applikationsomfånget kommer du att se objekt som representerar sökvägarna för arbetskatalog och tillfällig katalog.

Sessionsmanipulation i JSP

Sessioner introducerades i föregående servletsektion och är även tillgängliga i JSP:er. Följande exempel undersöker sessionsobjekt och låter dig manipulera hur lång tid det tar innan en session blir ogiltig.

//:! c15:jsp:SessionObject.jsp<%-- Hämta och ställa in värden för sessionsobjekt --%>

sessions-id:<%= session.getId () %>

Denna session skapades kl<%= session.getCreationTime () %>

Old MaxInactiveInterval =<%= () %>

<% session.setMaxInactiveInterval(5 ); %>

Nytt MaxInactiveInterval=<%= session.getMaxInactiveInterval() %>

Om sessionsobjektet "Min hund" fortfarande finns kvar kommer detta värde att vara icke-null:

Sessionsvärde för "Min hund" =<%= session.getAttribute ("My dog" ) %>

<%-- Låt oss nu lägga till sessionsobjektet "Min hund" --%> <% session.setAttribute ("My dog" , new String ("Ralph" )); %>

Min hund heter<%= session.getAttribute ("My dog" ) %>

<%-- Se om "Min hund" vandrar till en annan form --%>

< /FORM>

///:~

Sessionsobjektet tillhandahålls som standard, så det är tillgängligt utan ytterligare kod. Anropet till getID(), getCreationTime() och getMaxInactiveInterval() används för att visa information om detta sessionsobjekt.

När du först får den här sessionen kommer du att se att MaxInactiveInterval är till exempel 1800 sekunder (30 minuter). Det beror på din JSP/servlet-containerkonfiguration. MaxInactiveInterval förkortas till 5 sekunder för att göra saker mer intressanta. Om du laddar om sidan innan 5 sekunder har gått ser du:

Sessionsvärde för "Min hund" = Ralph

Men om du väntar längre blir "Ralph" null.

För att se hur sessionsinformation överförs till andra sidor, och även för att se effekten av att ogiltigförklara sessionsobjektet kontra att bara låta det löpa ut, har två nya sidor skapats. Den första (nås genom att klicka på knappen "ogiltigförklara" i SessionObject.jsp) läser sessionsinformationen och ogiltigförklarar sedan sessionen explicit:

//:! c15:jsp:SessionObject2.jsp<%-- Sessionsobjekt migrerat --%>

sessions-id:<%= session.getId () %>

Sessionsvärde för "Min hund"<%= session.getValue ("My dog" ) %>

<% session.invalidate (); %>

///:~

För att experimentera med detta, uppdatera SessionObject.jsp och klicka sedan omedelbart på knappen "ogiltigförklara" för att gå till sidan SessionObject2.jsp. Vid det här laget kommer du fortfarande att se "Ralph" och direkt efter det (innan 5 sekundersintervallet går upp), uppdatera SessionObject2.jsp för att se att sessionen ogiltigförklarades och "Ralph" är borta.

Om du går tillbaka till SessionObject.jsp, uppdatera sidan så att du har 5 sekunders intervall igen, klicka sedan på knappen "Keep Around" så kommer du till följande SessionObject3.jsp-sida, som inte ogiltigförklarar sessionen:

//:! c15:jsp:SessionObject3.jsp<%-- Övergång av sessionsobjektet genom sidor --%>

sessions-id:<%= session.getId () %>

Sessionsvärde för "Min hund"<%= session.getValue ("My dog" ) %>

///:~

Eftersom denna sida inte ogiltigförklarar sessionen kommer "Ralph" att finnas kvar under varje siduppdatering tills uppdateringsintervallet på 5 sekunder har passerat. Den skiljer sig inte mycket från en "Tomagotchi"-leksak - så länge du leker med "Ralph" kommer han att vara där, annars försvinner han.

Skapa och ändra cookies

Cookies introducerades i föregående avsnitt om servlets. Återigen, kortheten i JSP gör det lättare att hantera cookies än med servlets. Följande exempel visar detta genom att hämta cookien som kom i begäran, läsa och ändra maxåldern (utgångsdatum) och bifoga den nya cookien till svarsförfrågan:

//:! c15:jsp:Cookies.jsp<%-- Det här programmet beter sig olika i olika webbläsare! --%>

sessions-id:<%= session.getId () %>

<% Cookie cookies = request.getCookies (); for (int i = 0 ; i < cookies.length ; i ++) { %>Cookies namn:<%= cookies [ i ]. getName () %>
värde:<%= cookies [ i ]. getValue () %>
Gammal maxålder i sekunder:<%= cookies [ i ]. getMaxAge () %>
<% cookies [ i ]. setMaxAge (5 ); %>Ny maxålder i sekunder:<%= cookies [ i ]. getMaxAge () %>
<% } %> <% ! int count = 0 ; int dcount = 0 ; %> <% response.addCookie (new Cookie ("Bob" + count ++, "Dog" + dcount ++)); %>

///:~

Eftersom varje webbläsare lagrar cookies på olika sätt, kan du se olika beteende i olika webbläsare (inte övertygad, men detta kan vara någon typ av bugg som kan vara fixad när du läser detta). Du kan också få andra resultat om du avslutar webbläsaren och startar den jämfört med om du besöker en annan sida och sedan återgår till Cookies.jsp. Observera att användningen av sessionsobjektet verkar lämpligare än att använda cookies direkt.

Efter att sessions-ID:t har visats visas varje cookie i cookie-arrayen som följde med begärandeobjektet på sidan tillsammans med dess maximala ålder. Maxåldern ändras och visas igen för att kontrollera det nya värdet, sedan läggs en ny cookie till svaret. Din webbläsare kan dock ignorera denna maximala ålder; det är värt att spela med det här programmet och ändra det maximala åldersvärdet för att se beteendet under olika webbläsare.

Slutsats om JSP

Det här avsnittet är bara en snabb översikt av JSP, och även med det som tas upp här (tillsammans med vad du kommer att lära dig om Java i resten av boken, och tillsammans med dina kunskaper om HTML), kan du börja skriva snygga webbsidor med JSP. JSP-syntaxen är inte menad att vara svårbegriplig eller komplicerad, så om du förstår vad som har presenterats i det här avsnittet är du redo att vara produktiv med JSP. Du kan hitta mer information i de flesta tillgängliga servletböcker eller på java.sun.com.

Det är särskilt praktiskt att ha tillgång till JSP, även om ditt mål bara är att skapa servlets. Du kommer att upptäcka att om du har en fråga om beteendet hos en servletfunktion är det mycket enklare och snabbare att skriva ett JSP-testprogram för att få ett svar än det är att skriva en servlet. En del av bekvämligheten är att du måste skriva mindre kod och kan blanda renderad HTML med Java-kod, men denna fördel blir extra tydlig när du ser att JSP Container hanterar all JSP-omkompilering och omladdning åt dig när källkoden ändras. .

Men fasan med JSP:er är att du måste tänka på att skapa en JSP kräver en högre nivå av skicklighet än bara Java-programmering eller bara att skapa webbsidor. Dessutom är det inte lika lätt att felsöka en trasig JSP som det är med ett Java-program, eftersom (för närvarande) felmeddelandena är mer oklara. Detta bör förändras i takt med att utvecklingssystemen förbättras, men vi kan också se andra Java- och webbaserade teknologier som är bättre anpassade till webbdesigners kompetens.

Övningar

1. Skapa en JSP-sida som skriver ut en textrad med en tagg

   . Ställ in färgen på denna text slumpmässigt med hjälp av koden som är inbäddad på JSP-sidan. Om du inte har en befintlig JSP-behållare måste du ladda ner, installera och köra Tomcat från jakarta.apache.org

2. Ändra det maximala åldersvärdet i Cookies.jsp och observera beteendet i olika webbläsare. Notera också skillnaden mellan att besöka en sida igen och att ladda ner/ladda webbläsaren. Om du inte har en befintlig JSP-behållare, måste du ladda ner, installera och köra Tomcat från jakarta.apache.org för att kunna köra JSP.
3. Skapa en JSP med ett fält som låter användaren ange sessionens utgångstid och ett andra fält som innehåller data som lagras i sessionen. Skicka-knappen uppdaterar sidan och hämtar aktuell sessionstid och sessionsdata, och sätter dem sedan som standardvärde i ovanstående fält. Om du inte har en befintlig JSP-behållare, måste du ladda ner, installera och köra Tomcat från jakarta.apache.org för att kunna köra JSP.

Servlets låter dig ta emot förfrågningar från klienten, göra lite arbete och visa resultaten på skärmen. Servleten fungerar bra fram till ögonblicket när det kommer till att bearbeta information, d.v.s. innan du visar information på skärmen. Du kan infoga ganska komplex logik i en servlet, göra anrop till databasen och mycket, mycket mer som är nödvändigt för applikationen. Men här för att utföra en utmatning till skärmen i servleten - det är väldigt obekvämt. Men hur är det när man utvecklar komplexa designidéer och sedan gör ändringar i användargränssnittet? Designteknik Java Server Pages (JSP)är en av J2EE-teknologierna, som är en förlängning av servletteknologin för att göra det lättare att arbeta med webbinnehåll. JSP-sidor gör det enkelt att separera webbinnehåll i en statisk del och en dynamisk del, vilket möjliggör återanvändning av tidigare definierade komponenter. Java Server Pages-utvecklare kan använda JavaBeans-komponenter och skapa sina egna anpassade taggbibliotek som kapslar in komplex dynamisk funktionalitet. Java Server Pages-specifikationen (http://java.sun.com/products/jsp) ärver och utökar servlet-specifikationen (http://java.sun.com/products/servlets). Precis som servlets är JSP-komponenter webbkomponenter och finns i en webbbehållare. JSP-sidor är oberoende av en viss webbbehållareimplementering, vilket gör dem återanvändbara. Förutom klasser och gränssnitt för servletprogrammering (paket javax.servlet Och javax.servlet/http), i paket javax.servlet.jsp Och javax.servlet.jsp.target innehåller klasser och gränssnitt relaterade till Java Server Pages-programmering. En fullständig beskrivning av Java Server Pages-tekniken finns i specifikationen på (java.sun.com/products/jsp/download.htm)

Översikt över Java Server Pages Technology

Java Server Pages-tekniken innehåller fyra nyckelkomponenter:

1. direktiv (direktiv)är meddelanden för JSP-behållaren, som gör det möjligt att definiera sidparametrar, ansluta andra resurser, använda sina egna icke-standardiserade taggbibliotek.
2. Handlingar (handlingar) kapsla in funktionalitet i fördefinierade taggar som kan bäddas in i en JSP-sida. Åtgärder utförs ofta baserat på information som skickas till servern som en del av en begäran från en viss klient. Åtgärder kan också skapa Java-objekt för användning i JSP-skript.
3. Scriptlets (scriptlets) låter dig bädda in Java-kod i JSP-sidor som interagerar med sidobjekt när du bearbetar en begäran.
4. Tagga bibliotek (taggbibliotek)är en integrerad del av taggförlängningsmekanismen, som låter dig utveckla och använda dina egna taggar.

Närvaron av data med en oföränderlig struktur avgör valet av programmeraren för att bestämma vilken teknik som ska användas: servlets eller JSP-sidor. Programmerare föredrar att använda JSP-sidor om det mesta av innehållet som skickas till klienten är oföränderlig data och endast en liten del av innehållet genereras dynamiskt med Java-kod. Servlets är att föredra om endast en liten del av innehållet som skickas till klienten är data med en oföränderlig struktur. Faktum är att enskilda servlets inte alls genererar innehåll åt klienten, de utför en specifik uppgift på uppdrag av klienten och sedan anropar andra servlets eller JSP-sidor för att skicka svaret. Det bör noteras att i många fall är servlets och JSP-sidor utbytbara. Liksom servlets körs JSP-sidor vanligtvis på sidan av en webbserver, som kallas en JSP-behållare. När en JSP-aktiverad webbserver tar emot den första begäran om en JSP-sida, översätter JSP-behållaren JSP-sidan till en Java-servlet som servar den aktuella begäran och alla efterföljande förfrågningar för den sidan. Om fel uppstår när en ny servlet kompileras, resulterar dessa fel i kompileringsfel. JSP-behållaren, under översättningsfasen, lägger Java-satserna som implementerar JSP-sidesvaret i en metod _jspService. Om servleten kompilerar utan fel anropar JSP-behållaren metoden _jspService att behandla begäran. JSP-sidan kan bearbeta begäran direkt, eller så kan den anropa andra webbapplikationskomponenter för att hjälpa till att bearbeta begäran. Eventuella fel som uppstår under bearbetningen kommer att orsaka undantag i webbservern under begärandefasen. All statisk HTML-text, som refereras till i JSP-dokumentationen HTML-mall(HTML-mall) skickas omedelbart till utgångsströmmen. Sidoutputströmmen är buffrad. Buffring tillhandahålls av klassen JspWriter, utökande klass Författare. Standardbuffertstorleken är begränsad till 8 KB, men den kan ändras med attributet buffert märka <%@ page> . Närvaron av en buffert gör att du kan skriva svarsrubriker till utdataströmmen tillsammans med utdatatexten. I bufferten kommer rubrikerna att placeras före texten. Det räcker alltså att skriva en JSP-sida, spara den i en fil med tillägget jsp och installera filen i behållaren, precis som du skulle göra en HTML-sida, utan att behöva oroa dig för kompilering. Under installationen kan du ställa in de initiala parametrarna för JSP-sidan på samma sätt som de initiala parametrarna för servleten.

Senast uppdaterad: 02.09.2018

Representerar en teknik som låter dig skapa dynamiska webbsidor. JSP:er (tillsammans med servlets) var ursprungligen det dominerande tillvägagångssättet för Java-webbutveckling i början av Java EE. Och även om de nu har gett vika för en annan teknik - JSF, fortsätter ändå JSP:er att användas flitigt.

I grund och botten är Java Server Page eller JSP html-kod varvat med Java-kod. Samtidigt är jsp-sidor inte vanliga html-sidor. När en begäran kommer in för en specifik JSP-sida, bearbetar servern den, genererar html-kod från den och skickar den till klienten. Som ett resultat ser användaren, efter att ha kommit åt JSP-sidan, en vanlig HTML-sida i sin webbläsare.

Precis som vanliga statiska webbsidor måste JSP-filer finnas på en webbserver som vanliga användare kan komma åt med hjälp av http-protokollet, till exempel genom att skriva in önskad adress i webbläsarens adressfält. Men för att servern ska kunna bearbeta JSP-filer måste den använda JSP-motorn (), som också kallas JSP-behållaren. Det finns många JSP-motorer där ute, och de implementerar alla samma specifikation och fungerar i allmänhet på samma sätt. Men när kod porteras från en webbserver till en annan kan små ändringar fortfarande krävas.

I det här fallet, för att arbeta med JSP:n, kommer vi att använda Apache Tomcat, som är både en webbserver och en servlet och JSP-behållare.

Låt oss skapa en enkel JSP-sida. För att göra detta, låt oss definiera en index.jsp-fil någonstans på hårddisken. Alla JSP-sidor har en jsp-tillägg. Låt oss öppna den här filen i valfri textredigerare och definiera följande kod i den:

<% String header = "Apache Tomcat"; %>

<%= header %>

I dag<%= new java.util.Date() %>

Använda taggar<% ... %>vi kan definiera Java-kod på en JSP-sida. I det här fallet definierar vi helt enkelt en strängvariabel som kallas header.

Sedan kommer standard html-sidkoden. Taggar används för att bädda in java-kod på en HTML-sida.<%= %>- efter likhetstecknet anges ett Java-uttryck, vars resultat kommer att visas istället för dessa taggar. I detta fall används två sådana insatser. Den första infogningen är värdet på rubrikvariabeln, som definierades ovan. Den andra infogningen är uttrycket new java.util.Date() , som returnerar det aktuella datumet.

För den som är bekant med PHP-webbutveckling kan detta likna att styla php-filer som även innehåller html-kod och php-kod.

Låt oss nu lägga den här filen på servern - i det här fallet i Tomcat-behållaren. Låt oss gå till Apache Tomcat till mappen webapps\ROOT. Låt oss ta bort allt innehåll från den och placera vår index.jsp-sida som skapades ovan.

Låt oss starta Apache Tomcat (om den inte körs) och öppna applikationen på http://localhost:xxxx/index.jsp, där xxxx är portnumret som Tomcat körs på:

Som ett resultat kommer Tomcat att få en förfrågan till sidan index.jsp, bearbeta java-koden, generera en HTML-sida och skicka den till användaren.

Som standard är Apache Tomcat konfigurerad så att alla förfrågningar till applikationsroten hanteras av sidan index.jsp som standard, så vi kan också komma åt den på

Java Server Pages (tm) (JSP)-teknik gör det möjligt för webbapplikationsutvecklare och designers att snabbt utveckla och enkelt underhålla webbsidor med dynamiskt innehåll. Men beskrivningen av nästan varje teknik för detta ändamål (ASP, PHP, Net.Data) åtföljs av liknande ord - snabbt och enkelt...

Även om de är ytligt lika, kännetecknas JSP:er av vissa funktioner som gör denna teknik till något mer än bara ett annat verktyg för att skapa dynamiskt genererat webbsidainnehåll.

Först en enkel uppräkning:

• riktigt hög plattformsoberoende portabilitet; använda det universella högnivåspråket Java som ett skriptspråk;
• JSP är inte något fristående verktyg för att lösa ett ganska snävt utbud av uppgifter, om än ganska kraftfullt, utan ett till i en rad av en hel galax av teknologier kombinerade av Java;
• en verklig möjlighet att separera uppgifterna att skriva affärslogiken för en webbapplikation och användargränssnittet, vilket gör att du kan utveckla och underhålla olika delar av projektet självständigt;

JSP-tekniken är en direkt förlängning av en annan Java-teknik - Servlets (tm) och är också nära besläktad med Java Beans (tm)-teknologin och använder XML-liknande taggar (taggar) och scriptlets (scriptlets) skrivna i Java-programmeringsspråket för att introducera logik skapa dynamiskt innehåll för en webbsida, med HTML- eller XML-taggar som skickas direkt till klientsidan.

Antalet taggar är ganska litet, vilket förenklar den inledande utvecklingen av denna teknik; Men för enkla saker är samma Net.Data eller PHP också mycket enkel. Som vanligt, överväg det primitiva fallet med klassen Hej världen!
<%@ page contentType="text/html; charset=ibm866" %> <%@ page import ="java.net.*" %> <%@ page import ="java.util.Date" %> <% InetAddress localHost = InetAddress.getLocalHost(); Date localTime = new Date(); %>

Vem är jag?

jag kallas<%= localHost.getHostName() %> (<%= localHost.getHostAddress() %>).
Denna sida kördes senast kl<%= localTime.toString() %>.

Även för en person som inte kan Java, kommer förståelsen av ovanstående kod troligen inte att orsaka problem. Låt oss uppehålla oss vid några punkter: koden inuti taggarna<% %>, i själva verket är scriptlet-koden; allt däremellan<%-- --%>-- en kommentar; märka<%= позволяет вывести значение переменной в нужном месте страницы; <%@ page %>låter dig importera klasser och även anpassa en del av sidans beteende.

Om kraften hos sådana konkurrerande (förmodligen, detta är fortfarande fallet ;-) verktyg som PHP och Net.Data främst beror på en enorm uppsättning fördefinierade funktioner, så ligger bakom JSP hela konglomeratet av Java-klasser och -teknologier.

Men med ett så enkelt exempel är det inte alls självklart varför du behöver välja JSP:er och allt relaterat till dem, främst servlets och bönor. Låt oss ändå försöka överväga några av de trevliga aspekterna av JSP.

Sessionshantering

Värden som lagras och hämtas från sessionsobjektet kan inte vara primitiva datatyper (int, double) och måste representeras som deras analoga klasser (Integer, Double).
HttpSession session=request.getSession();//get session object or create one session.getId() //get session ID number Integer item = (Integer) session.getValue("item") // retrieve Integer object session. putValue("ItemValue", itemName);//ItemValue får inte vara primitivt

Applikationshantering

Ibland är det nödvändigt att förse en server med vissa variabelvärden på platsnivå, varje klient använder och manipulerar kopior av denna data. JSP använder ServletContext-objektet, som tillhandahåller en sessionsliknande mekanism (dvs inga primitiva typer).
getServletContext().setAttribute("Item", ItemValue);//för att ställa in en applikationsvariabel Integer i=(Integer)getServletContext().getAttribute("ItemName");//get item färg=blå>

JSP-specifikt språk

JSP-direktiv "säger" servern att göra något när de konverteras från JSP till servlet; direktiv föregås av symbolen @. Några viktiga JSP-direktiv listas nedan, för en mer fullständig bekantskap måste du naturligtvis läsa något annat.
include - inkludering av en statisk eller dynamisk fil (Server Side Include) <%@ include file="hello.jsp" %> import - den resulterande servlet kommer att importera detta paket<%@ import = "java.util.*" %>förlänger - servleten kommer att förlänga (ärva) den angivna klassen (detta är en superklass) <%@ extends = "java.util.Dictionary" %> implements - servleten kommer att implementera gränssnittet <%@ implements = "java.util.Enumeration" %> content_type - ställer in typen av svar som genereras av servleten <%@ content_type = "text/plain" %> eller <%@ content_type = "text/html" %>

Det är känt att uppgifter i denna komplexa värld inte bara är enkla eller till och med väldigt enkla. Om du faller för frestelsen att göra allt med scriptlets (dynamiska insättningar av Java-kod bland statisk HTML) och betraktar externa klasser som ett kraftfullt bibliotek med funktioner, är det mycket lätt att förvandla en dynamisk sida till ett omfattande monster, svårt att felsöka och med stor svårighet i ytterligare modifieringar och tillägg.

Ja, precis som konkurrenter kan komplexiteten utjämnas genom att dela upp en komplex sida i flera logiskt separata delar och sätta ihop dem med hjälp av inkluderingsverktyget.

Det finns två inkluderingsalternativ:

• Statisk inkludering, medan du bearbetar JSP-elementen i den inkluderade filen, om någon, och kommer in i den resulterande genererade Java-koden, faktiskt en serlet:
  <%@ include file="includeheader.jsp"%> eller så
  <%@ include file="includeheader.html"%> det vill säga den medföljande filen behöver inte alls vara en JSP-sida.
• Dynamisk aktivera, medan innehållet i den inkluderade filen bearbetas oberoende, överförs i själva verket kontrollen till den vid tidpunkten för exekvering:
  

Intressant nog kan dynamiskt inkluderat innehåll cachelagras oberoende, vilket i vissa fall ger en betydande vinst på komplexa flerdelade sidor. Men inkluderingsfunktionen är kanske den mest primitiva av JSP:s mångfacetterade funktioner ändå.

Nästan alla som börjar göra en webbapplikation står inför behovet av att förse användaren med ett bekvämt verktyg för att ange information, och här finns det som regel handla om fler problem än att bara tillhandahålla information i form av genererade HTML-sidor. Det är nödvändigt att säkerställa tillräcklig indataintelligens, dessutom, i händelse av inmatningsfel, förlora inte det som tidigare angavs och överför den nödvändiga allmänna informationen från sida till sida. I Net.Data, till exempel, har jag inte hittat ett sätt att göra detta annat än att använda dolda fält i inmatningsformulär, att lagra information med en "session"-livslängd växer till en svår uppgift; hur du kan komma ut med lösningen av detta problem i PHP vet jag inte. När det gäller JSP/servlets finns det ett standardverktyg för JavaBeans (i detta sammanhang kommer vi inte att uppehålla oss vid en så kraftfullare utveckling av detta koncept som EJB) - det här är fullfjädrade Java-klasser med några ytterligare programmeringsregler.

Det här är ett mycket kraftfullt verktyg, men det kräver några brytande stereotyper. JavaBeans är Java-komponenter som kan utföra väldefinierade uppgifter och inkludera dataobjekt. JavaBeans följer en strukturell objektmodell: en Bean har en offentlig konstruktor som inte tar några argument, och dess egenskaper ställs in av den kontrollerande servleten med introspektion/reflektion.

Att inkludera några bönor i en JSP "sida" görs så här:

... Tillägg <%=formHandler.getErrorMsg("description")%> Ägare <%= formHandler.getOwnerName()%> | <%= formHandler.getOwnerName()%> <%=formHandler.getErrorMsg("owner")%> ===> eller här är en annan
jag gillar<%= Cindy.getFlavor() %>kaffe. //The Coffee Bean: Public class Coffee ( private String m_flavor; public Coffee() ( m_flavor = "Regular"; ) public void setFlavor(String flavor) ( m_flavor = flavor; ) public String getFlavor() ( return m_flavor; ) )

Några förklaringar till detta utdrag: scope="request" betyder att bönans livslängd är request, property="*" betyder att denna böna accepterar alla parametrar som skickas i begäran till den här sidan med hjälp av dess metoder. Dessa metoder har en enkel namnregel: om formparametern är lastName, kommer metoden som tar emot data att heta setLastName, och metoden som returnerar data kommer att vara getLastName.

Tyvärr är det svårt nog att visa kraften i att använda bönor i en enkel applikation. Den här artikeln syftar dock inte till att ge hela djupet, uppgiften är att intressera.

Den allmänna linjen som kan spåras i många nya publikationer är åtskillnaden mellan en designers arbete och en programmerares arbete, som tillhandahåller skrivningen av själva arbetet med databasen och affärslogiken i en webbapplikation. Mycket av detta kan föras ner till papperskorgen. Tyvärr verkar komplexiteten i att skriva, åtminstone i det inledande skedet, för JSP-servlets-beans-paketet vara större än för Net.Data och PHP (dock är jag bekant med det senare på en nivå lite mer än " Hej världen!"). Men även användningen av bönor frigör inte helt den minimala användningen av Java på sidan. För att nå det logiska slutet och lämna designern endast den korrekta placeringen av taggar på sidan, introducerade JSP möjligheten att skriva anpassade JSP-taggbibliotek.

Användningen av taggbibliotek gör det för det första möjligt att ytterligare öka kodåteranvändningen, för det andra att minska komplexiteten i att skriva en applikation, och för det tredje att ytterligare hjälpa till med arbetsfördelningen. Tyvärr har det sistnämnda i vår verklighet ännu inte fått vederbörlig vikt vid val av utvecklingsverktyg. Avslutningsvis kommer jag att ge ett litet exempel på hur man använder anpassade taggar, till exempel kan en fråga till databasen med resultatet av resultatet i form av en tabell se ut så här:
<%@ taglib uri="xsql.tld" prefix="xsql" %> ...

något	något	beskrivning
"$1$"	"$2$"	"$3$"

men det betyder inte att det måste se ut så här ;-)

Faktum är att ämnet är för brett för att täckas utan vita fläckar i en så kort presentation.

Som vi såg i föregående artikel tillåter servlets oss att ta emot förfrågningar från klienten, göra en del arbete och visa resultaten på skärmen. Fram till den punkt där du behöver visa utdata på skärmen fungerar servleten bra. Du kan infoga ganska komplex logik i den, göra anrop till databasen och mycket, mycket mer som är nödvändigt för applikationen. Men det är väldigt obekvämt att visa utdata på skärmen inuti själva servleten. I vårt exempel begränsade vi oss till en extremt enkel lösning. Och vad måste göras om komplexa designidéer dras tillbaka? Det är osannolikt att en webbdesigner kommer att kunna förstå hur man renderar i vår servlet. Och när han vill implementera sina designidéer måste han komma till programmeraren och be honom ändra servletkoden för att ändra designen. Det kommer att behöva kompileras om, det kommer att vara nödvändigt att komma med smarta algoritmer för att visa inte bara bilder utan också samma JavaScript. Bara en mardröm.
Det är uppenbart för varje förnuftig utvecklare att en annan lösning måste användas. Det mest uppenbara är att komma på en mekanism som skulle dela upp uppgiften i två komponenter: en del bearbetar förfrågan, ändrar data, samlar in data, lägger den i ett paket och skickar den till den andra delen, som bara gör det. en sak - visar dessa data.
Så vi kom till mönstret vi redan känner - Model-View-Controller (MVC). När det gäller webbapplikationer blir servleten kontrollant, datapaketet som vi bildade blir modellen. Men rollen för vyn (View) är perfekt för JSP - Java Server Pages.
I den här artikeln kommer vi att göra en allmän översikt över denna teknik. Och vi kommer att fortsätta med "HR-avdelningen" i nästa artikel, där vi omedelbart kan använda bekanta teknologier - servlets och JSP.
Huvudidén med JSP är väldigt enkel - själva sidan är en mall med redan förberedda HTML-taggar, mellan vilka du måste infoga nödvändiga data. Något liknande detta (det här är bara ett diagram)

<% String name = request.getParameter("name"); if (name == null || name.length() == 0) { %>Hej världen!<% } else { %>Hej världen! Jag är<%= name%> <% } %>

< html > < head > < title > hej världen prov < / title > < / head > < body > < h1 > Strängnamn = begäran. getParameter("namn"); if (namn == null || namn . längd () == 0 ) ( Hej världen! <% } else { Hej världen! Jag är<%= name %> < / h1 > < / body > < / html >

Som du kan se är vår HTML-fil en blandning av HTML-taggar och Java-kod. Faktum är att JSP:n konverteras till en servlet första gången den öppnas och fungerar som en servlet. Detta är mycket viktigt att förstå. En JSP är INTE en sida som en HTML-sida - det är viktigt för en nybörjare som programmerar att vara tydlig med att det bara är en annan servlet - det är bara det att dess utdata inte behöver programmeras. Du kan bara rita den. Och placera data på rätt ställen. Men eftersom Om en JSP-sida på något sätt liknar HTML blir det självklart lättare för en designer. Och än en gång säger jag STARKT till nybörjare - JSP är en SERVLET. Dess förberedelse med all data sker på servern. Det är här all data går. Och användaren får en färdig HTML-sida i webbläsaren, där det inte finns några tecken på JAVA. Om inte någon form av applet - men det här är en helt annan teknik. Det är bara att JSP är bekväm att använda - du gör logiken för att ta emot data i en servlet (som inte ser ut som en JSP) och skickar sedan data till en annan servlet (denna gång i form av en JSP), vars uppgift är för att rita en HTML-sida med dessa data. Det krävs bara inte mycket för att rita. Dessutom behöver du inte kompilera om JSP-klasserna. Du kan helt enkelt byta ut JSP:n med en modernare så kommer den automatiskt att kompileras om. Vilket i allmänhet är ganska bekvämt - de kopierade helt enkelt den önskade sidan till platsen för den gamla. Som du kan se är Java-koden omgiven av vinkelparenteser med ett procenttecken "<%» и здесь вам можно написать любой код, который будет нужен.
Som du kan se kontrollerar vår kod förekomsten av namnparametern i begäran (request.getParameter("namn")), och om den finns visas en inskription. Annars kommer vi att se en "förkortad" version av inskriptionen.
Lite mer information - JSP har flera fördefinierade objekt. De där. de ska uppfattas som färdiga föremål som kan användas. De är begäran, svar, ut, session, applikation, config, pageContext och page. Jag ska ge en kort referens till dem, det är möjligt att det inte blir särskilt intressant för tillfället, och det är inte heller klart. Men för säkerhets skull.

begäran
Det här är HttpServletRequest-objektet som är associerat med förfrågan som låter dig komma åt förfrågningsparametrarna (via getParameter-metoden), förfrågningstypen (GET, POST, HEAD, etc.) och de inkommande HTTP-huvudena (cookies, Referer, etc.). d.). Mer specifikt är request en underklass till ServletRequest och kan skilja sig från HttpServletRequest om ett annat protokoll än HTTP används, vilket nästan aldrig är fallet i praktiken. Därför kan du se det som en HttpServletRequest.

svar
Detta är ett objekt av typen HttpServletResponse associerat med ett svar på en klientförfrågan. Observera att eftersom utdataströmmen (se nedan) är buffrad, är det möjligt att ändra HTTP-statuskoder och svarsrubriker, även om detta inte är tillåtet i en normal servlet, utan endast om någon utdata redan har skickats till klienten.

ut
Detta är ett objekt av typen PrintWriter som används för att skicka utdata till klienten. Men för att göra responsobjektet (se föregående avsnitt) användbart bör du använda den buffrade versionen av PrintWriter, JspWriter. Kom ihåg att du kan ändra storleken på bufferten och till och med inaktivera buffring genom att ändra värdet på siddirektivets buffertattribut. Notera också att out används nästan uteslutande av scriptlets, eftersom JSP-uttryck automatiskt placeras på utdataströmmen, vilket eliminerar behovet av att explicit anropa.

session
Detta är HttpSession-objektet som är kopplat till begäran. Sessioner skapas automatiskt och denna variabel finns även om det inte finns några referenser till inkommande sessioner. Det enda undantaget är när du inaktiverar användningen av sessioner med hjälp av sessionsattributet i siddirektivet. I det här fallet leder referenser till sessionsvariabeln till fel när JSP-sidan översätts till en servlet.

Ansökan
Detta är ett objekt av typen ServletContext som erhålls genom att använda metoden getServletConfig().getContext().

config
Detta är ett objekt av typen ServletConfig för den aktuella sidan.

sidaKontext
JSP introducerar en ny PageContext-klass för sandlådeserverspecifika funktioner som mer effektiva JspWriters. Tanken är att om du kommer åt dem via den här klassen istället för direkt, kan din kod köras på "vanliga" servlet/JSP-motorer.

sida
I huvudsak en synonym för detta, och behövs inte när man arbetar med Java. Denna variabel skapades med förväntningen att andra skriptspråk än Java kan dyka upp.

Låt oss ta en titt på vår skapelse i aktion. Du kan kompilera vår servlet med kommandot

javac -cp .;servlet-api.jar students\web\*.java

Efter det kommer vi att placera vår HelloWorldServlet-klass i katalogen \webapps\studentsApp\WEB-INF\students\web\. Och hello.jsp-filen i rotkatalogen för vår applikation - \webapps\studentsApp.
Nu är vårt katalogträd något enklare (vi använder inte vissa klasser)

WEB-INF klasser studenter webb -HelloWorldServlet.class -web.xml -hello.jsp

< strong >WEB-INF klasser studenter helloworldservlet. klass webb. xml Hallå. jsp< / strong >

Den redan kända web.xml-filen kommer att se exakt likadan ut som i föregående del

Hallå Hallå /Hallå

< ! DOCTYPE web - app PUBLIC "-//Sun Microsystems, Inc.//DTD Webbapplikation 2.3//SV" "http://java.sun.com/dtd/web-app_2_3.dtd"> < web - app > < servlet > < servlet - name >Hallå< / servlet - name > < servlet - class >studenter. webb. helloworldservlet< / servlet - class > < / servlet > < servlet - mapping > < servlet - name >Hallå< / servlet - name > < url - pattern >/Hallå< / url - pattern > < / servlet - mapping > < / web - app >

Vi startar Tomcat och försöker sedan anropa vår ansökan via URL
http://localhost:8080/studentsApp/hej

Om du vill se mitt namn använd denna URL
http://localhost:8080/studentsApp/hello?name=Anton
Du kan byta ut ditt namn senare 🙂

anpassad tagg

Nu kan vi dyka lite djupare in i JSP. Som du kanske har märkt är JSP en blandning av Java-kod och HTML-taggar. Med ökningen av komplexiteten i presentationslogiken (och JSP används just som en presentation - men även en presentation kan ha ganska sofistikerad logik - färger, typsnitt etc.), förvandlas sidan från mer eller mindre begriplig HTML till "flotta". -pasta”. Och designern kommer inte längre att kunna förstå någonting. Troligtvis kommer det inte att vara möjligt att helt bli av med logiken i JSP, men på något sätt "kombinera" koden och använd mer bekväma medel - en sådan lösning finns. Och det kallas CustomTags. I själva verket är detta en förenkling av JSP-konstruktionerna som jag ville uppnå.

Låt oss titta på ett enkelt exempel på hur du kan skriva och använda din egen anpassade tagg. För att göra detta behöver vi tre steg:

1. Skriv en TLD-fil (Tag Library Definition) - en taggbiblioteksbeskrivningsfil.
2. Skriv en klass för att implementera själva taggen
3. Fixa HTML-fil

Så. TLD-filen har filtillägget .tld och distribueras vanligtvis i en WEB-INF-katalog i din applikationskatalog. Även om den kan placeras i en annan. Om du har många sådana filer kan du tillhandahålla en separat katalog för dem. Här är vår version av hello.tld.

1.0 1.2 Exempel på taggbibliotek /SimpleTagLibrary Exempel på tagg för HelloWorld Hallå students.web.tag.HelloTag tömma hello world tag exempel namn falsk Sann

< taglib xmlns = "http://java.sun.com/xml/ns/j2ee" xmlns :xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi : schemaLocation= "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd" version="2.0"> < tlib - version > 1.0 < / tlib - version > < jsp - version > 1.2 < / jsp - version > < short - name >Exempel på taggbibliotek< / short - name > < uri >/SimpleTagLibrary< / uri > < description > Exempel på tagg för HelloWorld < / description > < tag > < name >Hallå< / name > < tag - class >studenter. webb. tagga . hellotag< / tag - class > < body - content >tömma< / body - content > < description > hello world tag exempel < / description > < attribute > < name >namn< / name > < required >falsk< / required > < rtexprvalue >Sann< / rtexprvalue > < / attribute > < / tag > < / taglib >

Som du säkert märkte från beskrivningen är taggen HelloTag-klassen. Det är han som är ansvarig för att visa information. Låt oss skriva det.

paket students.web.tag; importera java.io.IOException; importera javax.servlet.jsp.JspException; importera javax.servlet.jsp.JspTagException; importera javax.servlet.jsp.tagext.TagSupport; public final class HelloTag utökar TagSupport ( privat String name = null; public int doStartTag() kastar JspException ( try ( if (name == null) ( pageContext.getOut().write("Hej, värld!"); ) else ( pageContext.getOut().write("Hej världen! Jag är " + namn); ) ) catch (IOException ioe) ( kasta ny JspTagException(ioe.getMessage()); ) returnera SKIP_BODY; ) public String getName() ( return name; ) public void setName(String name) ( this.name = name; ) public void release() ( super.release(); name = null; ) )

paketelever. webb. tag ; importera java. io. IOException ; importera javax. server. jsp. jspException ; importera javax. server. jsp. JspTagException ; importera javax. server. jsp. text . TagSupport ; offentlig slutklass HelloTag utökar TagSupport( privat strängnamn = null; public int doStartTag() kastar JspException( Prova( if (namn == null ) ( sidaKontext. gå ut(). skriv ("Hej, värld!" ); ) annat ( sidaKontext. gå ut(). skriv ("Hej världen! Jag är " + namn ); ) catch (IOException ioe ) ( kasta nytt JspTagException (ioe . getMessage () ); returnera SKIP_BODY ; public String getName()( returnera namn ; public void setName (String name ) ( detta. namn = namn; public void release()( super . släpp(); namn= null; } }

För att bygga vår servlet och en ny tagg behöver vi en mer komplex linje

javac -cp .;servlet-api.jar;jsp-api.jar students\web\*.java students\web\tag\*.java

Det nya jsp-api.jar-biblioteket kan tas på samma plats som servlet_api.jar - i \vanlig\lib. Nu, för att koppla vår tagg till applikationen, måste vi registrera vårt bibliotek i web.xml-filen

Välkommen till Studentpersonal Välkommen till Studentpersonal Hallå students.web.HelloWorldServlet Hallå /Hallå http://www.someurl.ru /WEB-INF/hello.tld

xmlversion= "1.0" kodning= "ISO-8859-1"?> < webb- app> < visa- namn> VälkommentillStudenterpersonal< / visa- namn>