1. Tilstandsinformasjon på klientsiden

Transkript

1 Stiftelsen TISIP i samarbeid med Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Tomas Holt Opphavsrett: Tomas Holt og Stiftelsen TISIP Lærestoffet er utviklet for faget LV192D Web-programmering i ASP 1. Resymé: Denne leksjonen tar for seg ulike måter å ta vare på valgene brukeren har gjort. Ulike løsninger kan være cookies, gjemte felt osv. Inkludering av filer er tema tilslutt. Innhold 1. TILSTANDSINFORMASJON PÅ KLIENTSIDEN OM DENNE LEKSJONEN TILSTANDSINFORMASJON Kreativ bruk av URL Omskriving av URL Cookies Flere verdier i en cookie Enkel bokhandel som bruker cookies Gjemte felt (hidden fields) Frivillig oppgave om gjemte felt Typiske bruksområder for cookies Fakta om cookies Fakta om gjemte felt Fakta om omskriving av URL INKLUDERING AV FILER Tidlig inkludering Sen utførelse Variabler og funksjoner definert i ulike filer Unødig inkludering Konklusjon LØSNING FRIVILLIG OPPGAVE Om denne leksjonen I forrige leksjon så vi på hvordan vi kunne ta i mot informasjon fra klienten, hvordan vi kunne prosessere denne informasjonen og hvordan sende svar tilbake. Vi skal i denne leksjonen konsentrere oss om hvordan vi kan ta vare på informasjon, mellom to ulike forespørsler fra klienten. Det kan være situasjoner der vi vil vite hvilket valg brukeren har gjort før. Leksjonen går i hovedsak igjennom første del av kap.11 (s s.339), siste del av kap.10 (s ) og første del av kap. 13 (s ).

2 1.2. Tilstandsinformasjon HTTP er en tilstandsløs protokoll. Det betyr at tjeneren ikke husker at klienten har gjort tidligere forespørsler. Dette var greit så lenge web var beregnet på statisk informasjon. Interaktivitet førte imidlertid med seg behovet for også å kunne ta vare på tilstandsinformasjon. Vi har i hovedsak fire måter å sørge for å ta vare på tilstandsinformasjon. Dette er: Omskrivning av URL Gjemte felt (hidden fields) Cookies Tjenersidelagring Disse blir forklart i denne og neste leksjon Kreativ bruk av URL La oss tenke oss at vi skal lage en hjemmeside der du skal selv kunne velge fargen på bakgrunnen. Det er en meget enkel løsning på dette problemet. Vi lager en ASP som returnerer en web-side med lenker som angir fargen på bakgrunnen. Når vi trykker på lenken vil bakgrunnsfargen skifte til den ønskede fargen. (Vi kan selvsagt også lage tre ulike websider med ulik bakgrunn, men vår løsning er litt mer elegant). Figur 1:Valgfri bakgrunnsfarge Koden under viser hvordan vi ved hjelp av en URL kan spesifisere hvilken bakgrunn vi vil ha. Legg merke til at URL ene refererer til vår ASP, men med ulike parametre (fet skrift). Hvis vi trykker på lenken rød vil URL en bli ASP en vår sjekker hvilken farge som er med som paramter i URL en (hvit, rød eller grønn) og setter bakgrunnsfargen på grunnlag av denne parameteren (fet skrift). <% ' kreativurl.asp ' %> <% Dim strfarge, strbakgrunnsfarge strbakgrunnsfarge= "green" side 2 av 22

3 strfarge = Request("farge") ' henter fargen som er med som parameter ' sjekker så hvilken farge som er valgt If strfarge = "white" Then strbakgrunnsfarge="white" Elseif strfarge = "red" then strbakgrunnsfarge="red" Elseif strfarge = "green" then strbakgrunnsfarge="green" End If %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <BODY BGCOLOR="<%= strbakgrunnsfarge %>"> <H1> Du får den fargen du vil </H1> <A HREF=kreativURL.asp?farge=white> HVIT </A> <BR> <A HREF=kreativURL.asp?farge=red> RØD </A> <BR> <A HREF=kreativURL.asp?farge=green> GRØNN </A> <BR> Omskriving av URL Nå skal vi gå et steg videre. Vi skal nå lage en ASP som skifter farge på bakgrunnen til en web-side. Fargene som det skal skiftes mellom er rød og grønn. Vi skal imidlertid ikke bruke to lenker, men vi skal bruke en URL som inneholder hvilken farge bakgrunnen har nå (denne må omskrives hver gang fargen skifter). På grunnlag av dette vil vi kunne skifte farge når lenken trykkes på nytt. Dvs. hver gang lenken trykkes så skal bakgrunnsfargen skifte. Under vises web-siden og ASP-koden. Figur 2: Omskriving URL side 3 av 22

