Oggetto Server: Transfer

In questa lezione osserviamo alcuni tra i metodi più interessanti dell'oggetto Server di ASP.

MapPath

Iniziamo con il metodo MapPath. Grazie ad esso, a partire dal percorso "virtuale", relativo alla root (/) del sito web, possiamo ottenere il percorso "reale" (anche detto full path name) ovvero la posizione di un file o una cartella sul server.

Per percorso "virtuale" possiamo intendere la parte che segue il dominio in un indirizzo Web:

http://www.mio_sito.it/percorso/virtuale.gif

Il percorso fisico invece è proprio la posizione del file sul file system del server. Proviamo ad invocare MapPath scrivendo:

Response.Write(Server.MapPath("/percorso/virtuale.gif"))

otteniamo qualcosa di simile a:

c:inetpubwwwrootmio_sitopercorsovirtuale.gif

Server.Transfer vs Response.Redirect

Il metodo Transfer è stato introdotto con ASP 3.0 e, come si intuisce dal nome, serve a trasferire il controllo ad una nuova pagina. Se torniamo indietro di qualche lezione, lo possiamo assimilare al metodo Redirect dell'oggetto Response.

La differenza tra i due però è sostanziale

• Response.Redirect produce il caricamento di una nuova pagina, cambiando del tutto il contesto e anche l'url visualizzato nella barra indirizzi del browser
• Server.Transfer invece trasferisce il controllo del flusso dell'applicazione alla nuova pagina ma mantenendo lo stesso contesto della richiesta precedente, questo ad esempio significa che non cambia l'url nella barra indirizzi

Quindi Response.Redirect richiede una nuova pagina, la Server.Transfer richiede l'esecuzione della risorsa e la restituisce sulla pipeline originale, facciamo un esempio supponiamo di avere queste istruzioni:

<%
   Response.Write "Sono prima del Response.Redirect <br />"
   Response.Redirect "pagina_di_destinazione.asp" 
   Response.Write "Sono dopo il Response.Redirect <br />"
%>

<%
   response.write "Pagina di destinazione <br />"   
%>

Quando lanciamo Default.asp, il browser viene repentinamente dirottato su pagina_di_destinazione.asp (quindi nell'url nella barra indirizzi) e otteniamo la scritta:

Pagina di destinazione

Se invece utilizziamo Server.Transfer:

<%
   Response.Write "Sono prima del Server.Transfer <br />"
   Server.Transfer "pagina_di_destinazione.asp" 
   Response.Write "Sono dopo il Server.Transfer <br />"
%>

Vediamo che nella barra indirizzi non viene modificato l'url, che rimane fisso su Default.asp, ma che il controllo del flusso delle istruzioni è stato ceduto alla nuova pagina. Otteniamo:

Sono prima del Server.Transfer
Pagina di destinazione

Execute

Altro metodo molto interessante, soprattutto per integrare parti di codice scritti su pagine differenti, è Execute. Come suggerisce il nome, questo metodo permette di eseguire il codice scritto su un'altra pagina come se fosse presente nella pagina corrente.

Riprendendo l'esempio precedente, vediamo cosa accade se modifichiamo Default.asp:

In quella sede, avevo anticipato che ne esisteva una variabile più intelligente. Eccola. Questa variabile si presenta grazie al server.transfer. Adesso vi mostro la sintassi del metodo:

<%
   Response.Write "Sono prima del Server.Execute <br />"
   Server.Execute "pagina_di_destinazione.asp" 
   Response.Write "Sono dopo il Server.Execute <br />"
%>

Il server stampa la prima riga, esegue il contenuto della pagina esterna e torna sulla pagina a stampare la seconda riga, in modo assimilabile a quanto facciamo con include:

Sono prima del Server.Execute
Pagina di destinazione
Sono dopo il Server.Execute