- systemudvikling, programmering, softwareudvikling

Èn metode (hvortil jeg selv har fundet på navnet - det er altså ikke en officielt anerkendt måde at betegne denne metode) til strukturering af sider i websites kan sammenlignes lidt med en kinesisk æske, nemlig hvor man har et hovedlayout, som danner ramme om alle sider på et site (eller en større delmængde af et site). Inde i denne ramme kan der så være en mængde dellayouts, som benyttes i forskellige scenarier, alt efter hvilken side man er på i sitets struktur.

Dette koncept kan man så gå mere eller mindre i ekstremer med, jeg vil lade det være op til den enkelte at beslutte hvornår man har fundet et passende niveau af indkapsling og opdeling af sit sites elementer.

Jeg opfatter i øvrigt et element som en kasse der har en mere eller mindre afgrænset og ofte isoleret funktionalitet i et større sammenhæng, f.eks. en nyhedsoversigt, et galleri eller måske et lille internt postsystem. Som det fornemmes, kan det altså være alt lige fra små dimser til store subsystemer. Det jeg bare gerne vil opnå med min opdeling, er at jeg kan isolere min funktionalitet til nogle mindre enheder, som er lettere at overskue og vedligeholde og som kan udskiftes uden jeg skal til at trevle hele mit website's kode op for at få frigjort mit site fra komponenten/funktionaliteten.

Nu er mit fokus umiddelbart på ASP 3.0, men denne metode kan sagtens overføres på andre teknologier, sålænge disse er i stand til at isolere komponenter. I ASP.NET kunne en løsning f.eks. være at lave en web user control, andre teknologier tilbyder måske includes eller andre muligheder for at linke komponenter ind i en webside... det må være op til dig at gennemskue, hvordan din teknologi kan løfte denne opgave.

Som sagt er det ASP 3.0 der er i fokus her og i ASP 3.0 findes der et par metoder på serverobjektet, som kan hjælpe mig med at isolere mine komponenter, nemlig Server.Execute og Server.Transfer. Umiddelbart vil jeg benyttes Server.Execute, da den bringer mig tilbage til det sted hvor den blev aktiveret (dvs. kodelinien umiddelbart efter), hvilket, groft sagt, svarer til et funktionskald i proceduralt programmeringssprog.

Jeg vil ikke komme så meget ind på hvordan man benytter Server.Execute ud over, at den kaldes med en relativ sti til den fil man gerne vil have udført på det pågældende sted i sin kode. Stien kan være dynamisk og det er en af de egenskaber der gør den brugbar ifht. dynamisk layout på et website.

Modparten til Server.Execute er (tillempet) #include file eller #include virtual, men begge disse metoder er noget som "udføres" (dvs. indholdet af en inkluderet fil indsættes på den plads hvor #include-direktivet står i koden) af ASP's prækompiler (eller rettere ServerSide Include = SSI) og kan derfor ikke ændres af ASP-kode. ASP-kode udføres først efter ASP-prækompileren har kørt sine opgaver. I realiteten ser scriptfortolkeren ikke #include-direktivet, så det giver ikke mening at prøve at generere #include-direktiver i scriptkoden. Scriptfortolkeren ser et samlet script, som er summen at alle inkluderede filer på en side og forholder sig kun til dette. Et eksempel på dette kunne være:

default.asp (hovedsiden)

<!-- #include file="funktioner.asp" -->


<html>
<head><title>test af include</test></head>
<body><p><%=testInclude()%></p></body>
</html>

funktioner.asp (en inkluderet side)

<%
function testInclude()
  Response.Write "Vi tester en funktion i en include-fil"
end function
%>

Den side som scriptfortolkeren får leveret af ASP, ser således ud:

<%
function testInclude()
  Response.Write "Vi tester en funktion i en include-fil"
end function
%>


<html>
<head><title>test af include</test></head>
<body><p><%=testInclude()%></p></body>
</html>

Der er altså ikke nogen spor af et #include-direktiv...