4 <%' omskrivingurl.asp ' %> <% Dim strbakgrunnsfarge, strfarge strfarge = Request("farge") %> If strfarge = "green" Then strbakgrunnsfarge="red" Elseif strfarge = "red" Then strbakgrunnsfarge="green" Else strbakgrunnsfarge="green" End If <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <HEAD></HEAD> <BODY BGCOLOR="<%=strBakgrunnsFarge%>"> <H1> Du får den fargen du vil </H1> <A HREF=omskrivingURL.asp?farge=<%=strBakgrunnsFarge%> > SKIFT BAKGRUNNSFARGE </A> <BR> Legg merke til den fete skriften i koden over. Vi sørger for at URL en som sendes tilbake til klienten hele tiden inneholder hvilken bakgrunnsfarge klienten har. Dette gjør at når klienten sender en ny forespørsel så vet tjeneren hvilken bakgrunnsfarge klienten har fordi denne er med som en parameter i URL en. Problemet med metoden beskrevet over er at når du lukker nettleseren og kobler opp på nytt så vil du bestandig få grønn bakgrunnsfarge. Dette skjer hver gang det ikke er spesifisert hvilken farge du vil ha med?farge=xxx i URL en. Hvis du kommer inn på denne siden via en lenke fra en annen side er det ikke mulig å vite hva slags bakgrunnsfarge du valgte forrige gang (du kan selvsagt skrive inn URL en i adressefeltet på nettleseren selv med den fargen du vil ha, men dette er litt tungvindt for folk flest). Vi skulle gjerne hatt en metode som kunne huske hvilken farge vi valgte sist slik at yndlingsfargen kom opp også neste gang vi besøkte web-siden (slik at vi slipper å konfigurere web-siden hver gang vi går inn på den). I vårt simple eksempel betyr ikke dette så mye, men hvis vi snakker om mer avanserte web-sider med mange konfigurasjonsmuligheter vil det være veldig irritabelt å måtte gjøre konfigurering hver gang vi besøker en web-siden. Det er en løsning på dette problemet, nemlig cookies Cookies Vi skal nå lage en løsning som husker tilstanden også mellom besøk på web-siden. Cookies er en måte å få til dette på. En cookie er en liten datafil som nettleseren får fra tjeneren og lagrer på klientmaskinen. Hver gang en forespørsel til en tjener gjøres vil nettleseren sjekke om det finnes en cookie som stammer fra denne tjeneren. Hvis så er tilfelle så vil cookie en sendes med til tjeneren. Innholdet i cookie en er vanlig tekst. Ettersom tjeneren selv kan sette side 4 av 22

5 innholdet i cookie en så kan tjeneren sørge for å lagre tilstandsinformasjon i denne. Slike cookies kan også lagre tilstander etter at nettleseren er lukket. Vi kan dermed ta vare på tilstander over lengre tid (månder, år) med cookies. Koden under sørger for at tilstanden fra forrige gang huskes. For å gjøre eksemplet enklest mulig er det laget slik at fargen på bakgrunnen skifter hver gang du besøker web-siden (også etter du har lukket nettleseren og kobler opp på nytt). Vær klar over at for at koden under skal fungere så må nettleseren være konfigurert til å ta i mot cookie er. For mer forklaring på hvordan dette gjøres se kap <% 'cookiefarge.asp %> <% Dim strcookiefarge, strbakgrunnsfarge strcookiefarge = Request.Cookies("bakgrunnsfarge") %> <% %> If strcookiefarge = "red" Then strbakgrunnsfarge="green" setcookie("green") Elseif strcookiefarge = "green" Then strbakgrunnsfarge="red" setcookie("red") Else strbakgrunnsfarge="green" setcookie("green") End If Function setcookie(farge) Response.Cookies("bakgrunnsFarge") = farge Response.Cookies("bakgrunnsFarge").Expires = Date + 7 ' Cookie n varer 7 dager fra dags dato ' settes ikke denne verdien slettes cookie n når nettleseren lukkes. End Function <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <BODY BGCOLOR="<%=strBakgrunnsFarge%>"> <H1> Du får den fargen du vil </H1> <A HREF=cookieFarge.asp> SKIFT BAKGRUNNSFARGE </A> <BR> I koden over er det to områder uthevet med fet skrift. Se på koden Response.Cookies("bakgrunnsFarge") = farge. side 5 av 22

