|
| Az
ASP objektummodell |
|
Az .asp oldalak
programozását, a HTTP kommunikáció, a webkiszolgáló
egyes szolgáltatásainak elérését külön
objektummodell segíti. Az ASP objektummodelljének
minden elemét elérhetjük az .asp oldalak kódjaiból.
Az ASP
objektummodell és annak elemei:
Az ASP
objektummodellje
Ha a tranzakciós műveletekhez
használt ObjectContext objektumot nem számítjuk, az
objektummodell hat (Windows NT 4.0-n öt) objektumból
áll. A Windows 2000-ben megjelent új objektum az
ASPError, ami egy bekövetkezett hiba leírását
tartalmazza, az .asp-be ágyazott, saját hibakezelést
segíti.
A Server
objektum magát az IIS-t képviseli, néhány
kiszolgálószintű beállítással és szolgáltatással.
Az Application
objektum egy webalkalmazást jelképez. A
webalkalmazás különálló egység, általában egy
könyvtárban és annak alkönyvtáraiban található
.asp kódok összessége, közös objektumokkal és beállításokkal.
A Session
objektum egy ügyfél és a kiszolgáló között
“fennálló“ kapcsolatot, munkamenetet jelképez.
A “fennálló“ kapcsolatot azért írtuk így,
mert valójában nem egy kapcsolatról van szó. Az
IIS (a háttérben cookie-k segítségével) azonosítja
a felhasználót és a böngészőt, így az a böngésző
bezárásáig saját munkamenetébe térhet vissza.
A Request
objektum egy HTTP kérést jelképez, segítségével
kódból hozzáférhetünk a kérés minden eleméhez,
legyen az HTTP fejléc értéke, a böngészőben tárolt
cookie, vagy kérdőív tartama.
A Response
objektum pedig értelemszerűen a kérdésre küldendő
választ jelképezi. Természetesen a Response
objektum segítségével sem csak a válasz tartalmát,
hanem a HTTP protokoll fejrészét is kezelhetjük.
Egy IIS kiszolgálón
belül Server és ASPError objektumból
egy-egy létezik (utóbbi csak akkor érhető el,
ha hiba történt). Application objektum
minden webalkalmazás egyedi, globális objektuma, Session
objektum minden munkamenethez (ügyfélhez) egy
jön létre, egyidejűleg tehát több is létezhet. Request
és Response objektum pedig mindig az adott kérésre
és válaszra vonatkozik, újabb kérés esetén új példány
jön létre belőlük is.
A Server objektum
egy és oszthatatlan, és főleg kényelmi szolgáltatásai
miatt hasznos. Például ha ezt akarjuk a kiírni a
felhasználó böngészőjébe:
Vízszintes
vonal: <HR>
Ha ezt elküldjük a
böngészőbe, megjelenik a felirat, majd maga a vízszintes
vonal, hiszen a böngésző értelmezi a kódban található
HTML tagot. Ha a HTML elemet magát szeretnénk
megjeleníteni, a <
jelet < a >-t pedig >
entity-vel kell helyettesítenünk, tehát
valahogy így:
Vízszintes
vonal: <HR>
Ezen kívül még
sok más elemet is kódolni kell, nem beszélve a
speciális karakterekről. Szerencsére itt van a Server.HTMLEncode()
metódus, ami elvégzi
ezt a kódolást:
Response.Write(
Server.HTMLEncode("Vízszintes vonal: <HR>")
)
A HTMLEncode()
azért is nagyon fontos, mert okos használatával
elkerülhetjük az úgynevezett Cross Site Scripting
hibát. Ezt a fontos biztonsági hibát az okozza,
hogy egyes weboldalak (akár hibaüzenet formájában
is) válogatás nélkül, és kódolatlanul
visszaküldenek bizonyos, részükre előzőleg átadott
szövegrészeket.
A másik hasznos kódoló
metódus a Server.URLEncode(). Az URL-ekben nem
szerepelhet akármilyen karakter. Ami nem megszokott,
azt kódolni kell, általában %xx formában,
ahol xx a karakter hexadecimális kódja. (Még a
szóközt is helyettesítik, + jellel). Ha
URL-eket “építünk“ fel az ASP oldalainkban,
mindig használjuk ezt a metódust is
A Server.MapPath()
nagyon gyakran használt metódus. Arra való, hogy a
virtuális könyvtár- és fájlneveket (pl.
http://localhost/asp/default.asp) valós fájlnevekké
alakítsa (pl. C:\inetpub\wwwroot\asp\default.asp).
Ha a MapPath()-nek átadott virtuális név
“/“ vagy “\“ karakterrel kezdődik, akkor a
virtuális gyökérkönyvtártól, ellenkező esetben
pedig a hívás helyétől relatív fájlnevekkel
dolgozik (nem
lesz ugyanaz az eredménye tehát a “default.asp“
és a “/default.asp“ kódolásának, kivéve ha éppen
a gyökérkönyvtárban “állunk“).
Természetesen használhatók a “.“ és “..“
karakterek, azaz mozoghatunk a virtuális könyvtárak
által alkotott térben (a
“.“ az aktuális, a “..“ pedig a virtuális szülőkönyvtárra
mutat).
A Server.ScriptTimeOut
beállításával a scriptek időtúllépésének határát
növelhetjük meg (ez az érték nem lehet
alacsonyabb, mint a tulajdonságlapokon beállított
alapértelmezés), illetve kérdezhetjük le.
A Server.Transfer()
és a Server.Execute() két, az IIS5-ben új
szolgáltatás.
A Server.Transfer()
metódus egyszerűen átadja a vezérlést az alkalmazásban
található másik .asp kódnak. Minden átvett
adat megmarad, többek között a Request objektum
teljes tartalma is. A Server.Transfer(), amely
átadja a vezérlést a megadott oldalnak, kiválthatja
a Response Redirect() használatát, mert ehhez
nincs szükség a böngésző közreműködésére (és
így felesleges hálózati forgalomra). Természetesen
ez a megoldás csak akkor működik, ha webkiszolgálón
belül szeretnénk átirányítani a felhasználót.
A Server.Execute()
szubrutinszerűen végrehajtja az adott oldalt, majd a
végrehajtás befejezésre után visszatér az
eredetihez (mintha csak beszúrtuk volna a kódot).
Ennek előnye az <!--
include -->
kitétellel szemben az, hogy itt akár dinamikusan is
generálhatjuk a futtatandó oldal nevét.
Példa:
<%Server.Execute(”fejlec.htm”)%>
A Server.GetLastError()
visszaadja az utolsó ASP hibának adatait
tartalmazó ASPError objektum-ot.
A Server.CreateObject()
metódus létrehoz egy adott objektumot. Ha a létrehozott
objektum tartalmaz OnStartPage metódust, azt is meghívja.
Az objektum addig marad életben, amíg azt nem töröljük,
illetve az ASP oldal végrehajtása véget nem ér. Ha
az objektumot a Session vagy Application objektumba töltöttük,
akkor az objektum élete csak az adott Session vagy
Application objektum megszűnésekor ér véget.
Egy ASP alkalmazás
tulajdonképpen nem más, mint egy adott könyvtárban
és az összes alkönyvtárában található .asp
kódok halmaza. Azonban a valóságban ennél kicsit
bonyolultabb a helyzet, hiszen ha csak erről lenne szó,
nem lett volna szükség az alkalmazások létrehozására.
Az Application objektum segítségével a
felhasználók, kérések között adatokat oszthatunk
meg egyszerűen, anélkül, hogy például lemezre
kellene írnunk azokat. Az Application
objektumba írt információ mindaddig megmarad, amíg
az adott alkalmazást (gyakorlatilag az IIS-t) újra
nem indítjuk. Az ASP alkalmazás egy nagy globális
objektum a felhasználók kérései és az azokra
adott válaszok fölött.
| Az ASP munkamenet
– a Session objektum |
|
Az ASP munkamenet (Session)
célja teljesen hasonló, csakhogy az Application-nel
ellentétben nem felhasználók közötti, hanem egy
adott felhasználó műveletei fölötti globális
objektum. Azaz, számos Request
és Response fölött uralkodó objektum, ami
megmarad egészen addig, amíg a felhasználó el nem
hagyja a webhelyet, vagy be nem csukja a böngészőjét.
Természetesen Session
objektumból már nem csak egy van: ahány felhasználó,
annyi Session.
Az egyes munkamenetek azonosítása cookie-k segítségével
történik. Az (egyébként változó) ASPSESSIONIDxxxxxxxx
nevű cookie tartalmának segítségével az IIS egyértelműen
azonosítja a visszatérő böngészőt, és ugyanabba
a környezetbe helyezi (azaz,
mindenki az első látogatáskor részére létrehozott,
különbejáratú Session objektumba kerül).
Elbúcsúzhatunk a munkamenetektől, ha a felhasználó
böngészője visszautasítja a cookie-kat. Ha
ilyenkor mégis valami hasonló funkcionalitást
szeretnénk elérni, külső gyártó termékeit kell
használnunk, amelyek az URL-be ágyazva valósítják
meg a munkamenetek kezelését (az IIS-ben szűrő- ként
működve minden, az oldalakban található URL
hivatkozáshoz hozzáfűzik az azonosítót, míg a böngészőktől
érkező kérésekből kiszűrik azokat). Ez a megoldás
teljesen cookie-mentes, és elvileg minden böngésző
boldogul vele (csak
kicsit rondák lesznek az URL-ek).
|
|
|