ANYWAY! For at gøre en kort historie lang... så vil jeg herefter prøve at eksemplificere princippet for den Kinesiske æske.

Princippet er ret simpelt, nemlig hav en hovedside som på grundlag af nogle regler (f.eks. en parameter i querystring) beslutter hvilke elementer siden skal indeholde. Hvis det skal være rigtig fancy, så kan hvert element selv fungere som hovedsiden og dermed selv bestå af flere elementer (baseret på f.eks. parametre i querystring). På denne måde kan hver side sammensættes af et hierarki af komponenter i et relativt stort antal kombinationer...

En metode til at skabe denne dynamik i en side kunne være at lave en komponent, hvor reglerne for hvilke andre komponenter der skulle vises under en given omstændighed, var kodet ind i komponenten. Et eksempel herpå kunne se således ud:

<html>
<head>
  <title></tltle>
</head>
<body>  
<p>Først kan man skrive noget fast tekst - f.eks. en menu</p>
  <p>Så kan man gøre plads til en komponent</p>
<%
select case Request.QueryString("page") & ""
  case "1": Server.Execute "komponent1.asp"
  case "2": Server.Execute "komponent2.asp"
  case else: Server.Execute "dummykomponent.asp"
end select
%>
  <p>Så kan man jo slutte af med noget andet fast tekst,
    bare for at illustrere princippet...</p>
</body>
</html>

Denne metode er dog lidt statisk og den kræver at man ændrer i sine komponenter, hvis der opstår behov for at inføre nye komponenter i systemet. Det er, som udgangspunkt, ikke optimalt at skabe den slags afhængigheder i sine komponenter, så derfor abonnerer jeg selv på en mere fleksibel metode, som tillader mig kun at definere hvor i min komponent jeg vil have at andre komponenter kan vises. Hvilke komponenter der så vises er op til den person som sammensætter sitet. Se det er fleksibilitet!

Spørgsmålet er så, hvordan definerer jeg så min struktur!? Well, jeg kan da komme i tanke om et ret populært sprog som sætter mig i stand til at definere hierarkiske datastrukturer... det hedder XML (hvis du ikke havde luret det :)). Med XML kan jeg dels definere hvilke komponenter jeg har i mit system, dels definere hvordan de skal smaskes sammen når en specifik side forespørges (f.eks. vha. et id i querystring). Et eksempel på en sådan struktur kunne være:

<sitestruktur>
  <side id="1">    
    <kref kid="1" sid="1" orden="1">      
      <kref kid="2" sid="1" orden="1" />    
    </kref>
  </side>
  <komponent id="1" filnavn="komponent1.asp" />
  <komponent id="2" filnavn="komponent2.asp" />
</sitestruktur>

Forklaring:

Komponent-elementet fortæller systemet i hvilken fysisk fil komponenten er defineret. En komponent kan sagtens være andet en ASP-filer, men i så fald kan der være begrænsninger i muligheden for yderligere indlejring af komponenter (idet indlejringen af komponenter kræver at Server.Execute kan kaldes - og det kan den kun i ASP-sider).

Side-elementet definerer komponenthierarkiet for en side, hvor hierarkiet defineres igennem kref-elementerne. Når et kref-element er indlejret i et andet kref-element, betyder det, at det indlejrede kref-element skal vises et eller andet sted i det indlejrende kref-element. I ovenstående eksempel betyder det, at komponent2.asp skal vises et eller andet sted i komponent1.asp. At det var komponent2.asp der skulle indlejres i komponent1.asp, fandt jeg frem til via kref-atributten kid, som peger på den komponent hvis id = kid...

Hm!? Hvordan får jeg så rent faktisk vist mine komponenter i mine sider? Det kan gøres på flere måde, personligt har jeg valgt at lave et par funktioner som kan læse i XML-filen, hvilke komponenter der skal indsættes i den givne komponent på den givne side og så kalde disse komponenter vha. Server.Execute. Jeg har valgt at kalde min funktion for visKomponent. Et konkret eksempel på hvordan min komponent kommer til at se ud kunne være:

<!-- #include virtual="/funcs.asp" -->
<html>
<head>
  <title></tltle>
</head>
<body>
  <p>Først kan man skrive noget fast tekst - f.eks. en menu</p>
  <p>Så kan man gøre plads til en komponent</p>
  <% visKomponent %>
  <p>Så kan man jo slutte af med noget andet fast tekst, bare for at
    illustrere princippet...</p>
</body>
</html>

Som det ses, er siden nu blevet noget simplere, idet logikken til at beslutte hvilken komponent der skal vises og indsætte den, er flyttet væk fra selve siden (over i funcs.asp). Det betyder at jeg kun skal "røre ved" komponenten, hvis der skal ændres i designet eller tilføjes yderligere funktionalitet - sådan som det bør være.

Pt. har min metode umiddelbart en ulempe, nemlig at jeg kun kan indsætte komponenter et sted på min side. Det synes jeg ikke er særlig hensigtsmæssigt, så derfor indfører jeg et nyt koncept, som hedder "sektioner". Med en sektion menes der blot et område i komponenten der er afsat til at vise andre komponenter. Dette stiller dog nogle flere krav til min XML-struktur, såvel som min funktion til at vise komponenter (visKomponent), nemlig at jeg kan specificere hvilke komponenter der skal vises i hvilke sektioner (ellers vil alle komponenter i en komponent, jo blive vist i alle sektioner!), samt at min funktion er i stand til at skelne mellem disse sektioner. Hvis man kigger på XML-strukturen jeg definerede tidligere, kan man se at hver kref-element har en atribut som hedder sid og det er sektionsid'et. Nu kan jeg gruppere mine komponenter i de forskellige sektioner og dermed bestemme hvor på siden komponenten skal vises - det er jo rart nok. Min side kan så ændres til at se således ud:

<!-- #include virtual="/funcs.asp" -->
<html>
<head>
  <title></tltle>
</head>
<body>  
  <p>Først kan man skrive noget fast tekst - f.eks. en menu</p>
  <p>Så kan man gøre plads til en komponent</p>
  <% call visKomponent(1) %>  
  <p>Så kan man jo slutte af med noget andet fast tekst, bare for at
    illustrere princippet...</p>
  <% call visKomponent(2) %>
</body>
</html>

For illustrationens skyld har jeg tilføjet et kald mere til visKomponent, hvor jeg angiver sektionsnummeret hvortil jeg gerne vil have vist komponenter i den pågældende komponent. For kompletheden skyld illustreres en XML-struktur som resulterer i en side med komponent i begge sektioner:

<sitestruktur>
  <side id="1">
    <kref kid="1" sid="1" orden="1">        
      <kref kid="2" sid="1" orden="1" />  
      <kref kid="3" sid="2" orden="1" />
    </kref>  
  </side>
  <komponent id="1" filnavn="komponent1.asp" />
  <komponent id="2" filnavn="komponent2.asp" />  
  <komponent id="3" filnavn="komponent3.asp" />
</sitestruktur>

Som det ses er der kommet et kref-element mere inde i det yderste på side 1, med et nyt sektionsid.

En anden feature som kunne være rar, var at der kunne stoppes flere komponenter ind i samme sektion. Også dette er der gjort klar til i XML-strukturen (faktisk er det ikke et teknisk krav, men nok et uundgåeligt praktisk krav), nemlig via kref-atributten orden. Denne atribut skal muliggøre at komponenterne kan vises i den ønskede rækkefølge i den givne sektion på siden. Igen er dette noget som funktionen visKomponent skal håndtere. Der sker i dette tilfælde ikke nogen ændringer i måden hvorpå funktionen kaldes, da denne udvidelse kun har konsekvenser for implementeringen af funktionen. Det er blot et spørgsmål om, hvordan kref-elementerne læses/behandles når de er læst fra XML-strukturen.

Sidst opdateret: 10-09-2008 19:02:23

Tilmeld link | Tilføj Link | Tilføj Link | @-begynder
Erklæring om beskyttelse af personlige oplysninger