6 Det som skjer her er at vi lager en cookie med navn bakgrunnsfarge og verdi lik strengen farge. Vi spesifiserer så hvor lenge denne cookien skal være gyldig i dager med Response.Cookies("bakgrunnsFarge").Expires = Date + 7. Vi går ut fra dagens dato (med Date) og legger på 7 dager ekstra. Etter dette vil den ikke brukes av nettleseren. Hvis ingen verdi oppgis vil cookie en slettes når nettleseren lukkes. Det andre området uthvet med fet skrift (lenger oppe i koden) sørger for å ta i mot cookie er fra nettleseren. Variablen cookiefarge får verdien som cookie n bakgrunnsfarge inneholder. (Request.Cookie er en samling av cookie er. Dette temaet ble gjennomgått i leksjon 4). På klientmaskinen har jeg etter å kjøre eksempelet over fått en cookie som er slik: bakgrunnsfarge red localhost/ * Vi ser at første linje er navnet på cookie en. Linje nummer to inneholder verdien som er red. Linje nummer 3 viser hvor cookie en er laget (host). Nettleseren vil kun sende cookie en tilbake til programmer som ligger på localhost/kurs/lek5 eller kataloger som ligger under lek5. Dvs. at ASP en localhost/kurs/test.asp ikke vil få tilgang til cookie en som vi har laget, men derimot så vil ASP en localhost/kurs/lek5/underkatalog/endaenunderkatalog/test.asp få tilgang til denne cookie en. Hvor denne cookie en blir lagret på maskinen er avhengig av nettleseren og operativsystem. Hos meg på Windows XP og med Internet Explorer 6 finnes cookie en over på C:\Documents and Settings\tomash\Cookies og heter tomash@localhost[1].txt. Dette er altså brukernavnet mitt og tjeneren cookie en er sendt fra. Nettleserene har som regel muligheten til å vise fram lagrede cookies. I Internet Explorer 6 velger du Verktøy > Alternativer for Internett > Instillinger > Vis filer. Du kan da se alle cookies som ligger lagret av IE (dette er tekstfiler så du kan lese innholdet). For Opera velger du Fil > Instillinger > Personvern > Rediger tjenerfiler. NB! Vær forsiktig med å bruke disse tegnene i både navn og verdi i en cookie: hvit tegn (whitespace), samt []()=,/?@:;. Dette kan gi problemer med eldre nettlesere. side 6 av 22

