Guide

ASP, Server Side Include

Come sostituire include di tipo File con include di tipo Virtual

Sui server con sistema operativo Windows Server (quindi con server web IIS), negli script ASP le istruzioni include e il metodo MapPath dell'oggetto Server utilizzano esclusivamente percorsi virtuali assoluti la cui radice (/) corrisponde alla root web del sito.
Se, però, gli script utilizzano istruzioni include di tipo file o, in generale, percorsi fisici relativi (che iniziano con ../), può essere importante sapere come trasformare tali istruzioni in modo adeguato al server web IIS.

In termini di URL virtuali assoluti, se il sito è, ad esempio, nomedominio.it, la radice del sito (che si indica con il carattere /) corrisponde all'indirizzo http://www.nomedominio.it, cioè il percorso virtuale assoluto per la radice del sito è il solo carattere /; ponendo, quindi, il carattere / all'inizio di ciascun percorso sarà possibile evitare di ripetere negli url il testo http://www.nomedominio.it ed i persorsi risulteranno estremamente più semplici. Ad esempio:

URL: http://www.nomedominio.it/connessioni/connessione.asp
percorso virtuale: /connessioni/connessione.asp
include: <!-- #include virtual="/connessioni/connessione.asp" -->
Server.MapPath: Server.MapPath("/connessioni/connessione.asp")>

URL: http://www.nomedominio.it/variabiliglobali.asp
percorso virtuale: /variabiliglobali.asp
include: <!-- #include virtual="/variabiliglobali.asp" -->
Server.MapPath: Server.MapPath("/variabiliglobali.asp")

URL: http://www.nomedominio.it/testi/cultura/dolcestilnovo.html
percorso virtuale: /testi/cultura/dolcestilnovo.html
include: <!-- #include virtual="/testi/cultura/dolcestilnovo.html" -->
Server.MapPath: Server.MapPath("/testi/cultura/dolcestilnovo.html")

In questo modo, le istruzioni di include o Server.MapPath rimarranno inalterate in qualsiasi posizione del sito vengano eseguite; quindi, qualora fosse necessario spostare uno script asp o html che contiene istruzioni include di tipo virtual, non sarà più necessario modificare il percorso dell'include.

Analogamente ed in generale, grazie al percorso virtuale assoluto sarà possibile inserire un'istruzione di include all'interno di uno script indipendentemente dalla posizione di questo script.

Esempio 1

Le istruzioni di include sono utilizzate per inserire lo stesso codice in più pagine di un sito e rendere così più facili le modifiche (perché centralizzate in un unico file). In questo esempio si suppone di includere un file che contiene il codice dell'header html (generalmente comune a tutte le pagine), in qualsiasi pagina asp o shtml del sito stesso.

Supponiamo di voler includere nello script http://www.nomedominio.it/index.asp il codice html che il cui url è: http://www.nomedominio.it/layout/header.html.

Se si utilizza un'istruzione include di tipo file nello script index.asp, quindi:

<!-- #include file="layout/header.html" -->

Utilizzando, invece, un'istruzione include di tipo virtual, nello script index.asp si aggiunge:

<!-- #include virtual="/layout/header.html" -->

Come si può notare, tra il percorso utilizzato nell'istruzione include virtual e quello dell'istruzione include file, l'unica differenza è la presenza del carattere "/".

Procediamo con l'analisi.

Supponiamo di voler includere nello script http://www.nomedominio.it/guestbook/index.asp il contenuto del file che si trova all'url http://www.nomedominio.it/layout/header.html.

Se si utilizza un'istruzione include di tipo file, bisogna aggiungere nello script index.asp la riga:

<!-- #include file="../layout/header.html" -->

Utilizzando, invece, un'istruzione include di tipo virtual, bisogna aggiungere nello script index.asp la riga:

<!-- #include virtual="/layout/header.html" -->

Esempio 2

Questo esempio mostra in maniera evidente come l'istruzione include di tipo virtual rimanga invariata indipendentemente dalla posizione dello script che la utilizza; l'istruzione include di tipo file, contenendo un percorso relativo, deve essere invece modificata dipendentemente dalla posizione dello script che la utilizza.

Anche nel caso di Server.MapPath il discorso è del tutto analogo.
Supponiamo di voler leggere il file di testo posto all'url http://www.nomedominio.it/contenuti/listino.txt, usando la libreria vbscript Scripting.FileSystemObject.

Tale libreria ha bisogno del percorso fisico del file, che in ASP si ricava utilizzando appunto il metodo MapPath dell'oggetto Server.

Volendo leggere il file http://www.nomedominio.it/contenuti/listino.txt dallo script http://www.nomedominio.it/mostralistino.asp, le righe di codice da utilizzare sono le seguenti:

percorso relativo
percorsofile = Server.MapPath("contenuti/listino.txt")
Set oggettoFileSystem = Server.CreateObject("Scripting.FileSystemObject")
Set oggettoFile = oggettoFileSystem.OpenTextFile(percorsofile, 1)

percorso virtuale
percorsofile = Server.MapPath("/contenuti/listino.txt")
Set oggettoFileSystem = Server.CreateObject("Scripting.FileSystemObject")
Set oggettoFile = oggettoFileSystem.OpenTextFile(percorsofile, 1)

Lunica differenza tra i due percorsi è il carattere "/".

Consideriamo il caso seguente.

Si vuole leggere il file http://www.nomedominio.it/contenuti/listino.txt dallo script http://www.nomedominio.it/gadget/italiano/mostralistino.asp.

Le righe di codice da utilizzare sono le seguenti:

percorso relativo
percorsofile = Server.MapPath("../../contenuti/listino.txt")
Set oggettoFileSystem = Server.CreateObject("Scripting.FileSystemObject")
Set oggettoFile = oggettoFileSystem.OpenTextFile(percorsofile, 1)

percorso virtuale
percorsofile = Server.MapPath("/contenuti/listino.txt")
Set oggettoFileSystem = Server.CreateObject("Scripting.FileSystemObject")
Set oggettoFile = oggettoFileSystem.OpenTextFile(percorsofile, 1)

Analogamente a quanto osservato per le istruzioni include, anche nel caso di Server.MapPath il percorso virtuale rimane invariato indipendentemente dalla posizione dello script che lo utilizza. Indicare dei percorsi relativi comporta il dover ricavare un nuovo percorso ogni volta che si richiama un file da una posizione differente, aumentando la probabilità di commettere errori nella stesura del codice.