Kapittel 25 (Big Java 1.utg) Java Server Pages og Servlets

Oversikt Når ein weblesar ber om ei html-side frå ein webserver, vil serveren finne korrekt fil og returnere denne Statisk innhold – det same blir returnert kvar gong, heilt til den aktuelle sida blir erstatta med ei ny Websider med dynamisk innhold er ofte meir interessant Innholdet er avhengig av kven som spør, og av input frå den som spør Vi skal sjå på korleis vi kan lage dynamiske websider ved hjelp av Java Server Pages (JSP) og servlets

JSP For å bruke JSP treng vi ein webserver som er integrert med ein JSP Container Dette er innebygd i NetBeans Vi bruker eksemplet med tid og dato frå kap. 25 i Big Java, og starter med ei svært enkel JSP-side som viser tidspunkt Vi lagar web-applikasjon i NetBeans JSP-sida er nesten som ei vanleg html-side, bortsett frå instruksjonen Denne instruksjonen blir eksekvert kvar gong sida blir sendt til ein weblesar, og verdien av uttrykket blir sett inn. På denne måten blir korrekt tid vist

JSP For å deploye (ta i bruk?) sida bruker vi F6 (run main project) i NetBeans Instruksjonane i punkt 1-5 på side 1005 blir automatisk utført av NetBeans Kjekt for oss, men vi mister litt kontroll med strukturen og kva som foregår JSP-sida blir lagt på rett plass i katalogstrukturen Web-serveren starter Ein weblesar peikar på rett adresse for å lese JSP-sida JSP-containeren les JSP-sida og lagar ei html-side av denne Vanlege html-tags blir ikkje endra JSP tags på formen blir berekna og konvertert til tekst, som blir sett inn Det blir gjort tilsvarande med andre typer JSP tags

JavaBeans Vi kan dytte inn masse java-kode i ei JSP-side, og på den måten få ei blanding av html-kode som styrer korleis innholdet skal presenterast, og programlogikk som finn ut kva innholdet skal vere Dette bør vi unngå! Vi treng input frå to ekspertar, ein webdesigner og ein programmerar Webdesigneren kan mykje om korleis vi kan presentere ting på web Programmeraren kan mykje om korleis vi skal skaffe fram resultata som skal visast Om vi samlar alt i ei stor JSP-side, vil begge få problem med å gjere det dei er flinke til Vi bør skille presentasjon og programlogikk

JavaBeans Vi bør utføre alle berekningar, utover det heilt trivielle, i eigne Java-klasser Vi kan lage ein eller fleire JavaBeans i tilknytning til JSP-sida I prinsippet kan alle omtrent alle Java-klasser vere JavaBeans Men: Klassen må ha ein public konstruktør som ikkje tar argument Ein JavaBean skal vere ein klasse som viser eigenskaper (properties) Navnekonvensjoner

JavaBeans Vi går gjennom eksemplet med formattert tid i NetBeans Pass på å vere nøyaktig! Små syntaksfeil kan føre til feilmeldingar det ikkje alltid er like enkelt å forstå Sjølv om dette er eit enkelt og lite eksempel, illustrere det korleis vi kan splitte presentasjon og java-kode I større prosjekt er dette svært viktig for å holde orden på ting Lottery-eksemplet viser at det ikkje alltid er like lett å få til eit fullstendig skille mellom berekningar og presentasjon Mogleg løysing: to JavaBeans, ein “computational” og ein “formatting”

Request parameter Neste steg mot ein meir fullstendig web-applikasjon er å få input frå brukaren Vi gjer ei enkel utviding av FormattedTime- programmet, der vi får brukaren til å skrive inn namnet på ein by Vi sjekkar tidssona til denne byen, og finn på den måten tida der brukaren er, ikkje der serveren er Vi treng eit html-skjema med tekstfelt og trykknapp, og vi må få tak i det brukaren har skrive (pluss at vi må registrere knappetrykket)

Request parameter Vi bruker klassen TimeZone frå java- biblioteket Statisk metode getAvailableIDs() returnerer eit String -array Vi sjekkar bynavn frå input mot bynavna i dette arrayet Ved match finn vi rett tidssone, og vi kan returnere lokal tid til brukaren Vi lagar ein JavaBean som tar seg av dette