7 Flere verdier i en cookie Hvis en vil ha flere verdier i en cookie kan dette enkelt gjøres ved å bruke en nøkkelverdi. La oss si at vi lager en cookie. Vi vil at denne skal ta vare både på tittelen på en bok og forfatteren. Vi kunne selvsagt laget to cookie er for dette men vi velger en mer elegant måte. Vi bestemmer oss for å kalle cookie en bokkjøp. Koden kan være slik: <% Response.Cookies( bokkjøp )( bok ) = ASP Response.Cookies( bokkjøp )( forfatter )= Gnatt %> I koden over er bok og forfatter nøkkelverdier til cookie en bokkjøp. Disse settes til å ha verdiene ASP og Gnatt her. Å få tak i verdiene i en cookie med flere verdier er også enkelt. La oss lage kode for å få tak i verdiene i cookie en vi laget over: <% Dim bok, forfatter bok = Request.Cookies( bokkjøp )( bok ) forfatter = Request.Cookies( bokkjøp )( forfatter ) %> Både navnet på cookie en og nøkkelverdiene er som du kan se de samme som vi definerte over. Mye enklere kan det vel ikke gjøres? Enkel bokhandel som bruker cookies Tenk bare på når du bestiller en bok på nett. La oss tenke oss at du krysser av for en bok. HTML-skjemaet sendes til tjeneren. Denne returnerer et nytt skjema der du må skrive inn navn, adresse og epost, for at boka skal kunne sendes til deg. Dette høres fint ut. Det er imidlertid et problem. Tjeneren husker ikke din forrige forespørsel. Dvs. det er ingen måte å koble sammen forespørsel nummer 1 (bestillingen av boken) med forespørsel nummer 2 (der du oppgir navn og adresse). Dette gjør at tjeneren vet at en bok er bestilt, og vet at du har bestilt en bok, men vet ikke at du har bestilt akkurat den boka. Så lenge kun en person bestiller bok vil dette selvsagt fungere. Når to eller flere bestiller bok vil tjeneren ha mange bøker som er solgt, og mange kjøpere, men har ikke mulighet til å koble bøker mot kjøpere. Cookies er løsningen. La oss tenke oss at du bestiller boka The Shadow Rising av Robert Jordan. Dette gjør du på HTML-siden bok.html. Når denne fylt ut denne siden får du returnert ASP-siden betal.asp, der du må skrive inn nødvendig personalia. Tilslutt får du tilbake web-siden resultat.asp, der opplysningene du har skrevet inn vises for deg. side 7 av 22

8 De neste underkapittelene vil gå igjennom hver av delene beskrevet over. Jeg gjør oppmerksom på at dette eksemplet er gjort så enkelt som mulig for å gi best mulig oversikt. Det egner seg derfor ikke som en kommersiell bokhandel. Overordnet skisse av løsningen Figuren under viser hvordan cookies brukes til å ta vare på informasjon mellom forespørsler i bokkjøpet. Figur 3: Overordnet skisse av løsning med cookies Bok.html Dette er en helt vanlig HTML-fil med HTML-skjema. Denne sender informasjon brukeren taster inn til betal.jsp (se neste kap.). side 8 av 22

9 Figur 4: bok.html side 9 av 22

10 <HEAD></HEAD> <BODY> <H1> Online bokkjøp dot.no </H1> <H2> Velg en bok: </H2> <TABLE CELLPADDING=10> <TH> Bok <TH> Bestill <FORM ACTION="betal.asp" METHOD="POST"> <TR> <TD> The Shadow Rising av Robert Jordan <TD> <INPUT TYPE="radio" NAME="bok" VALUE="The shadow rising"> <TR> <TD> Ringenes herre av J.R.R Tolkien <TD> <INPUT TYPE="radio" NAME="bok" VALUE="Ringenes herre"> <TR> <TD>Beatles av Lars Saabye <TD><INPUT TYPE="radio" NAME="bok" VALUE="Beatles"> <TR> <TD> Hottentottene av Tomas the Man <TD> <INPUT TYPE="radio" NAME="bok" VALUE="The shadow rising"> <TR> <TD> Sikre investments av Laura <TD> <INPUT TYPE="radio" NAME="bok" VALUE="Sikre investments"> <TR> <TD> <TD> <INPUT TYPE="SUBMIT" VALUE="Send"> </FORM> </TABLE> Betal.asp Denne tar imot informasjonen fra bok.html. Informasjonen om boken legges i en cookie som sendes tilbake til klienten, sammen med et HTML-skjema for å taste inn navn, adresse og epost-adresse. Legg merke til hvordan bok legges i cookie en med koden Response.Cookies ( bok ) = bok side 10 av 22

11 Figur 5: betal.asp <%' betal.asp ' %> <% Option Explicit Dim bok henter ut verdien til boken som ble valgt i bok.html bok = Request("bok") %> Response.Cookies ("bok")= bok ' Cookien varer kun til nettleseren lukkes' <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <HEAD></HEAD> <BODY> <H1> Betalingsinformasjon </H1> <P> Du har krysset av for boka: <%=bok%> <P> For å få denne boka tilsendt må du oppgi navn, adresse og epost. Boka blir så sendt i postoppkrav til deg. <TABLE> <FORM ACTION="resultat.asp" METHOD="POST"> <TR><TD> Navn: <TD> <INPUT TYPE="TEXT" NAME="navn"> <TR><TD> Adresse: <TD> <INPUT TYPE="TEXT" NAME="adresse"> <TR><TD> Epost: <TD> <INPUT TYPE="TEXT" NAME="epost"> <TR><TD> <TD> <INPUT TYPE="SUBMIT" VALUE="Send"> </FORM> </TABLE> side 11 av 22

