Vevsteder

Websites eller vevsteder er i dagens situasjon ikke noe entydig og lett definert begrep. På et overordnet nivå kan vi kanskje si at det er en gruppe vevsider som har en eller annen innbyrdes sammenheng og organisering. Svært ofte er sidene ordnet etter en hierarkisk modell. Hva er en vevside i et slikt resonnement? Vi vet at det kan være en ferdiglagde side som vi henter opp ved en URL. Det kan også være en URL til et program som skaper en side når den etterspørres. Videre kan vi fort få problemer med å avgrense et vevsted, siden det i prinsippet ikke er noen grenser for hva vi lenker til.

En kategorisering

Som et forslag til en slags enkel oversikt over litt av de mest typiske trekkene ved web-teknologien skal jeg nedenfor forsøke å rydde litt i noen begreper. Dette er ikke noe forsøk på å lage noe som er riktigere enn mange andre forklaringer, men kun et ordningsforsøk som kan hjelpe oss å forholde oss til den kompleksiteten denne teknolgien inneholder.

Jeg vil først forsøke å bygge et resonnemnet med utgangspunkt i en enkel figur. Deretter kan vi plukke det fra hverandre med å se på en del mekanismer som gjør det litt mer komplisert. Mitt utgangspunkt er en tradisjonell programmerers utgangspunkt.

Faste sider

De sidene du leser nå er faste sider. Vi ser at de har .html som sidetype og de hentes av nettleseren som de er. De er bygget uavhengig av lesetidspunktet. Det betyr ikke at vi ikke kan bruke effektive verktøy for å bygge sidene. I dette tilfellet er verktøyet WXT brukt, se WXT 6.

Faste sider betyr at sidene ikke gjenspeiler dynamiske endringer med høyere frekvens enn byggefrekvensen. Bygging av sidene er en manuell eller preprogrammert, tidsbestemt handling.

Dynamiske sider

Dynamiske sider finnes i prinsipp ikke. De lages når de etterspørres. I motsetning til faste sider reiser dette tre viktige spørsmål:

1. Hvilket verktøy skal vi bruke for å lage sidene.
2. Hva slags datastruktur skal vi bruke for å lagre datakildene
3. Hvordan skal vi lagre strukturen i vevstedet

Med valg av verktøy mener jeg i praksis vilket programmeringsspråk vi skal bruke og hvordan dette programmeringsspråket samhandler med de strukturelle delene av en vevside. Løsningen på dette er grunnlaget for skillet mellom ISAPI og CGI.

I motsetning til faste sider som er ferdige med innhold, stilsett og det hele, må dynamiske løsninger ha en mekanisme for å hente innhold og sy dette sammen med stilinformasjon og sidestruktur på en effektiv måte. Databaser og XML-strukturer er kandidater for dette. Det er ikke tilfeldig at Microsoft har pakket begge teknologiene inn i et dataccess-bibliotek.

Lagring av strukturen til selve vestedet er en problemstilling for seg. Vi vet at vi må ha oversikt over dette når vi lager, programmerer, innholdsfortegnelser og menyer. Vi vil finne ulike mekanismer for å ivareta dette.

CGI

Common Gateway Interface

CGI er den mest grunnleggende teknologien i web løsninger. Det går i korthet ut på at vi sender en forespørsel, med eller uten parametere, til en server som starter et program. Dette programmet leser forespørselen, forbereder et svar og sender svaret tilbake.

Programmet kan lages i et vilket som helst programmeringsspråk som kan kjøre på serveren. Det er programmet som har kontrollen. Dersom vi skal returnere en vevside, må denne konstrueres i sin helhet av programmet. Hvorvidt siden bygges opp ved hjelp av masterfiler som modifiseres, eller ved rene tekstkonstanter i programmet er uvesentlig, sett fra et prinsippielt synspunkt. Det samme gjelder om innholdet hentes fra databaser eller XML-strukturer.

SAPI

Server Application Programming Interface

SAPI er et generisk navn på API'er som knytter server tjenester tettere til internett kommunikasjon. En rekke moduler "ligger klare" og tar i mot henvendleser. ISAPI (Internet Server API) er Microsofts versjon. Andre leverandører enn Microsft har tatt ISAPI i bruk. De programmeringsverktøyene som dominerer tradisjonelle løsninger basert på ISAPI/SAPI-teknologeien er alle P-språkene, ASP,PHP, JSP.

Prinsippielt har de en arbeidsdeling mellom data og program som er slik at vi bruker programmeringsspråket, skriptspråket, til å fylle ut en vev-side. Dette i motsetning til en tradisjonell CGI-løsning der programmet har hele ansvaret for å generere siden.

ASPX

ASPX-løsninger skiller seg ikke prinsippielt fra ASP-,PHP-,JSP-løsninger, men for en tradisjonell programmerer er det en viktig forskjell. Koplingen til vevsiden er (kan være) en enkelt linje som angir koden som skal kjøres. Denne koden kan vi skrive i et moderne kraftig programmeringsspråk, C#. Det innebærer at vi har langt større programmeringskraft enn det vi har med nnP-skriptene. Vi har et stort bibliotek og vi kan få tak og manipulere elementer på vevsiden med et rent grensesnitt.

Sidebegrepet

Det bildet vi har tegnet ovenfor er selvsagt sterkt forenklet. Vi kan lage vevsteder som er kombinasjoner av faste og dynamiske sider.

Videre vet vi at vi kan lage vevsider som er delt inn i komponenter med hver sin kilde. Verktøyene er frames og iframes.

Videre vet vi at AJAX-teknologien gjør det enkelt å lage dynamiske elementer på faste sider. Det vil si at vi interaktivt henter innhold som erstatter deler av en side.

Layout og struktur

Alle som har arbeidet med vevstder med at antall sider som overstiger en handfull vet at Det er viktig å ha en plan og gjøre det som i noen sammenhegner omtales som "separation of concern" (Cocoon). Det vil si at vi må være istand til skille og bearbeide separat følgende komponenter i et vevsted:

• Vevstruktur. Altså hvordan sidene forholder seg til hverandre. Hvilken side som lenkes til hvem. Siden vi svært ofte har en eller annen form for hierarkisk løsning er en XML-beskrivelse en nærliggende løsning.
• Sidestruktur. Altså hvordan de enkelte sidene er bygget opp, hvor er menyene osv. Vi trenger en eller annen form for template eller masterpage. I et ikke-trivielt vevsted vil vi trenge flere templates.
• Stiler. Altså hvordan komponentene på sidene skal se ut. Dette realiserer vi med stilsett. Vi skal altså kunne endre f.eks. skriftstørrelsen på et helt vevsted ved å gjøre en endring i ett stilsett.
• Innhold. Selve innholdet på sidene må kunne endres uten at vi må endre sidestruktur og stilsett. Det inne bærer for det føsrte at vi må ha en fleksibel og robust sidelayout og vi må ha en standardisert måte å representere og bruke innholdsdata på.

.Net har komponenter som kan hjelpe oss i en slik dekomponering av arbeidet. Dels er det snakk om generelle mekanismer (stilsett) og dels er det snakk om spesielle klasser for vevstedstruktur og templates.