|
ASP: la guida introduttiva
Capitolo 15 - L'oggetto built-in Application
15.0 Scopo
e utilizzo dell'oggetto Application
15.1 Metodi
e collezioni dell'oggetto Application
15.2 I
metodi Lock e UnLock
15.3 Un
pratico esempio
15.0 - Scopo e utilizzo dell'oggetto Application
Application,
quinto ed ultimo degli oggetti built-in di ASP, permette di
gestire informazioni condivise tra tutti gli utenti connessi ad
un sito. La comprensione dell'utilizzo delle variabili
Application è molto semplice se già si hatà con le
controparti Session (cfr.
Capitolo 13). La sintassi che consente l'attivazione di una
variabile di applicazione, infatti, è identica a quella che si
utilizza di norma per le variabili di sessione o variabili
utente:
Application("nomevariabile") = contenuto;
Anche il recupero del valore memorizzato conserva la stessa
semplicità del caso precedente:
<%=Application("nomevariabile")%>
I
dati che possono essere memorizzati in variabili di questo tipo,
inoltre, sono i tipi semplici supportati dai linguaggi di
scripting, primi fra tutti quindi i valori numerici e le
stringhe. Non possono essere assegnati a delle variabili di
applicazione i riferimenti ad oggetti propri del linguaggio di
scripting usato (come d'altronde non è possibile farlo per le
variabili Session), in quanto tali oggetti vengono distrutti
automaticamente al termine dell'esecuzione del codice. Tuttavia
possono essere inseriti in Application riferimenti ad oggetti
ActiveX di varia natura, tra i quali spicca ad esempio ADO. Non
sempre è conveniente, però, ricorrere a questa tecnica. Per il
momento ci limiteremo ad osservare l'uso dell'oggetto
Application rispetto ai tipi di dati primitivi.
Si è osservato quale grande analogia corra tra gli oggetti
Session e Application, ma non si è ancora precisato in cosa
differiscano. Le variabili di applicazione permettono la
condivisione di dati tra gli utenti, pertanto là dove le
variabili Session sono distinte e separate per ogni utente
connesso, le variabili Application sono uniche per tutti. Questa
peculiarità rende le variabili di applicazione utilissime ogni
qual volta un'informazione debba essere velocemente condivisa
tra tutte le persone collegate ad un sito. E' il caso dei famosi
contatori di utenti connessi, oppure quello delle chat per
interfaccia Web, dove i messaggi postati dai partecipanti
vengono inseriti in variabili di questo tipo per divenire
fruibili pubblicamente. In poche parole inserire il valore
"ciao" all'interno di una variabile Application è come
inserirlo, ad esempio, in un file di testo. Il file di testo,
infatti, è unico, e qualsiasi utente vorrà leggerlo in un dato
momento vi individuerà lo stesso contenuto. La differenza
sostanziale tra le variabili Application e i dati conservati
fisicamente sul disco è comunque lampante, e quello fornito
vuole essere solo un aiuto alla comprensione. Per prima cosa
l'accesso ai contenuti di una variabile di questo tipo è molto
più veloce, e non si basa sull'utilizzo di componenti esterni da
inizializzare ogni volta. Inoltre i file di testo (o i database
gestiti da ADO) conservano i dati perennemente, almeno fino a
quando non si comunica esplicitamente la loro eliminazione,
mentre le variabili Application sono mantenute in memoria dal
Web server, e per questo motivo il loro contenuto va perso ogni
volta che un reset viene eseguito. Un'altra differenza
essenziale che corre tra Session e Application è che le
variabili di quest'ultimo tipo non scadono dopo un determinato
tempo di inattività, ed il loro ciclo vitale si conclude solo
quando vengono esplicitamente distrutte, o con il reset del
server, come già è stato detto. In definitiva, quindi, l'oggetto
built-in Application è la maniera migliore per condividere dati
semplici ed immediati, la cui conservazione perenne non sia
comunque richiesta.
15.1 - Metodi e collezioni dell'oggetto Application
L'oggetto built-in Application mette a disposizione dello
sviluppatore due metodi e due collezioni, che verranno ora
passati velocemente in rassegna. I paragrafi successivi saranno
destinati ad approfondimenti ed esempi in merito.
|
Metodi |
|
|
|
|
Lock |
Impedisce ad altri script di modificare il contenuto delle
variabili Application. |
|
UnLock |
Consente ad altri script di modificare il contenuto delle
variabili Application. |
|
|
|
|
Collezioni |
|
|
|
|
Contents |
Collezione di tutte le variabili Application attive sul
server. |
|
StaticObjects |
Collezione di tutti gli oggetti che hanno ricevuto lo scope
"application". |
|
|
|
15.2 - I metodi Lock e UnLock
Il
fatto che le variabili Application presentino natura globale nel
confronto di tutti gli utenti espone le applicazioni Web basate
su di esse a potenziali problemi. Essendo ogni valore condiviso
è probabile che più di uno script, la cui richiesta di
esecuzione è stata lanciata da utenti differenti, tenti di
modificare il contenuto di una variabile Application nello
stesso istante. Questo è fonte di grandi problemi, in quanto si
rischia la perdita e la malformazione dei dati precedentemente
accumulati. Per ovviare a tale inconveniente sono stati
introdotti i metodi Lock e
UnLock, grazie ai quali solo uno
script alla volta ha accesso in scrittura sui valori di
applicazione. La prassi generale che si deve seguire quando si
inseriscono valori condivisi, quindi, ricalca il seguente caso:
Application.Lock();
Application("nomevariabile") = contenuto;
Application.UnLock();
Nel
momento in cui viene lanciato Lock, si impedisce automaticamente
ad ogni altro processo di intervenire sul contenuto delle
variabili Application. L'unico script che può scrivere
tranquillamente dei valori al loro interno resta quello che ha
richiamato per primo il metodo. Tutti gli altri processi,
quindi, resteranno in attesa e, a turno, interverranno
singolarmente in scrittura nelle variabili di loro interesse.
Per questo motivo, ogni volta che il codice completi il lavoro
richiesto su delle variabili di applicazione, è bene lanciare il
metodo UnLock, che permetterà agli altri processi di terminare
l'attesa e compiere il loro dovere.
15.3 - Un pratico esempio
Verrà ora analizzato un esempio tanto buono dal punto di vista
didattico, quanto inutile da quello delle applicazioni concrete.
Sarà realizzata una pagina ASP che permetterà ad un utente
qualsiasi l'inserimento di un messaggio di testo all'interno di
Application. Ogni volta che un nuovo messaggio sarà postato
questo rimpiazzerà il precedente. In contemporanea un secondo
script mostrerà in output il messaggio correntemente accumulato
nella variabile utilizzata.
Il documento (pagina1.asp) utile
per l'inserimento di un messaggio è il seguente:
<%@ LANGUAGE = JScript %>
<%
var msg = String(Request.Form("msg"));
if (msg!="undefined") {
Application.Lock();
Application("messaggio") = msg;
Application.UnLock();
Response.Redirect("pagina2.asp");
}
%>
<html>
<head>
<title>Inserisci il tuo messaggio!</title>
</head>
<body>
<form method="post" action="pagina1.asp">
<input type="text" name="msg" value="">
<input type="submit" value="VAI!">
</form>
</body>
</html>
La
visualizzazione sul browser (pagina2.asp)
è estremamente semplice:
<%@ LANGUAGE = JScript %>
<html>
<head>
<title>Ecco il messaggio!</title>
</head>
<body>
<p>Messaggio corrente: <b><%=Application("messaggio")%></b></p>
</body>
</html>
Ogni
volta che un utente qualsiasi si servirà di pagina1.asp per
esternare un proprio pensiero, tutto il resto del mondo potrà
venirne a conoscenza collegandosi a pagina2.asp!
Nel corso del prossimo capitolo sarà preso in esame un uso molto
più concreto ed utile delle variabili Application. |