12 Resultat.asp Koden under finner ut hvilken bok som ble valgt i bok.html. I tillegg mottas informasjon om navn, adresse og epost-adresse til brukeren (fra betal.asp). Vi har dermed det vi trenger for å sende boka til riktig person. Figur 6: resultat.asp <% Option Explicit Dim navn, adresse, epost %> henter opplysninger fra HTML-skjema navn = request("navn") adresse = request("adresse") epost = request("epost") henter opplysninger fra cookie bok = Request.Cookies ("bok") <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <HEAD></HEAD> <BODY> <H1> Bestilling mottatt </H1> <p> Du har bestilt boka: <%=bok %> <P> Navnet ditt er: <%= navn %> <P> Adressen din er: <%= adresse %> <P> Epost-adressen er: <%= epost %> side 12 av 22

13 Gjemte felt (hidden fields) Dette er en meget enkel måte å ta vare på tilstander. Metoden er ikke beskrevet i boka, men er med for oversiktens skyld. I HTML-skjema er det slik at vi kan spesifisere elementer som hidden. Det betyr at elementet ikke vil vises av nettleseren, men at vi fortsatt kan se elementet vha. Vis/Kilde i nettleseren. Koden under viser hvordan bruken av slike gjemte felt kan være. <FORM>... <INPUT TYPE="HIDDEN" NAME="bok" VALUE= The Shadow Rising > <INPUT TYPE="HIDDEN" NAME="forfatter" VALUE= Robert Jordan >... </FORM> Frivillig oppgave om gjemte felt Koden over viser syntaksen for et gjemt felt. I forrige kap. sendte vi med en cookie fra betal.jsp slik at vi kunne ta vare på informasjonen fra bok.html. Du skal nå forandre denne løsningen til å bruke gjemte felt. Dvs. at du må utvide HTML-skjemaet i betal.asp til også å inneholde gjemte felt. I resultat.asp får du tak i disse gjemte feltene på samme måte som andre felter i HTML-skjemaet Typiske bruksområder for cookies Cookies kan brukes i flere ulike sammenhenger. Her kommer en kort oppsummering av typiske bruksområder. Identifikasjon av bruker i E-handel Vi har allerede sett eksempel på denne metoden i kap En vil ofte lage en litt annen løsning en den vi valgte i dette kapitlet. I stedet for å sende informasjon om bok og forfatter fram og tilbake i en cookie, vil vi kunnet oppnå samme effekt med å lagre dette på tjeneren sammen med en id på brukeren. La oss si at vi lager en id for hver bruker som vil kjøpe en bok, f.eks. ID1, ID2 osv. Vi kan så lagre informasjonen om bok og forfatter på tjeneren sammen med ID en. Når vi får en ny forespørsel fra brukeren med f.eks. ID1 kan vi finne fram til hvilken bok denne brukeren har valgt. Dette er et veldig vanlig scenario og det finnes en egen måte å behandle dette på i ASP. Vi har et innebygget objekt som heter session. Vi skal se nærmere på dette i neste leksjon. Unngå brukernavn og passord På web-sider med lite krav til sikkerhet kan vi bruke cookies til å kjenne igjen brukeren i stedet for å bruke brukernavn og passord. Dette vil være mye mer brukervennlig, men gir side 13 av 22

