I dette kapitel vil der blive givet en generel introduktion til ASP. Kapitlet indeholder blandt andet en historisk gennemgang af udviklingen fra statisk til dynamisk indhold på web-stederne, og fordele og ulemper ved henholdsvis programmering på klient- og serversiden. I denne introduktion vil de forskellige programmeringssprog, man kan bruge sammen med ASP, også blive forklaret kort, ligesom det vil blive forklaret, hvordan man kan lave ASP uden selv at programmere. Der afrundes med en kort beskrivelse af alternativerne til ASP.

Fra statisk til dynamisk indhold

I starten af World Wide Webs liv var alle web-steder statiske. Webbet blev kun brugt til at præsentere information i form af rapporter, undersøgelser, forskningsresultater og så videre. Denne opgave kunne markeringssproget HTML sagtens håndtere, og det var da også den mest udbredte web-teknologi på det tidspunkt.

 

Programmer på serveren

Efterhånden som webbet blev brugt til flere og flere ting, opstod der et ønske om at kunne mere end blot at vise information. Man ville gerne kunne vise udtræk fra databaser på web-stederne, og man ville også gerne give de besøgende muligheder for at indtaste oplysninger, der kunne gemmes i databasen.

For at løse denne opgave blev CGI-standarden (Common Gateway Interface) defineret. CGI beskriver, hvordan web-servere og andre programmer snakker sammen. Fra brugerens synspunkt er et CGI-program blot en Internet-adresse (for eksempel http://www.mitsted.dk/cgi-bin/indsend.pl). Web-serveren, ved at denne adresse ikke angiver en HTML-side, der skal vises, men i stedet et CGI-program. Derfor starter web-serveren programmet og giver det oplysninger om den forespørgsel, der skal behandles. Herefter udfører programmet sin opgave, som eksempelvis kan være at gemme oplysninger i en database eller at udtrække oplysninger fra en database. Det resultat, programmet genererer, er formateret i HTML-format, og det er dette resultat, web-serveren sender tilbage til brugeren, som får det vist i sin browser.

Da CGI blev opfundet, var hovedparten af alle web-servere Unix-baserede, og CGI-programmer blev derfor hovedsagelig skrevet i de sprog, der var udbredte i Unix-verdenen. Det drejer sig for eksempel om Perl og TCL. Fordi mange af de sprog, der blev benyttet, er scriptsprog, kaldes CGI-programmer ofte for CGI-scripts. Det er dog også muligt at lave CGI-programmer, der er skrevet i andre programmeringssprog, og som er kompileret til maskinkode. Dette bruges blandt andet på Windows-platformen, hvor mange CGI-programmer findes som exe- eller dll-filer.

Teknologien bag CGI-programmer har imidlertid nogle ulemper. Det største problem er, at programmerne afvikles på serveren. Umiddelbart virker det meget fornuftigt at lade serveren, der jo ofte er en meget kraftfuld maskine, udføre programmerne, og det er også tit nødvendigt, hvis programmerne skal have adgang til oplysninger gemt i en database på serveren. Problemet med denne fremgangsmåde er bare, at programmerne har uanede muligheder på serveren. For eksempel kan man skrive et program, der formaterer serverens harddisk, eller på anden måde ødelægger serveren. Dette problem var ikke så stort, da CGI blev opfundet i starten af webbets historie, men efterhånden som flere og flere brugere kom på nettet, og flere og flere brugere havde deres hjemmesider på den samme server, blev det et problem, at en bruger kunne ødelægge det for de andre. Mange Internet-udbydere valgte ligefrem at forbyde deres brugere at benytte CGI-programmer, mens andre begrænsede adgangen til nogle få programmer, som udbyderen selv stillede til rådighed.

 

Programmer på klienten

Denne udvikling gjorde, at det blev svært for mange brugere at lave dynamiske hjemmesider, fordi deres Internet-udbyder simpelthen ikke tillod det. Derudover var der et ønske om at lave web-siderne mere interessante for brugerne. Mange valgte derfor at skifte fra at lade programmerne køre på serveren til at lade dem køre på klientens computer. Det var Netscape, der definerede den teknologi, der gjorde dette muligt. Teknologien gjorde det muligt at skrive programmer, der kunne inkluderes i HTML-sider, og derefter blive udført på klientens maskine. Netscape definerede et sprog, man kunne skrive programmerne i. Dette sprog blev kaldt JavaScript (og det må ikke forveksles med Java fra Sun, som er noget helt andet). JavaScript blev i første omgang inkluderet i Netscapes egen browser, Navigator, men blev senere også inkluderet i Microsoft Internet Explorer. Her blev sproget dog kaldt Jscript, og det var ikke helt magen til JavaScript fra Netscape. Nogle ting kunne man kun gøre i JavaScript, og andre ting kunne kun gøres i Jscript. Derudover valgte Microsoft at definere sit eget sprog, som kun kunne afvikles i Internet Explorer. Dette sprog blev baseret på Microsoft Visual Basic, og kom derfor til at hedde VBScript.

Dette viser en af svaghederne ved at afvikle programmerne på klienten – man kan ikke være sikker på, at programmet virkeligt bliver afviklet. Skriver man for eksempel sit program i JavaScript, kan man ikke være sikker på, at det bliver afviklet korrekt i Internet Explorer. Derudover har man et problem, hvis brugeren har en browser, der er så gammel, at den slet ikke kender til JavaScript eller Jscript – så bliver ens program med garanti ikke udført.

Derudover har man ikke løst det sikkerhedsproblem, CGI-script gav på serveren, men i stedet flyttet det til klientens computer. Skrækhistorierne om, hvad det var muligt at gøre ved klientens computer ved hjælp at JavaScript, Jscript eller VBScript har været utallige, og det har fået mange sikkerhedsnervøse brugere til at slå scriptfunktionerne i browseren helt fra. Derved er der endnu flere brugere, der ikke får programmerne afviklet.

En anden svaghed ved klientscriptene ligger i teknologiens natur. Eftersom scriptene skal afvikles på klientens computer, er det nødvendigt at overføre dem til den. Som nævnt tidligere bliver scriptene overført som en del af de HTML-sider, brugeren vælger at få vist – det betyder, at brugeren nemt kan se, hvordan scriptet er opbygget, og uden videre kopiere det til sit eget web-sted. Dette er naturligvis ikke lovligt, men det har ikke forhindret mange mennesker i at gøre det, og det er da også særdeles svært – hvis ikke umuligt – at bevise, hvem der har ophavsretten til et script, der ligger på nettet, og som kan være blevet hentet af flere millioner brugere. Dette problem har lagt en stor begrænsning på mængden af kommercielle scripts udviklet af professionelle programmører. Der er ikke mange, der vil give penge for et script, når man ved, at man selv kan kopiere det på 5 minutter uden at skulle give en øre for det.

Endeligt er der det problem, at det ikke er alting, det er muligt at gøre fra klienten. Man kan eksempelvis ikke læse eller skrive i en database, der ligger på serveren, fra et program, der afvikles på klienten.

Alle disse problemer fandtes ikke, da man lod programmerne blive afviklet på serveren. Brugeren havde ingen mulighed for at forhindre programmerne i at blive kørt, og man var sikker på, at brugeren kunne se resultatet, ligegyldigt hvilken browser han benyttede, for svaret blev jo bare returneret som et ganske almindeligt HTML-dokument.

Der var derfor et udbredt ønske om at få flyttet programafviklingen tilbage serveren, men på en måde, der var mere sikker end CGI.

 

ASP

Det er her ASP, kommer ind i billedet. ASP blev opfundet af Microsoft som en mulighed for at afvikle programmer sikkert på serveren. I praksis har ASP dog mange af de samme risici, som fandtes ved CGI, men ASP har dog en lang række andre fordele over CGI.

CGI-programmer er selvstændige programmer, der selv skal generere hele resultatet. Med ASP er det muligt at skrive hovedparten af resultatet som almindelig HTML, mens den dynamiske del af siden kan skrives i et scriptsprog.

Derudover bliver ASP afviklet inde i web-serveren, hvilket giver web-serveren mulighed for at kontrollere programmet, når det bliver afviklet. I forhold til CGI har ASP også den fordel, at programmerne skrives i scriptsprog, der typisk er lettere at lære, end de mere komplicerede programmeringssprog. Denne medalje har dog også en bagside: der er mange ting, der ikke kan gøres fra scriptsprogene i ASP, men som sagtens kan gøres fra CGI-programmer.

Fordelene ved ASP er dog større end ulemperne, og derfor er ASP også blevet meget udbredt på forholdsvis kort tid.

Sprogene

ASP er ikke i sig selv et programmeringssprog. Det er en standard, som gør det muligt at skrive programmer, der kan afvikles fra web-servere. Standarden siger intet om, hvilket sprog programmerne skal være skrevet i. Der er dog mange ting i standarden, der antyder, at ASP bedst kan kombineres med scriptsprog.

Et scriptsprog skal ses i modsætning til ”rigtige” programmeringssprog som Java, C++, Visual Basic og så videre. Den væsentligste forskel på et scriptsprog og et af de andre sprog er, at scriptsproget bliver fortolket. Det vil sige, at programmer skrevet i et scriptsprog ikke skal kompileres, før de udføres. Dette kan umiddelbart virke som en fordel – det er jo trods alt hurtigere at skrive et program, hvis man ikke skal bruge tid på at kompilere det – men der er en række ulemper ved det. Den væsentligste ulempe er nok, at man mister compilerens kontrol af ens program. Hvis man ved, at det program, man har skrevet, kan kompileres, så er man i det mindste sikker på, at der ikke er syntaktiske fejl i programmet. Ved at undvære compileren mister man også muligheden for at kontrollere, at sprogets typer bruges korrekt – groft sagt kan man uden en compiler lægge æbler og bananer sammen.

En tredje ulempe ved et ikke-kompileret program er, at det er langsommere at afvikle end et kompileret program. For i virkeligheden skal programmet jo kompileres – det er bare et spørgsmål om, hvornår det sker. Vælger man et scriptsprog, sker kompileringen først, når programmet skal udføres. Det betyder, at brugeren skal vente, både på at programmet bliver udført, og at programmet bliver kompileret.

På den baggrund kunne man tro, at det er fuldstændigt håbløst at arbejde med scriptsprog. Men der er imidlertid også nogle fordele. I forrige afsnit nævntes det godt nok, at det var en ulempe, at programmet først skulle kompileres, når det skulle udføres – og selvom det er sandt, er der dog også muligheder for at optimere udførslen af et scriptprogram. For eksempel er der en masse ting, man ved, når programmet bliver udført, som man ikke ved, når man normalt kompilerer et program. Ved udførsel af et program ved man for eksempel præcis, hvilke dele af programmet, der skal udføres. Man kan afgøre resultatet af de fleste betingelser i programmet. For eksempel er et udtryk som ”hvis brugeren er over 16 år, så…” svært at afgøre, når man normalt kompilerer programmer, fordi man ikke på det tidspunkt har kendskab til brugeren. Til gengæld er det let at afgøre, når programmet afvikles, for da har brugeren allerede indtastet sin alder. Når man ved, hvilke dele af programmet, der skal udføres, kan man naturligvis nøjes med at kompilere de dele, der bliver brug for, og det er lige nøjagtigt det, der sker.

Der er dog også en anden fordel, som nok er den, der er den væsentligste grund til, at det er scriptsprog, der anvendes i samarbejde med ASP. Den grund er, at når man ikke kompilerer et program, kan man egentligt være ligeglad med, hvad der står i det, indtil man skal udføre det. Det betyder, at man kan blande programkode med alt muligt andet – for eksempel HTML-kode.

De scriptsprog, der oftest bruges sammen med ASP, er JavaScript og VBScript. Disse vil kort blive gennemgået i det følgende. Gennemgangen er tænkt som en kort introduktion til sprogene og ikke som en grundig gennemgang.

Der er ikke særlig stor forskel på, hvilke muligheder de to sprog stiller til rådighed, og man kan således ikke sige, at det ene sprog er bedre end det andet. I denne bog har vi valgt at skrive eksemplerne i JavaScript.

Ligesom virkelige sprog udvikler sig, og der kommer nye udtryk til, udvikler scriptsprogene sig også. Derfor findes der i øjeblikket to forskellige udgaver af sprogene. De nye versioner (VBScript 5 og JScript 5) kan kun bruges, når serveren er Windows 2000. Der er dog ikke indført megen ny funktionalitet i de nye udgaver, og derfor behandles de i hovedparten af denne bog ens. Enkelte steder, bliver der dog gjort opmærksom på, at en given fremgangsmåde kun kan benyttes af en bestemt udgave af sproget.

 

JavaScript

Som det blev nævnt tidligere, er JavaScript et sprog, der blev udviklet af Netscape for at gøre det lettere at lave spændende hjemmesider. Første gang sproget blev nævnt i denne bog, var i forbindelse med programmer på klienten, og man kunne således forledes til at tro, at JavaScript ikke havde noget at gøre på serveren. Dette er imidlertid ikke sandt, for JavaScript er et generelt sprog – klientprogrammer er blot en af dets mange anvendelser; Netscape bruger for eksempel JavaScript i de fleste af deres serverprogrammer, og det kan også anvendes i forbindelse med ASP.

JavaScript må ikke forveksles med Java fra Sun. Java er et egentligt programmeringssprog, som skal kompileres, og som man kan skrive selvstændige programmer i. JavaScript derimod er et scriptsprog, som kun kan bruges til at skrive småprogrammer (scripts), som udføres i andre programmer (for eksempel web-servere). Derudover er JavaScript typeløst (alle variable er af den samme type), mens Java har stærkt typecheck og indeholder flere hundrede forskellige typer og klasser. Ligeledes er Java et fuldstændigt objektorienteret sprog, mens JavaScript kun giver mulighed for at benytte de objekter, der i forvejen er defineret af den standard, scriptet skal afvikles under – det kan eksempelvis være ASP.

Med det på plads skal det dog nævnes, at der er visse ligheder mellem Java og JavaScript, men det gælder kun selve opbygningen af sproget. For eksempel er mange af kontrolstrukturerne i de to sprog ens, og hvis man i forvejen kender til Java, er det nok en fordel at vælge JavaScript som sit programmeringssprog.

JavaScript er blevet standardiseret af ECMA (European Computer Manufacturer Association) og hedder derfor ECMAScript. Både JavaScript, som det er defineret af Netscape, og JScript, som det er defineret af Microsoft, opfylder ECMAScript-standarden – men de indeholder også nogle tilføjelser. Der er altså stadig forskel på JavaScript og JScript, men så længe man kun bruger de muligheder, der er standadiserede, er man på den sikre side.

For at mindske navneforvirringen bliver alle tre JavaScript-varianter i denne bog kaldt JavaScript, selvom det egentligt er JScript, der benyttes, da ASP – ligesom JScript – er opfundet af Microsoft.

 

Generel syntaks

I JavaScript er der forskel på store og små bogstaver. Det vil sige, at variablen Tal ikke er det samme som variablen tal.

For hver kodesætning er det god skik at sætte et semikolon, men det er ikke strengt nødvendigt. Semikoloner kan være med til at gøre programmet lettere at læse, men hvis man ikke er rutineret i et programmeringssprog, der anvender semikolon, kan det være besværligt at få dem sat rigtigt.

 

Metoder

Nogle programmeringssprog skelner mellem funktioner og procedurer. En funktion er en metode, der returnerer en værdi, mens en procedure er en metode, der ikke returnerer en værdi. Et eksempel på en funktion kunne være kvadratrod, som returnerer kvadratroden af et tal. Et eksempel på en procedure kunne være udskriv, der udskriver noget tekst, men intet returnerer.

I JavaScript benyttes denne skelnen ikke. Her bliver funktioner og procedurer under ét kaldt funktioner. Man erklærer en funktion ved at bruge ordet function, der efterfølges af funktionens navn. Herefter angiver man navnene på de parametre, funktionen skal bruge, i parentes. Eksempelvis

 

function areal(len, bredde) {

return len * bredde;

}

 

Eksemplet viser lidt mere end blot, hvordan man erklærer en funktion. Den viser også, at alle de kommandoer, der er en del af funktionen, skal samles mellem { og }. Eksemplet viser også, hvordan man returnerer en værdi. Det gør man ved at skrive return efterfulgt af den værdi, der skal returneres. I dette eksempel er det arealet, der skal returneres, og det findes som bekendt ved at gange længde med bredde.

I JavaScript består et program ikke kun af funktioner. Det er også muligt at skrive kode, der ikke er del af en funktion. Da JavaScript som nævnt er et fortolket sprog, vil den del af programmet, der står uden for funktioner, blive udført, når fortolkeren når til det, mens funktionerne kun vil blive udført, når de bliver kaldt eksplicit. Hvis et program kun består af funktioner, vil der således intet ske, når det bliver udført.

 

Kontrolstrukturer

Kontrolstrukturer er de strukturer i et sprog, der gør det muligt at kontrollere afviklingen af programmet. Det kan for eksempel være løkker, der gentager dele af programmet, eller betingelser, der afgør, hvilke dele af programmet, der skal udføres.

I JavaScript bruges tegnene { og } til at samle flere linier kode i en blok. Det vil sige, at hvis der er flere linier kode, der kun skal udføres, hvis en bestemt betingelse er opfyldt, skal disse linier omkranses af { og }.

JavaScript indeholder to forskellige former for løkker. Det er for-løkker og while-løkker. Det er ikke direkte forkert at bruge den ene løkke fremfor den anden, for de kan det samme. Der er dog typisk en af løkkerne, det er mere hensigtsmæssigt at bruge end andre.

For-løkker bruges typisk, når en sektion skal løbes igennem et bestemt antal gange. Hvis man eksempelvis vil summere tallene fra 1 til 9, kan man skrive

 

sum = 0;

for (tal = 1; tal < 10; tal = tal + 1) {

sum = sum + tal;

}

 

Umiddelbart ser for-strukturen lidt kompliceret ud. Lad os først konstatere, at indholdet af parentesen i for-sætningen består af tre dele, der er adskilt af semikolon. Den første del indeholder initialisering – denne del bliver udført, før løkken køres første gang. Den næste del kaldes kørselsbetingelsen, fordi det er en betingelse, der skal være sand, for at løkken bliver kørt. I dette tilfælde er betingelsen tal < 10, hvilket betyder, at løkken bliver kørt, så længe tal er mindre end 10. Den sidste del kaldes tællerskridtet – her bliver tal talt op. Tællerskridtet udføres for hver gang, løkken er blevet udført. Det vil altså sige, at tal ender med at være 10. Sidste gang løkken køres, er tal 9, men tællerskridtet udføres som det sidste, og derfor bliver tal talt op til 10.

While-løkker bruges, hvis en løkke skal udføres, så længe et givent udtryk er sandt. Det kan for eksempel være, så længe der ikke er ny e-post.

 

while (antal_beskeder == 0) {

…

}

 

JavaScript har også et udtryk, der hedder enumerator. Det er en samling af oplysninger. Enumerator-objektet bruges ofte i ASP, når man skal have oplysninger om en række elementer – det kan for eksempel være elementerne i en HTML-formular.

Enumerator-objektet bruges således:

 

enum = new Enumerator(elementer);

while (!enum.atEnd()) {

element =  enum.item();

enum.moveNext();

}

 

Det, eksemplet viser, er, at man kan oprette et Enumerator-objekt ved at skrive new Enumerator og derefter angive et objekt, der indeholder en række elementer. Dette kan være et objekt eller en funktion, der returnerer et objekt. Hvis man vil gennemløbe alle elementerne i Enumerator, kan man lave en løkke, der kører så længe atEnd() returnerer falsk.

Når man vil have det objekt, enumeratoren peger på lige i øjeblikket, skal man kalde metoden item(). For at gå videre til det næste objekt skal man bruge metoden moveNext().

 

Operatorer

Operatorer er de tegn eller udtryk, man kan sætte imellem to udtryk. Det kan for eksempel være de almindelige regneoperatorer (+, -, *, /), eller nogle mere avancerede operatorer, der sammenligner eller tildeler værdier.

I JavaScript anvendes et enkelt lighedstegn til at tildele værdier, mens dobbelte lighedstegn bruges til at sammenligne værdier:

 

tal = 2;

if (tal == 2) {

…

}

 

Derudover har JavaScript to operatorer til at optælle og nedtælle en værdi. Det er henholdsvis ++ og –.

 

Nedenstående eksempel tildeler variablen tal værdien 5, hvorefter den tælles en op (til 6), hvorefter den tælles en ned (til 5).

 

tal = 5;

tal++;

tal–;

 

Exceptions

Med introduktionen af Windows 2000 er der foretaget en opdatering af de scriptsprog, der understøttes i forbindelse med ASP. JavaScript-fortolkeren er blevet opgraderet til version 5, hvilket betyder, at man nu har mulighed for at håndtere exceptions. Exceptions er en måde at angive, at der er opstået en fejl. Nedenstående eksempel viser, hvordan man kan bruge exceptions i JavaScript.

 

try {

// gør noget

} catch (exception) {

// gør dette, hvis der opstår en fejl

}

 

De programlinier, der kan medføre en exception, skal skrives i en try-blok. Hvis der opstår en exception, afbrydes udførslen af try-blokken, og i stedet udføres catch-blokken.

Man kan også selv skrive kode, der kan give en exception. Så skal man først lave en exception-metode, som skal se således ud:

 

function MinException (nummer, beskrivelse, info) {

this.Number = nummer;

this.Description = beskrivelse;

this.CustomInfo = info;

}

 

Når der opstår en fejl, kan man kaste den pågældende exception. Det gøres således:

 

enException = new MinException(10, “Kan ikke dividere med 0”, “Fejl”);

throw enException;

 

Som det ses af ovenstående, er exception-systemet i JavaScript stort set det samme som i programmeringssproget Java.

 

VBScript

Som nævnt tidligere er VBScript Microsofts svar på JavaScript. Hvor VBScripts udbredelse på klientsiden er begrænset, fordi det kun understøttes af Microsofts egen browser, er der ingen problemer i at anvende det på serversiden, da det er web-serveren, der udfører scriptene, og ikke browseren.

Som sprog minder VBScript meget om Microsoft Visual Basic – dog er der en lang række ting, man ikke kan i VBScript, som er mulige i Visual Basic. Man kan sige, at VBScript er til Visual Basic som JavaScript er til Java. Visual Basic er det sprog, der bruges til at skrive fuldstændige applikationer, mens VBScript bruges til at skrive småprogrammer, der udføres af andre programmer. På linie med JavaScript er VBScript typeløst – det vil sige, at alle variable er af den samme type: Variant.

 

Generel syntaks

I VBScript er der ikke forskel på store og små bogstaver – det er i tråd med sproget BASIC, hvor store og små bogstaver også opfattes ens. I modsætning til JavaScript er det i VBScript forbudt at bruge semikolon for enden af en linie. Hver kommando afsluttes i VBScript med et linieskift, og fortolkeren håndterer selv kommandoer, der strækker sig over mere end en linie.

 

Metoder

Når man bruger VBScript, skal man være opmærksom på, at der er stor forskel på funktioner og procedurer. Funktioner er som nævnt metoder, der returnerer en værdi, mens procedurer intet returnerer. Nedenstående eksempel viser, hvordan man laver en procedure – i VBScript kaldes procedurer for Subs.

 

Sub udskriv

…

End Sub

 

Funktioner kaldes I VBScript for functions (ligesom i JavaScript), og en funktion kan defineres således:

 

Function areal(len, bredde)

areal = len * bredde

End Function

 

Eksemplet viser også, hvordan man returnerer en værdi fra en funktion. Hvor man i JavaScript bruger det reserverede ord return, gør man i VBScript det, at man tildeler funktionen den værdi, der skal returneres. I dette eksempel skal værdien af udtrykket len * bredde returneres, og da funktionen hedder areal, skriver man simpelthen areal = len * bredde.

Allerede nu begynder en del af forskellene på JavaScript og VBScript at blive tydelige. Ikke alene returnerer man værdier på forskellige måder, man samler også kommandoer i blokke på forskellige måder.

Hvor man i JavaScript bruger { og } til at angive blokke, bruger man i VBScript reserverede ord. I ovenstående eksempel er det Function, som automatisk starter en blok, og End Function, der afslutter den. Det samme princip anvendes ved betingelser, hvor If automatisk starter en blok, og End If automatisk afslutter den.

 

Kontrolstrukturer

Kontrolstrukturerne i VBScript er væsentligt anderledes end i JavaScript. Ligesom JavaScript har VBScript både For-løkker og While-løkker. Selvom løkkerne har samme navn som løkkerne i JavaScript, er deres syntaks meget anderledes.

For-løkken i VBScript ser således ud:

 

Sum = 0

For Tal = 1 To 10

Sum = Sum + Tal

Next

 

Denne løkke gør præcis det samme som den tilsvarende løkke i JavaScript-afsnittet: den summerer alle tal mellem 1 og 10. Umiddelbart ser VBScripts udgave af For-konstruktionen simplere ud end JavaScripts. Det skyldes, at man ikke har så mange muligheder i VBScripts For-løkker som i JavaScripts for-løkker.

Initialiseringen af variablen Tal sker umiddelbart efter det reserverede ord For. Efter initialiseringen følger det reserverede ord To. Det tal, der står efter To, angiver den største værdi Tal vil få. I dette eksempel er det 10.

I JavaScript var optællingen af Tal også en del af For-sætningen – det er ikke tilfældet i VBScript. Her bliver Tal først talt op, når man når til udtrykket Next, der afslutter For-blokken. Det vil sige, at det er kommandoerne mellem For og Next, der bliver udført i løkken.

Som det ses, er der adskillige ting, der var simpelt i JavaScript, som man ikke umiddelbart kan gøre i VBScript. Det gælder for eksempel at lave en For-løkke, hvor kørselsbetingelsen ikke afhænger af Tal’s værdi. Det gælder også at ændre Tal’s værdi med andet end +1 for hver gennemkørsel af løkken.

While-løkkerne i VBScript minder en del om de tilsvarende While-løkker i JavaScript. Hvis man vil implementere løkken fra JavaScript-afsnittet i VBScript, ville den se således ud:

 

While (Antal_Beskeder = 0)

. . .

Wend

 

Ovenstående løkke kører, så længe variablen Antal_Beskeder har værdien 0. Ordet While starter en blok i koden, mens ordet Wend slutter den. Det er altså med andre ord linierne mellem While og Wend, der udføres i løkken.

 

Operatorer

VBScript har ikke lige så mange avancerede operatorer som JavaScript. Der er naturligvis de almindelige, matematiske operatorer (+, -, * og /). Derudover er der selvfølgelig sammenligningsoperatorer og en operator til tildeling. I modsætning til JavaScript bruger VBScript den samme operator til sammenligning og tildeling – operatoren er =. Det betyder, at nedenstående eksempel er korrekt:

 

Tal = 5

If Tal = 5

. . .

End If

 

Hvis man skal sammenligne for forskellighed, skal man bruge operatoren <>. Eksempelvis sådan:

 

Tal = 7

If Tal <> 5

. . .

End if

Visuelle værktøjer

Da World Wide Web og HTML begyndte at blive populært, blev der udviklet masser af små HTML-redigeringsprogrammer (HTML-editorer), der skulle gøre det lettere at skrive HTML. Inden længe fik disse dog hård konkurrence af de grafiske HTML-værktøjer, der gjorde det muligt at lave en HTML-side uden at forstå en brik HTML – den eneste evne man skulle have, var at kunne betjene et program med en grafisk brugergrænseflade. Microsoft Frontpage er et eksempel på den slags programmer.

Udviklingen indenfor ASP tager den samme retning. Der findes allerede en række programmer, der kan generere ASP-sider automatisk. De mest udbredte til Windows-platformen er nok Drumbeat 2000 fra Macromedia og Microsoft Visual InterDev. Microsoft Access fra pakken Microsoft Office er dog også i stand til at generere nogle standardiserede ASP-sider.

Ved at bruge disse visuelle værktøjer kan man lave en mængde ASP-sider i en fart, og hvis udviklingstiden er det eneste succeskriterium, er det klart, at man skal vælge at bruge et af de visuelle værktøjer.

Der er imidlertid også en række ulemper ved de visuelle værktøjer. Den største ulempe ligger nok begravet i selve konceptet bag et visuelt værktøj. Værktøjet er intet værd, hvis det ikke er generelt. Der er ikke ret meget ved et værktøj, hvis det kun kan udføre en bestemt opgave – det skal naturligvis kunne tilpasses den enkelte bruger, og generere ASP-sider med præcis det indhold, designeren vil have. For at kunne dette skal værktøjet tage højde for en hel masse ting – en masse ting, som i de fleste tilfælde er særdeles overflødige. Derfor genererer værktøjerne ofte en masse overflødig programkode. Overflødig programkode optager ikke bare unødigt meget plads på web-serveren, men det belaster også serveren unødigt, når siderne skal hentes frem og fortolkes, ligesom det giver længere svartider til brugeren, fordi store sider tager længere tid at fortolke end små.

Et andet problem er, at selvom værktøjerne som regel er ret generelle, kan man let løbe ind i en problemstilling, som værktøjet ikke kan klare. I så fald er man nødt til at have et vist kendskab til ASP, da man enten selv skal skrive det hele fra bunden, eller fordi man skal tilpasse det, værktøjet har genereret. I det sidste tilfælde får man derudover det problem, at de ASP-sider, der bliver genereret af de visuelle værktøjer, oftest er særdeles uoverskuelige.

 

Drumbeat 2000

I forhold til tidligere versioner af Drumbeat er Drumbeat 2000 stærkt forbedret. Programmet findes i flere forskellige udgaver – i dette afsnit beskrives ASP-versionen.

Drumbeat 2000 kan dels bruges som designerværktøj til hjemmesider på linie med eksempelvis Microsoft Frontpage. En mere interessant anvendelse af produktet er dog muligheden for at lave ASP-sider med udgangspunkt i en database.

Til at foretage dette findes en guide. Denne guide skal man fortælle, hvilken database man vil benytte, samt hvilken SQL-forespørgsel som udvælger de data, der skal arbejdes på.

Dernæst kan man vælge, hvilke funktioner man skal have. Der er muligheder for søgning, sletning, oprettelse og ændring. Systemet bygges op om en søgning eller en total oversigt over posterne og med knapper til at gå til næste og forrige post.

 

Figur 1.1: Det er simpelt at lave ASP-sider med databaseadgang fra Drumbeat 2000.

 

 

 

 

 

 

Systemet er forholdsvis let tilgængeligt. Designet af siderne er særdeles simpelt, men det er kun en fordel. Det gør siderne hurtigere at indlæse, og man kan altid bruge nogle af Drumbeats avancerede funktioner til at lave et pænere design.

En anden ting, der gør Drumbeat 2000 interessant, er, at man har forsøgt at tage højde for de forskellige browsere. Man kan således vælge, hvilken browser ens web-sted skal henvende sig til. I et vist omgang sørger Drumbeat 2000 for at tilpasse siderne den browser, men på visse punkter må den melde pas og sige, at den pågældende funktion ikke kan udføres på grund af den valgte browser.

Et andet eksempel på fleksibiliteten i Drumbeat 2000 er, at man selv kan vælge, hvilke scriptsprog der skal vendes. Drumbeat 2000 er i stand til at generere ASP-sider i såvel JavaScript som VBScript. Dette er en fordel, hvis man selv skal tilpasse siderne efterfølgende – og det skal man sandsynligvis.

Det største problem ved Drumbeat 2000 er, at de ASP-sider, der genereres, er særdeles store. Det vil sige, at de både optager plads på web-serveren, og at de tager en del tid at afvikle, hvilket naturligvis også belaster web-serveren. Eksempelvis inkluderes skrupelløst JavaScript-filer på 53 KB, hvortil sidernes størrelse på cirka 7 KB skal lægges. Alt i alt en hel del for at kunne trække data ud af en database og tilføje og redigere.

Alt i alt er Drumbeat dog et godt værktøj til at generere administrationssider til at opdatere databasen på web-stedet, men det kan ikke anbefales til udvikling af selve web-stedet.

Web-sted: www.macromedia.com/software/drumbeat/.

 

Microsoft Visual InterDev

Microsoft Visual InterDev er ikke umiddelbart så simpelt at gå til som Drumbeat 2000. Hvis man ikke i forvejen har kendskab til Microsofts udviklingsværktøjer, vil man nok synes, at produktet er lidt omstændeligt at bruge de første par gange.

Grunden til dette er, at Microsoft Visual InterDev indeholder en lang række avancerede funktioner. Alt lige fra at lægge dokumenterne op på web-serveren til generering af søgesider og meget andet håndteres automatisk af programmet.

Ligesom Drumbeat 2000 giver Microsoft Visual InterDev mulighed for, at man selv kan vælge, hvilket scriptsprog, der skal bruges. Man skal dog specifikt vælge JavaScript, hvis man vil bruge det i stedet for VBScript.

Som det er kendetegnende for automatiske værktøjer som Microsoft Visual InterDev, er den kildetekst, der genereres, temmelig omfattende. Når man bruger projektguiden til at oprette et nyt projekt, genererer den automatisk 281 KB kildetekst. Denne kildetekst indeholder alle de funktioner, der – måske – skal bruges på web-stedet, alt efter hvor mange af Visual InterDevs avancerede muligheder man vælger at anvende.

Når man først kommer i gang med at benytte Microsoft Visual InterDev er værktøjet dog behageligt at arbejde med, og det indeholder en række guides, der hjælper en med at løse en række af de mest almindelige opgaver i forbindelse med web-udvikling.

Web-sted: msdn.microsoft.com/vinterdev/.

 

Microsoft Access

De seneste versioner af Microsoft Office har koncentreret sig mere og mere om integration med Internet. Det har betydet, at alle programmerne kan gemme deres dokumenter i HTML-format – det har også betydet, at databaseprogrammet Microsoft Access har fået indbygget muligheden for at lave ASP-sider.

I modsætning til de andre programmer, der er blevet beskrevet, er Access stærkt begrænset. Hvor formålet med de andre programmer er at udvikle ASP-sider, er Microsoft Access hovedsageligt et databaseprogram.

De ASP-sider, der kan genereres med Microsoft Access, er meget simple, og uden manuel tilpasning vil de ikke være egnede til at lægge på Internet. Fra Microsoft Access er det ikke muligt at kombinere ASP-koden med flot design – det er tydeligt, at det her er dataene, der er i højsædet, og ikke udseendet.

Fra Microsoft Access kan man for eksempel gemme en forespørgsel som en ASP-side. Det vil sige, at man kan få den samme forespørgsel udført ved at kalde en ASP-side. Det dynamiske i dette er, at indholdet af ASP-siden naturligvis ændrer sig, når indholdet af databasen ændrer sig. Det er dog ikke muligt at få forespørgslen til at ændre sig baseret på brugerens valg. Alle forespørgslerne skal designes i Microsoft Access på forhånd.

Dette betyder, at anvendeligheden af Microsoft Access som ASP-generator er stærkt begrænset. Hvem kunne for eksempel forestille sig at lave en søgemaskine, hvor brugeren ikke selv kunne indtaste, hvilke ord der skulle søges efter, men var nødt til at vælge fra en liste af ord. Dette kunne blive konsekvensen, fordi alle forespørgsler skal genereres på forhånd.

Der er dog nogle tilfælde, hvor det kan være ganske fornuftigt at bruge Microsoft Access til at lave ASP-sider. Det kan eksempelvis være en statistikfunktion, hvor forespørgslerne er forholdsvis konstante – det vil typisk være antal besøgende fordelt på dage. Denne forespørgsel vil med fordel kunne skrives i Microsoft Access og derefter gemmes som ASP-fil. Et andet eksempel er en fuldstændig og ufiltreret visning af indholdet af en tabel – her er det væsentligt lettere at bede Microsoft Access om at lave en ASP-fil, der viser indholdet af tabellen, end selv at lave den.

 

Sammenfatning

Hvis man skal udvikle et større web-sted og har brug for et integreret udviklingsmiljø til alle dele af udviklingen, er Microsoft Visual InterDev et godt valg. Har man i stedet kun behov for automatisk generering af ASP-sider med databaseadgang og lignende, bør man nok vælge Drumbeat 2000, der er noget lettere at gå til. Endeligt kan man jo også spare pengene, og selv skrive al den nødvendige kode – dette ender sandsynligvis med et web-sted, der fylder mindre og er hurtigere.

Alternativer til ASP

Selvom denne bog omhandler ASP, er vi ikke blinde for, at der findes en række alternativer til ASP. Disse alternativer har hver deres fordele og ulemper, som kort vil blive beskrevet i dette afsnit.

 

JavaServer Pages (JSP)

JavaServer Pages blev lanceret i 1999 af Sun som et direkte modstykke til Active Server Pages. Hovedårsagen til at Sun har valgt at genopfinde den dybe tallerken, skal nok findes i, at ASP ikke har kunnet implementeres på Sun-Netscape-alliancens web-servere, og at det i særdeleshed ikke har kunnet installeres på Suns egen Java Web Server. Tidligere har den eneste måde at lave dynamik på disse servere været CGI eller Java-servletter. Det er tidligere i denne bog blevet omtalt, hvorfor mange gerne vil undgå CGI, og Java Servlets er forholdsvis komplicerede at programmere – i hvert fald i forhold til ASP. Udvikling af Java Servlets kræver som minimum installation af Sun Java Development Kit, og selvom det produkt er gratis, er det unødigt besværligt (for slet ikke at tale om, hvad det koster at hente 20 MB via et modem). Med ASP er der ingen krav til udstyret – ASP-siderne kan skrives fra en hvilken som helst editor – for eksempel Notesblok, som følger gratis med Windows.

Sun har naturligvis indset dette problem og har set sig nødsaget til at opfinde en tilsvarende teknologi, før Microsofts web-servere blev alt for udbredte – denne teknologi blev JSP.

JSP er særdeles tæt integreret med Java. Hvor ASP blot beskriver, hvilke objekter, der kan bruges og hvordan, men ikke stiller krav til det sprog, programmerne skrives i, kræver JSP at der bruges Java som programmeringssprog. Grunden til dette krav er, at JSP-sider – i modsætning til ASP-sider – bliver kompileret. Resultatet af denne kompilering er en Java-servlet. En servlet kan i grove træk sammenlignes med et CGI-program, der afvikles på serveren. At JSP-siderne bliver kompilerede betyder, at de kan afvikles hurtigere end ASP-sider.

At udvikle JSP-sider svarer meget til at udvikle ASP-sider. I sit program kan man uden problemer blande HTML-kode og Java. Selve oversættelsen til en Java-servlet foregår automatisk bag programmørens ryg. Dette er som regel en fordel, men kan være et problem, når man skal forsøge at finde fejl i sin JSP-side. Så er det ikke ret anvendeligt at få at vide, at der er en fejl i linie 200 i den kompilerede servlet, når det linienummer ikke har nogen sammenhæng med linienumrene i ens egen JSP-side.

Den store fordel ved at anvende JSP fremfor ASP er, at man har adgang til alle mulighederne i Java – og det er væsentligt flere end scriptsprogene i ASP giver mulighed for. Derudover kan man uden videre bruge eksisterende Java-klasser og JavaBeans direkte fra JSP-siderne – der skal ikke foretages konfiguration for at indlæse dem. Dette er i skarp kontrast til ASP, hvor man skal bruge COM-objekter, hvis man vil foretage ting, der ikke umiddelbart er mulige fra scriptsproget.

En anden fordel ved at anvende JSP er, at det – ligesom Java selv – er platformsuafhængigt. Selvom JSP er en meget ny teknologi, er der allerede nu mange web-server-producenter, der lover at understøtte den. Derudover er det let selv at udvide en eksisterende web-server med JSP-funktionalitet. Man behøver simpelthen bare at starte et program på web-serveren. Blandt de web-servere, der kommer til at understøtte JSP, er Apache, der er den mest brugte web-server på Internet.

Der er imidlertid også en række ulemper ved JSP. Den største er nok, at det ikke er særligt let at gå til, hvis man ikke allerede har kendskab til Java.

En anden ting, man skal være opmærksom på, er, at JSP er en relativt ny teknologi. Selvom JSP er baseret på de samme principper som ASP, der efterhånden er forholdsvis gennemprøvet, har systemet stadig en række børnesygdomme, der skal kureres.

Web-sted: java.sun.com/products/jsp

 

PHP3

PHP3 blev udviklet før ASP og var udsprunget af en desperat web-designers ønske om at lave noget avanceret på en måde, der var simplere end CGI. Han opfandt en teknologi, som han kaldte Personal Home Page Tools. Navnet blev senere ændret til Professional Home Page Tools.

Princippet i PHP3 er stort set det samme som i ASP, og den væsentligste forskel er, at PHP3 er taget ud af Unix-miljøet, hvor ASP er taget ud af Windows-miljøet. Det betyder, at de sprog, der kan anvendes sammen med ASP er de, som normalt anvendes fra Windows – VBScript og JavaScript – mens PHP3 i stedet anvender de sprog, der er kendte i Unix – Perl, Python og lignende.

PHP3 er på nuværende tidspunkt ikke ligeså udbredt som ASP, der anvendes på en lang række af de største web-steder på Internet.

Web-sted: www.php.net.

Afrunding

I dette kapitel er den historiske baggrund for udviklingen af ASP blevet gennemgået. Derudover er der blevet gennemgået nogle grundlæggende ting, det er godt at have på plads, før man begynder at udvikle ASP. Det er også blevet beskrevet i hvilke tilfælde, man med fordel kan anvende nogle af de visuelle ASP-værktøjer, der findes på markedet.