Request parameter I html-skjemaet må vi gi URL’en til programmet som skal ta imot input frå brukaren (action-attributten) JSP-sida får tak i input ved å kalle getParameter() -metoden hos request - objektet med namnet på inputfeltet som argument Parameterverdien blir sendt vidare til bønna som skal finne rett tidssone Vi lagar web-applikasjon nr. 3...

html skjema Vi har sett eit enkelt html-skjema med tekstboks og trykknapp Andre element: Passordfelt – tekst som brukaren skriv inn blir vist som * eller liknande Tekstområde – for å ta inn meir enn ei linje med tekst Radio buttons – når brukaren må velge eit element av fleire Check boxes – når brukaren kan velge fritt mellom element (ingen, eit eller fleire) Selection lists – tilsvarer comboboks Skjulte felt – kan brukast for å holde styr på sesjoner Vi bør bruke andre teknikkar til dette Alle felt blir plassert inne i skjemaet form -tag action -attributt gir URL til JSP’en som skal behandle data method -attributt bør vere POST, sidan GET har avgrensa lengde

Sesjoner I mange tilfelle har vi bruk for å ta vare på informasjon gjennom ein sesjon – ein serie med requests frå ein weblesar til ein webserver Handlekorg – når du legg til ei ny vare i handlekorga, veit programmet kva du har lagt til frå før I JSP er dette enkelt, vi legg attributten scope=“session” til bønna Vi får ei Java-bønne som bruker det same objektet så lenge henvendelsane kjem frå den same weblesaren Kvar ny brukar fører til at eit nytt objekt blir oppretta Så langt har vi hatt page scope, der eit nytt objekt blir oppretta for kvar ny henvendelse (request)

Sesjoner Vi gjer ei ny lita endring av programmet som viser tid Brukaren kan legge til fleire byar, og få vist ei liste av byar og deira lokaltid For å ta vare på informasjon om det brukaren tidlegare har spurt om, bruker vi session kontroll Web-applikasjon nr. 4 i NetBeans

Fordeling av oppgåver I kap 25.6 blir det forklart korleis vi kan fordele oppgåve på ulike JSP-sider Basert på input er det aktuelt å vise ulike sider Ei side dersom brukaren skriv inn ein by der vi finn tidssone Ei anna side om vi ikkje finn tidssone scope=“request” rundt Java-kode JSP-sida med forward -direktivet blir ikkje vist Dei aktuelle JSP-sidene har tilgang til requesten og bønna på grunn av scope -attributten Test på isAvailable()- metoden i bønna

Kap lags applikasjon Dette er sjølvstudium, vi går raskt gjennom hovudinnholdet I klartekst: du kan få spørsmål om dette på eksamen! Applikasjonen er delt i 3 lag: Presentasjonslag: Weblesaren Forretningslogikk: JSP og Java-bønner Datalagring: Database Viktig forskjell frå 2-lags modell Bruk av xml for å lagre konfigurasjonsparameter JSP-tags for å få tak i desse Eigen klasse for å styre databasekobling

Servlets Java servlets er alternativ til JSP og JavaBeans Servlets skiller ikkje så tydeleg mellom presentasjon og berekningar/Javakode Det blir anbefalt å bruke hovudsakleg JSP som teknologi for å lage web-grenesnitt Når bør vi bruke servlets: Når resultatet av henvendelsen ikkje er html, f eks binære data som eit bilde eller ei fil for nedlasting Dessutan: JSP-sider blir til servlets ved kompilering, så det kan vere lurt å vite litt om servlets

Servlets Bruk av instansvariable og statiske metoder i servlets Servlet-containeren oppretter kun eit servlet-objekt Om fleire henvendelser kjem samtidig blir dei kjørt samtidig i kvar sin tråd Alle vil dele same objekt, og dermed eventuelle instansvariable Instansvariable kan dermed berre brukast for informasjon som er felles for alle henvendelsane Ved å bruke statiske metoder unngår vi problem Lokale variable (inne i metodene) er OK, sidan kvar tråd har sin eigen kopi av metoden, og dermed eventuelle lokale variable

Servlets JSP – sider blir kompilert til servlets Ved første request Ved request etter endring jsp –direktiv og tags blir gjort om til Java- kode Vi gir oss her med web-applikasjoner Stoffet dukkar opp igjen med full tyngde i seinare kurs