14 lavere sikkerhet enn brukernavn og passord, da det er nok å ha tilgang til maskinen cookie en ligger på. Web-siden kan også huske andre opplysninger som adresse på brukeren osv. som kan gi meget brukervennlige sider da brukeren kun trenger å oppgi nødvendige opplysninger en gang. Skreddersy web-sider Denne metoden har vi også vært inne på i kap Siste del av kap. 11 i boka omhandler også dette. Spesifisert reklame Reklame på web har blitt populært etter hvert. De som betaler for å ha slik reklame på websidene er generelt mer villig til å betale når de vet at brukeren er interessert i den type produkt som de reklamerer for. Bruk av cookies gir mulighet for å huske oppførselen til brukeren. En kan derfor gi mer relevant reklame til brukeren, samt gi annonsøren mer valuta for pengene Fakta om cookies Nyere nettlesere støtter cookies, men det er mulig å konfigurere dem til å nekte å ta imot cookies. I Internett Explorer 5 gjøres dette med å velge Verktøy/Alternativer for Internett/Sikkerhet/Egendefinert nivå. Ved å bla nedover i skjermbildet så kan en nå krysse av for ikke å akseptere cookies. Internet Explorer 6 må konfigureres på følgende måte: Verktøy/Alternativer for Internett/Personvern/Avansert. Du kan nå velge hvordan nettleseren skal behandle cookies. I Opera gjøres dette med Fil > Instillinger > Personvern > Aktiver informasjonskapsler. Det skal ikke store fantasien til å skjønne at vi fort kan få problemer hvis vi kun baserer oss på bruk av cookies. Omskriving av URL har ikke samme problem, og det kan derfor være en mulighet å bruke denne metoden i stedet, da vi er sikker på at denne vil virke (vi kan imidlertid også få problemer med denne metoden hvis det er mye opplysninger som skal sendes, da denne metoden arver GET-metoden sine problemer (se forrige leksjon)). Sikkerheten med bruk av cookies kan være dårlig. Da opplysningene blir liggende tilgjengelig i en tekstfil på harddisken til brukeren. Det kan være nok å ha tilgang til maskinen for å kunne bruke opplysningene i cookie en. En bruker kan også endre på innholdet i cookie en selv (gjennom en tekst-editor). Tenk bare på eksemplet med bokkjøp i kap Hvis vi hadde side 14 av 22

15 lagret prisen boka koster sammen med boka, kunne brukeren gått inn og forandret prisen! (En mulighet for å begrense denne muligheten er å kryptere innholdet i cookie en slik at ingen kan lese det. Dette krever imidlertid kunnskaper og maskinkraft, og gjennomgås ikke i dette kurset). Forsiktighet må derfor utvises. Nettlesere har også begrensninger i hvor mange slike cookies som aksepteres, typisk 20 pr. område og 300 totalt. Lengden på cookies er begrenset til 4 Kb. Dette gjør at det ikke er noe fare for å fylle opp harddisken på klienten. Cookies vil også føre til økt datatrafikk mellom klient og tjener, men kan holdes på et lavt nivå så lenge det ikke gjemmes mye informasjon her Fakta om gjemte felt En stor ulempe med bruken av gjemte felt kan leses ved hjelp av Vis/Kilde i nettleseren. Dette gjør at brukeren faktisk kan endre innholdet i disse feltene (akkurat på samme måte som for cookies). Også ved bruk av gjemte felt vil det bli en del ekstra trafikk mellom klient og tjener, noe som særlig er uheldig når det er snakk om trege forbindelser. Gjemte felt har et mindre bruksområde enn cookies da innholdet i disse feltene vil være borte hvis du f.eks. lukker nettleseren og kobler deg til web-siden på nytt. Du må da taste inn informasjonen på nytt. Gjemte felt har fordelen over omskriving av URL at en kan bruke POST-metoden ved sending av data, og en omgår derfor problemet med for lange URL er (som en kan få ved bruk av GET-metoden). Metoden er også mer oversiktlig i mange tilfeller Fakta om omskriving av URL Denne metoden har samme fordeler ulemper som for gjemte felt. Med unntak av at informasjonen legges i URL en og sendes som en GET-forespørsel. Dette gjør at en skal være forsiktig med å legge mye informasjon i slike URL er da det er begrensninger på hvor mye informasjon som kan sendes som en del av URL en. side 15 av 22

16 1.3. Inkludering av filer Nå skal vi over på et noe lettere men likevel nyttig tema. Vi skal lære oss å inkludere filer i ASP en vår. En grunn til at vi vil gjøre dette kan være at vi har mange web-sider, og ønsker at sidene skal ha samme logo. Figur 7: Inkludering av fil Det er to måter å få til dette på Tidlig inkludering Denne metoden er beskrevet som tjenerside-inkludering (server-side includes) i boka. Måten vi bruker denne på er:  La oss se nærmere ASP koden for velkommen.asp som ble vist i figuren over. side 16 av 22

17 <BODY>  <P> <H1> Dette er velkomstsiden </H1> <P> blabla... Vi inkluderer i denne koden filen logo.html som ligger på samme katalog som ASP-filen. Logo.html ser slik ut: <IMG SRC="logo.jpg" ALIGN=RIGHT BORDER=1> <A HREF=" Forsiden </A> <BR> <A HREF="mailto:laura@investements.com">E-post Laura </A> <BR CLEAR=all> Vi ser at det denne filen inneholder er referansen til et bilde som ligger på samme katalog som filen. Dette bildet vises i velkommen.asp. Vi har også noe kode som sørger for at utseendet blir noenlunde og link til forsiden og e-post. Så enkelt er det å inkludere en annen fil i en ASP. Den kan inkluderes hvor som helst i ASPsiden. Det vil imidlertid kunne være dumt med relative URL er som i eksempelet over. Vi har her forutsatt at logo.html og logo.jpg ligger på samme katalog som velkommen.asp. Dette er en dum antagelse da vi antagelig vil ha flere web-sider som skal bruke samme logo. Vi vil derfor sannsynligvis ha en egen katalog for logo.html og logo.jpg som alle disse web-sidene kan referere til. Vi lager en egen katalog for disse filene f.eks. c:\inetput\wwwroot\logo. Rotkatalogen her er wwwroot (se leksjon 1). Vi kan nå enklest få tak i logo.html med følgende kode:  Det eneste som er gjort er at ordet file skiftes ut med virtual for å angi at vi starter på rotkatalogen i stedet for stående katalog. Resultatet når vi bruker tjenerside-inkludering er at den inkluderte filen blir satt inn i den andre filen. F.eks. vil velkommen.asp (se figuren først i dette kapitlet) bli slik før den utføres: side 17 av 22

18 <BODY> <IMG SRC="logo.jpg" ALIGN=RIGHT BORDER=1> <A HREF=" Forsiden </A> <BR> <A Laura </A> <BR CLEAR=all> <P> <H1> Dette er velkomstsiden </H1> <P> blabla... Det i fet skrift er koden som er inkludert fra logo.html. At koden blir satt direkte inn i en annen fil gjør at vi faktisk kan legge funksjoner i en fil og bruke funksjonene i en annen. Vi trenger derfor ikke å lage samme funksjon flere ganger hvis den skal brukes i flere ASP er, men vi kan legge funksjonene i en ASP-fil og inkludere denne filen i de ASP ene som skal bruke den aktuelle metoden Sen utførelse Sen utførelse er en annen måte å inkludere filer på. Denne er ny for Internet Information Server 5.0 (IIS). Når sant skal sies er ikke dette en måte å inkludere en annen fil på. I dette tilfellet vil den inkluderte filen utføres. Resultatet av denne utførelsen blir satt inn som en del av resultatet og kontrollen går tilbake til den første ASP-filen. I velkommen.asp brukte vi tjenerside-inkludering for å vise logoen. Vi kan også gjøre dette med sen utførelse. Alt vi trenger å gjøre er å forandre  til <% Server.Execute( logo.html ) %> Du spekulerer sikkert på hvorfor ha to så like metoder, men kun med litt forskjellig skrivemåte. Fakta er at de to metodene oppfører seg ulikt (se de neste kapitlene) Variabler og funksjoner definert i ulike filer Det er to hovedforskjeller mellom de to måtene å inkludere filer på. Tidlig inkludering skal sørge for at inkludering av filer skjer før utførelse av ASP-koden begynner. Ved bruk av sen utførelse skjer inkluderingen under utførelse av ASP-kode. side 18 av 22

19 Se på koden under. <% tidliginkludering.asp %> <%Option Explicit %> <BODY> <% Dim str str= "Dagens tips: Kjør forsiktig" If Hour(Time) < 12 Then %>  <% Else %>  <% End If %> <% morgen.asp %> God morgen <br> <%= str %> <% ettermiddag.asp %> god ettermiddag Kjøring av tidliginkludering.asp gir følgende resultat: Figur 8: Tjenerside-inkludering av filer Legg merke at strengen Dagens tips: Kjør forsiktig defineres i tidliginkludering.asp, men skrives ut i morgen.asp. Morgen.asp har altså tilgang til variablene som er definert i tidliginkludering.asp. side 19 av 22

20 Hva om vi prøver dette med sen utførelse? Vi lager oss en ny ASP seninkludering.asp som er akkurat lik tidliginkludering.asp bortsett fra at vi bruker sen utførelse. Figur 9: Sen utførelse Som vi kan se blir resultatet nå annerledes. Grunnen til dette er at morgen.asp ikke lenger har tilgang til variabelen s som ble laget i seninkludering.asp. Dette er fordi det kun er resultatet av utførelsen av morgen.asp som blir satt inn i seninkludering.asp. Når morgen.asp utføres vil ikke variabelen s være synlig for morgen.asp. Konklusjonen er at vi ikke kan bruke variabler eller funksjoner definert i andre filer når vi bruker sen utførelse Unødig inkludering Du tenker nå at det kanskje ikke er noen vits i å bruke sen utførelse? Det er imidlertid tilfeller denne metoden kommer til sin rett. La oss se på hvordan tidliginkludering.asp vil se ut under utførelse: <% tidliginkludering.asp %> <%Option Explicit %> <BODY> <% Dim str str= "Dagens tips: Kjør forsiktig" If Hour(Time) < 12 Then %> God morgen <br> <%= str %> <% Else %> god ettermiddag <% End If %> side 20 av 22

21 Hvis du kikker nøye igjennom koden over så vil du se at både morgen.asp og kveld.asp er inkludert i denne filen. Dette skjer enda vi ikke har bruk for mer enn en av dem! Vi får altså unødig mye kode inn i filen vår. Hadde vi brukt sen utførelse i stedet ville vi ha unngått dette. Kun den filen som trengs vil i dette tilfellet utføres. Vi kan altså med sen utførelse bestemme oss underveis hvilken fil vi vil inkludere, noe vi ikke kan gjøre med tidlig inkludering. Tenk på følgende: Vi vil lage en ASP der brukeren kan skrive inn i et tekstfelt URL en til en annen ASP eller HTML-fil som han vil se. Dette kan vi få til på en god måte ved sen utførelse, men ikke med tidlig inkludering. I det siste tilfellet må vi da på forhånd inkludere alle filene som brukeren kan finne på å velge. I det første tilfellet derimot så kan vi inne i ASP en velge akkurat den filen brukeren har valgt, etter at han har valgt den Konklusjon Bruk sen utførelse (hvis du bruker IIS5.0 eller nyere) så lenge du ikke skal bruke koden fra en inkludert fil Løsning frivillig oppgave Betal.asp blir slik med gjemte felt, se fet skrift. Forskjellen ligger i at vi sender et gjemt felt tilbake til klienten i stedet for en cookie. <% oppg1_betal.asp %> <% Dim bok ' henter ut verdien til boken som ble valgt i bok.html' bok = Request("bok") %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <HEAD></HEAD> <BODY> <H1> Betalingsinformasjon </H1> <P> Du har krysset av for boka: <%=bok%> <P> For å få denne boka tilsendt må du oppgi navn, adresse og epost. Boka blir så sendt i postoppkrav til deg. <TABLE> <FORM ACTION="oppg1_resultat.asp" METHOD="POST"> <INPUT TYPE="HIDDEN" NAME="bok" VALUE="<%= bok %>"> <TR><TD> Navn: <TD> <INPUT TYPE="TEXT" NAME="navn"> <TR><TD> Adresse: <TD> <INPUT TYPE="TEXT" NAME="adresse"> <TR><TD> Epost: <TD> <INPUT TYPE="TEXT" NAME="epost"> <TR><TD> <TD> <INPUT TYPE="SUBMIT" VALUE="Send"> </FORM> </TABLE> Resultat.asp kan da lages slik: side 21 av 22

22 <% oppg1_resultat.asp %> <% Dim navn, adresse, kortnummer ' henter oppslysninger fra HTML-skjema ' navn = request("navn") adresse = request("adresse") epost = request("epost") %> ' henter oppslysninger fra gjemt felt ' bok = Request("bok") <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//NO"> <HEAD></HEAD> <BODY> <H1> Bestilling mottatt </H1> <p> Du har bestilt boka: <%=bok %> <P> Navnet ditt er: <%= navn %> <P> Adressen din er: <%= adresse %> <P> Epost-adressen er: <%= epost %> side 22 av 22