Modello di pagina ASP.NET 2.0

da Microsoft

In ASP.NET 1.x gli sviluppatori hanno avuto una scelta tra un modello di codice inline e un modello di codice code-behind. Il code-behind può essere implementato usando l'attributo Src o l'attributo CodeBehind della @Page direttiva. In ASP.NET 2.0 gli sviluppatori hanno ancora una scelta tra codice inline e code-behind, ma sono stati apportati miglioramenti significativi al modello code-behind.

In ASP.NET 1.x gli sviluppatori hanno avuto una scelta tra un modello di codice inline e un modello di codice code-behind. Il code-behind può essere implementato usando l'attributo Src o l'attributo CodeBehind della @Page direttiva. In ASP.NET 2.0 gli sviluppatori hanno ancora una scelta tra codice inline e code-behind, ma sono stati apportati miglioramenti significativi al modello code-behind.

Miglioramenti nel modello di Code-Behind

Per comprendere completamente le modifiche apportate al modello code-behind in ASP.NET 2.0, è consigliabile esaminare rapidamente il modello in ASP.NET 1.x.

Modello Code-Behind in ASP.NET 1.x

In ASP.NET 1.x il modello code-behind è costituito da un file ASPX (webform) e da un file code-behind contenente codice di programmazione. I due file sono stati connessi usando la @Page direttiva nel file ASPX. Ogni controllo nella pagina ASPX ha una dichiarazione corrispondente nel file code-behind come variabile di istanza. Il file code-behind contiene anche codice per l'associazione di eventi e il codice generato necessario per la finestra di progettazione di Visual Studio. Questo modello funzionava abbastanza bene, ma perché ogni elemento ASP.NET nella pagina ASPX richiedeva il codice corrispondente nel file code-behind, non c'era una vera separazione del codice e del contenuto. Ad esempio, se una finestra di progettazione ha aggiunto un nuovo controllo server a un file ASPX all'esterno dell'IDE di Visual Studio, l'applicazione si interromperà a causa dell'assenza di una dichiarazione per tale controllo nel file code-behind.

Modello di Code-Behind in ASP.NET 2.0

ASP.NET 2.0 migliora notevolmente il modello. In ASP.NET 2.0, il code-behind viene implementato usando le nuove classi parziali fornite in ASP.NET 2.0. La classe code-behind in ASP.NET 2.0 è definita come classe parziale che contiene solo parte della definizione della classe. La parte rimanente della definizione della classe viene generata dinamicamente da ASP.NET 2.0 usando la pagina ASPX in fase di esecuzione o quando il sito Web è precompilato. Il collegamento tra il file code-behind e la pagina ASPX viene ancora stabilito usando la direttiva @ Page. Tuttavia, invece di un attributo CodeBehind o Src, ASP.NET 2.0 usa ora l'attributo CodeFile. L'attributo Eredita viene usato anche per specificare il nome della classe per la pagina.

Una tipica direttiva @ Page potrebbe essere simile alla seguente:

<%@Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

Una definizione tipica della classe in un file code-behind ASP.NET 2.0 potrebbe essere simile al seguente:

public partial class _Default : System.Web.UI.Page

Nota

C# e Visual Basic sono gli unici linguaggi gestiti che attualmente supportano classi parziali. Pertanto, gli sviluppatori che usano J# non potranno usare il modello code-behind in ASP.NET 2.0.

Il nuovo modello migliora il modello code-behind perché gli sviluppatori avranno ora file di codice che contengono solo il codice creato. Fornisce anche una vera separazione del codice e del contenuto perché non sono presenti dichiarazioni di variabili di istanza nel file code-behind.

Nota

Poiché la classe parziale per la pagina ASPX è la posizione in cui si svolge l'associazione di eventi, gli sviluppatori di Visual Basic possono realizzare un lieve aumento delle prestazioni usando la parola chiave Handle nel code-behind per associare gli eventi. C# non ha parole chiave equivalenti.

Attributi della direttiva New @ Page

ASP.NET 2.0 aggiunge molti nuovi attributi alla direttiva @ Page. Gli attributi seguenti sono nuovi in ASP.NET 2.0.

Async

L'attributo Async consente di configurare la pagina da eseguire in modo asincrono. Coprire bene le pagine asincrone più avanti in questo modulo.

Timeout asincrono

Specificato il timeout per le pagine asincrone. Il valore predefinito è 45 secondi.

Codefile

L'attributo CodeFile è la sostituzione dell'attributo CodeBehind in Visual Studio 2002/2003.

CodeFileBaseClass

L'attributo CodeFileBaseClass viene usato nei casi in cui si desidera che più pagine vengano derivate da una singola classe di base. A causa dell'implementazione di classi parziali in ASP.NET, senza questo attributo, una classe di base che usa campi comuni condivisi per fare riferimento ai controlli dichiarati in una pagina ASPX non funziona correttamente perché ASP. Il motore di compilazione delle reti nets creerà automaticamente nuovi membri in base ai controlli nella pagina. Pertanto, se si vuole una classe base comune per due o più pagine in ASP.NET, sarà necessario definire la classe di base nell'attributo CodeFileBaseClass e quindi derivare ogni classe di pagine da tale classe di base. L'attributo CodeFile è necessario anche quando viene usato questo attributo.

Compilationmode

Questo attributo consente di impostare la proprietà CompilationMode della pagina ASPX. La proprietà CompilationMode è un'enumerazione contenente i valori Always, Auto e Never. Il valore predefinito è Always. Se possibile, l'impostazione Automatica impedisce ASP.NET di compilare dinamicamente la pagina. L'esclusione delle pagine dalla compilazione dinamica aumenta le prestazioni. Tuttavia, se una pagina esclusa contiene il codice che deve essere compilato, verrà generato un errore quando viene visualizzata la pagina.

Abilitare la convalida degli eventi

Questo attributo specifica se gli eventi di postback e callback vengono convalidati. Quando questa opzione è abilitata, gli argomenti per eseguire il postback o gli eventi di callback vengono controllati per assicurarsi che abbiano origine dal controllo server che li ha originariamente sottoposti a rendering.

Abilitare l'abilitazione di tali elementi

Questo attributo specifica se i temi ASP.NET vengono usati in una pagina. Il valore predefinito è false. ASP.NET temi sono trattati nel modulo 10.

LinePragmas

Questo attributo specifica se è necessario aggiungere pragmas di riga durante la compilazione. I pragmas di riga sono opzioni usate dai debugger per contrassegnare sezioni specifiche del codice.

MaintainScrollPositionOnPostback

Questo attributo specifica se JavaScript viene inserito nella pagina per mantenere la posizione di scorrimento tra postback. Questo attributo è false per impostazione predefinita.

Quando questo attributo è true, ASP.NET aggiungerà un <blocco di script> al postback simile al seguente:

<script src="/website/WebResource.axd?d=jBAvpwrdOM_V_Xzeox989A2 &t=632653133849531250" type="text/javascript"> </script>

Si noti che lo src per questo blocco di script è WebResource.axd. Questa risorsa non è un percorso fisico. Quando viene richiesto questo script, ASP.NET compila dinamicamente lo script.

Masterpagefile

Questo attributo specifica il file della pagina master per la pagina corrente. Il percorso può essere relativo o assoluto. Le pagine master sono illustrate nel modulo 4.

Tema foglio di stile

Questo attributo consente di eseguire l'override delle proprietà dell'aspetto dell'interfaccia utente definite da un tema ASP.NET 2.0. I temi sono trattati nel modulo 10.

Valore del tema

Specifica il tema per la pagina. Se un valore non viene specificato per l'attributo StyleSheetTheme, l'attributo Theme esegue l'override di tutti gli stili applicati ai controlli nella pagina.

Valore titolo

Imposta il titolo per la pagina. Il valore specificato qui verrà visualizzato nell'elemento <titolo> della pagina di cui è stato eseguito il rendering.

Viewstateencryptionmode

Imposta il valore per l'enumerazione ViewStateEncryptionMode. I valori disponibili sono Always, Auto e Never. Il valore predefinito è Auto. Quando questo attributo è impostato su un valore auto, lo stato di visualizzazione viene crittografato è un controllo che lo richiede chiamando il metodo RegisterRequiresViewStateEncryption .

Impostazione dei valori delle proprietà pubbliche tramite la direttiva @ Page

Un'altra nuova funzionalità della direttiva @ Page in ASP.NET 2.0 è la possibilità di impostare il valore iniziale delle proprietà pubbliche di una classe base. Si supponga, ad esempio, di avere una proprietà pubblica denominata SomeText nella classe di base e si vuole che venga inizializzata in Hello quando viene caricata una pagina. È possibile eseguire questa operazione impostando semplicemente il valore nella direttiva @ Page come segue:

<%@Page Language="C#" SomeText="Hello!" Inherits="PageBase" %>

L'attributo SomeText della direttiva @ Page imposta il valore iniziale della proprietà SomeText nella classe base su Hello!. Il video seguente illustra come impostare il valore iniziale di una proprietà pubblica in una classe di base usando la direttiva @ Page.

Aprire Full-Screen Video

Nuove proprietà pubbliche della classe Page

Le proprietà pubbliche seguenti sono nuove in ASP.NET 2.0.

AppRelativeTemplateSourceDirectory

Restituisce il percorso relativo all'applicazione della pagina o del controllo. Ad esempio, per una pagina che si trova in http://app/folder/page.aspx, la proprietà restituisce ~/cartella/.

AppRelativeVirtualPath

Restituisce il percorso della directory virtuale relativa alla pagina o al controllo . Ad esempio, per una pagina che si trova in http://app/folder/page.aspx, la proprietà restituisce ~/folder/page.aspx.

Asynctimeout

Ottiene o imposta il timeout utilizzato per la gestione asincrona delle pagine. Le pagine asincrone verranno illustrate più avanti in questo modulo.

ClientQueryString

Proprietà di sola lettura che restituisce la parte della stringa di query dell'URL richiesto. Questo valore è codificato in URL. È possibile usare il metodo UrlDecode della classe HttpServerUtility per decodificarlo.

ClientScript

Questa proprietà restituisce un oggetto ClientScriptManager che può essere utilizzato per gestire ASP. Emissione di RETI di script lato client. La classe ClientScriptManager viene descritta più avanti in questo modulo.

Enableeventvalidation

Questa proprietà controlla se la convalida degli eventi è abilitata per gli eventi di postback e callback. Se abilitata, gli argomenti per il postback o gli eventi di callback vengono verificati per assicurarsi che provenissero dal controllo server che li ha originariamente sottoposti a rendering.

Enabletheming

Questa proprietà ottiene o imposta un valore booleano che specifica se un tema ASP.NET 2.0 si applica o meno alla pagina.

Form

Questa proprietà restituisce il modulo HTML nella pagina ASPX come oggetto HtmlForm.

Intestazione

Questa proprietà restituisce un riferimento a un oggetto HtmlHead che contiene l'intestazione di pagina. È possibile utilizzare l'oggetto HtmlHead restituito per ottenere/impostare fogli di stile, meta tag e così via.

IdSeparator

Questa proprietà di sola lettura ottiene il carattere utilizzato per separare gli identificatori di controllo quando ASP.NET crea un ID univoco per i controlli in una pagina. Non è progettato per l'utilizzo diretto dal codice.

IsAsync

Questa proprietà consente pagine asincrone. Le pagine asincrone vengono descritte più avanti in questo modulo.

IsCallback

Questa proprietà di sola lettura restituisce true se la pagina è il risultato di una chiamata. I callback vengono descritti più avanti in questo modulo.

IsCrossPagePostBack

Questa proprietà di sola lettura restituisce true se la pagina fa parte di un postback tra pagine. I postback tra pagine vengono trattati più avanti in questo modulo.

Elementi

Restituisce un riferimento a un'istanza IDictionary che contiene tutti gli oggetti archiviati nel contesto delle pagine. È possibile aggiungere elementi a questo oggetto IDictionary e saranno disponibili per tutta la durata del contesto.

MaintainScrollPositionOnPostBack

Questa proprietà controlla se ASP.NET genera JavaScript che mantiene la posizione di scorrimento delle pagine nel browser dopo che si verifica un postback. I dettagli di questa proprietà sono stati descritti in precedenza in questo modulo.

Master

Questa proprietà di sola lettura restituisce un riferimento all'istanza di MasterPage per una pagina a cui è stata applicata una pagina master.

Masterpagefile

Ottiene o imposta il nome file della pagina master per la pagina. Questa proprietà può essere impostata solo nel metodo PreInit.

Maxpagestatefieldlength

Questa proprietà ottiene o imposta la lunghezza massima per lo stato delle pagine in byte. Se la proprietà è impostata su un numero positivo, lo stato di visualizzazione pagine verrà suddiviso in più campi nascosti in modo che non superi il numero di byte specificati. Se la proprietà è un numero negativo, lo stato di visualizzazione non verrà suddiviso in blocchi.

Pageadapter

Restituisce un riferimento all'oggetto PageAdapter che modifica la pagina per il browser richiedente.

Previouspage

Restituisce un riferimento alla pagina precedente nei casi di un postback server.Transfer o tra pagine.

Skinid

Specifica l'interfaccia ASP.NET 2.0 da applicare alla pagina.

Stylesheettheme

Questa proprietà ottiene o imposta il foglio di stile applicato a una pagina.

Templatecontrol

Restituisce un riferimento al controllo contenitore per la pagina.

Tema

Ottiene o imposta il nome del tema ASP.NET 2.0 applicato alla pagina. Questo valore deve essere impostato prima del metodo PreInit.

Titolo

Questa proprietà ottiene o imposta il titolo della pagina ottenuto dall'intestazione delle pagine.

Viewstateencryptionmode

Ottiene o imposta viewStateEncryptionMode della pagina. Vedere una descrizione dettagliata di questa proprietà in precedenza in questo modulo.

Nuove proprietà protette della classe Page

Di seguito sono riportate le nuove proprietà protette della classe Page in ASP.NET 2.0.

Adattatore

Restituisce un riferimento all'oggetto ControlAdapter che esegue il rendering della pagina nel dispositivo che lo ha richiesto.

AsyncMode

Questa proprietà indica se la pagina viene elaborata in modo asincrono. È destinato all'uso da parte del runtime e non direttamente nel codice.

ClientIDSeparator

Questa proprietà restituisce il carattere utilizzato come separatore durante la creazione di ID client univoci per i controlli. È destinato all'uso da parte del runtime e non direttamente nel codice.

Pagestatepersister

Questa proprietà restituisce l'oggetto PageStatePersister per la pagina. Questa proprietà viene usata principalmente dagli sviluppatori di controlli ASP.NET.

UniqueFilePathSuffix

Questa proprietà restituisce un suffisso univoco aggiunto al percorso del file per i browser di memorizzazione nella cache. Il valore predefinito è __ufps= e un numero a 6 cifre.

Nuovi metodi pubblici per la classe Page

I metodi pubblici seguenti sono nuovi della classe Page in ASP.NET 2.0.

AddOnPreRenderCompleteAsync

Questo metodo registra i delegati del gestore eventi per l'esecuzione asincrona della pagina. Le pagine asincrone vengono descritte più avanti in questo modulo.

ApplyStyleSheetSkin

Applica le proprietà di un foglio di stile di pagine alla pagina.

ExecuteRegisteredAsyncTasks

Questo metodo è un'attività asincrona.

GetValidators

Restituisce una raccolta di validator per il gruppo di convalida specificato o il gruppo di convalida predefinito se non è specificato alcun oggetto.

RegisterAsyncTask

Questo metodo registra una nuova attività asincrona. Le pagine asincrone vengono illustrate più avanti in questo modulo.

RegisterRequiresControlState

Questo metodo indica ASP.NET che lo stato del controllo pagine deve essere persistente.

RegisterRequiresViewStateEncryption

Questo metodo indica ASP.NET che lo stato di visualizzazione delle pagine richiede la crittografia.

ResolveClientUrl

Restituisce un URL relativo che può essere usato per le richieste client per le immagini e così via.

SetFocus

Questo metodo imposta lo stato attivo sul controllo specificato quando la pagina viene inizialmente caricata.

Annullare la registrazioneRequiresControlState

Questo metodo annulla la registrazione del controllo passato a esso perché non richiede più la persistenza dello stato di controllo.

Modifiche al ciclo di vita della pagina

Il ciclo di vita della pagina in ASP.NET 2.0 non è cambiato in modo significativo, ma esistono alcuni nuovi metodi da tenere presente. Il ciclo di vita della pagina ASP.NET 2.0 è descritto di seguito.

PreInit (nuovo in ASP.NET 2.0)

L'evento PreInit è la prima fase del ciclo di vita a cui uno sviluppatore può accedere. L'aggiunta di questo evento consente di modificare a livello di codice ASP.NET temi 2.0, pagine master, proprietà di accesso per un profilo ASP.NET 2.0 e così via. Se si è in uno stato di postback, è importante capire che Viewstate non è ancora stato applicato ai controlli a questo punto nel ciclo di vita. Pertanto, se uno sviluppatore modifica una proprietà di un controllo in questa fase, probabilmente verrà sovrascritto più avanti nel ciclo di vita delle pagine.

Init

L'evento Init non è cambiato da ASP.NET 1.x. Questa è la posizione in cui si desidera leggere o inizializzare le proprietà dei controlli nella pagina. In questa fase, pagine master, temi e così via. sono già applicati alla pagina.

InitComplete (novità nella versione 2.0)

L'evento InitComplete viene chiamato alla fine della fase di inizializzazione delle pagine. A questo punto nel ciclo di vita, è possibile accedere ai controlli nella pagina, ma lo stato non è ancora stato popolato.

PreLoad (nuovo in 2.0)

Questo evento viene chiamato dopo che tutti i dati di postback sono stati applicati e subito prima di Page_Load.

Caricamento

L'evento Load non è cambiato da ASP.NET 1.x.

LoadComplete (novità nella versione 2.0)

L'evento LoadComplete è l'ultimo evento nella fase di caricamento delle pagine. In questa fase, tutti i dati postback e viewstate sono stati applicati alla pagina.

Prerender

Se si desidera mantenere correttamente lo stato di visualizzazione per i controlli aggiunti alla pagina in modo dinamico, l'evento PreRender è l'ultima opportunità di aggiungerle.

PreRenderComplete (nuovo in 2.0)

Nella fase PreRenderComplete tutti i controlli sono stati aggiunti alla pagina e la pagina è pronta per il rendering. L'evento PreRenderComplete è l'ultimo evento generato prima che venga salvato lo stato di visualizzazione delle pagine.

SaveStateComplete (novità nella versione 2.0)

L'evento SaveStateComplete viene chiamato immediatamente dopo che è stato salvato lo stato di visualizzazione e controllo di tutte le pagine. Questo è l'ultimo evento prima del rendering della pagina nel browser.

Rendering

Il metodo Rendering non è cambiato da ASP.NET 1.x. In questo caso, htmlTextWriter viene inizializzato e viene eseguito il rendering della pagina nel browser.

Postback tra pagine in ASP.NET 2.0

In ASP.NET 1.x, i postback sono stati necessari per pubblicare nella stessa pagina. I postback tra pagine non sono consentiti. ASP.NET 2.0 aggiunge la possibilità di eseguire il postback a una pagina diversa tramite l'interfaccia IButtonControl. Qualsiasi controllo che implementa la nuova interfaccia IButtonControl (Button, LinkButton e ImageButton oltre ai controlli personalizzati di terze parti) può sfruttare questa nuova funzionalità tramite l'uso dell'attributo PostBackUrl. Il codice seguente mostra un controllo Button che esegue il post di nuovo in una seconda pagina.

<asp:Button ID="SubmitReport" PostBackUrl="~/Default.aspx" runat="server" Text="Submit Report" />

Quando la pagina viene pubblicata, la pagina che avvia il postback è accessibile tramite la proprietà PreviousPage nella seconda pagina. Questa funzionalità viene implementata tramite la nuova funzione lato client WebForm_DoPostBackWithOptions che ASP.NET 2.0 esegue il rendering della pagina quando un controllo esegue il post a una pagina diversa. Questa funzione JavaScript viene fornita dal nuovo gestore WebResource.axd che genera script al client.

Il video seguente è una procedura dettagliata di un postback tra pagine.

Aprire Full-Screen Video

Altri dettagli sui postback tra pagine

Viewstate

Potrebbe essere stato chiesto già cosa accade allo stato di visualizzazione dalla prima pagina in uno scenario di postback tra pagine. Dopo tutto, qualsiasi controllo che non implementa IPostBackDataHandler persisterà lo stato tramite viewstate, in modo da avere accesso alle proprietà del controllo nella seconda pagina di un postback tra pagine, è necessario avere accesso allo stato di visualizzazione per la pagina. ASP.NET 2.0 si occupa di questo scenario usando un nuovo campo nascosto nella seconda pagina denominata __PREVIOUSPAGE. Il campo modulo __PREVIOUSPAGE contiene lo stato di visualizzazione per la prima pagina in modo che sia possibile accedere alle proprietà di tutti i controlli nella seconda pagina.

Aggirare FindControl

Nella procedura dettagliata video di un postback tra pagine, ho usato il metodo FindControl per ottenere un riferimento al controllo TextBox nella prima pagina. Questo metodo funziona bene per tale scopo, ma FindControl è costoso e richiede la scrittura di codice aggiuntivo. Fortunatamente, ASP.NET 2.0 offre un'alternativa a FindControl per questo scopo che funzionerà in molti scenari. La direttiva PreviousPageType consente di avere un riferimento fortemente tipizzato alla pagina precedente usando TypeName o l'attributo VirtualPath. L'attributo TypeName consente di specificare il tipo della pagina precedente mentre l'attributo VirtualPath consente di fare riferimento alla pagina precedente usando un percorso virtuale. Dopo aver impostato la direttiva PreviousPageType, è quindi necessario esporre i controlli e così via. a cui si vuole consentire l'accesso usando le proprietà pubbliche.

Postback tra pagine 1 lab

In questo lab verrà creata un'applicazione che usa la nuova funzionalità di postback tra pagine di ASP.NET 2.0.

1. Aprire Visual Studio 2005 e creare un nuovo sito Web ASP.NET.

2. Aggiungere una nuova webform denominata page2.aspx.

3. Aprire Default.aspx nella visualizzazione Progettazione e aggiungere un controllo Button e un controllo TextBox.

   1. Assegnare al controllo Button un ID di SubmitButton e al controllo TextBox un ID di UserName.
   2. Impostare la proprietà PostBackUrl del pulsante su page2.aspx.

4. Aprire page2.aspx nella visualizzazione Origine.

5. Aggiungere una direttiva @ PreviousPageType come illustrato di seguito:

6. Aggiungere il codice seguente alla Page_Load del code-behind di page2.aspx:

   Response.Write(PreviousPage.UserName.Text);
   

7. Compilare il progetto facendo clic su Compila nel menu Compila.

8. Aggiungere il codice seguente al code-behind per Default.aspx:

   public TextBox txtUserName {
       get { return this.UserName; }
   }
   

9. Modificare il Page_Load in page2.aspx nel modo seguente:

   Response.Write(PreviousPage.txtUserName.Text);
   

10. Compilare il progetto.

11. Eseguire il progetto.

12. Immettere il nome nella casella di testo e fare clic sul pulsante .

13. Qual è il risultato?

Pagine asincrone in ASP.NET 2.0

Molti problemi di contesa in ASP.NET sono causati dalla latenza delle chiamate esterne (ad esempio chiamate di servizio Web o di database), la latenza I/O file e così via. Quando una richiesta viene effettuata in base a un'applicazione ASP.NET, ASP.NET usa uno dei thread di lavoro per il servizio della richiesta. Tale richiesta è proprietaria del thread fino al completamento della richiesta e la risposta è stata inviata. ASP.NET 2.0 cerca di risolvere i problemi di latenza con questi tipi di problemi aggiungendo la funzionalità per eseguire pagine in modo asincrono. Ciò significa che un thread di lavoro può avviare la richiesta e quindi passare un'esecuzione aggiuntiva a un altro thread, quindi tornare rapidamente al pool di thread disponibile. Quando il file I/O, la chiamata al database e così via. è stato completato, viene ottenuto un nuovo thread dal pool di thread per completare la richiesta.

Il primo passaggio in cui eseguire una pagina in modo asincrono consiste nell'impostare l'attributo Async della direttiva della pagina come segue:

<%@ Page Async="true" %>

Questo attributo indica ASP.NET di implementare IHttpAsyncHandler per la pagina.

Il passaggio successivo consiste nel chiamare il metodo AddOnPreRenderCompleteAsync a un punto del ciclo di vita della pagina prima di PreRender. Questo metodo viene in genere chiamato in Page_Load. Il metodo AddOnPreRenderCompleteAsync accetta due parametri; BeginEventHandler e EndEventHandler. BeginEventHandler restituisce un oggetto IAsyncResult che viene quindi passato come parametro a EndEventHandler.

Il video seguente è una procedura dettagliata di una richiesta di pagina asincrona.

Aprire Full-Screen Video

Nota

Non viene eseguito il rendering di una pagina asincrona nel browser fino al completamento di EndEventHandler. Senza dubbio, ma alcuni sviluppatori pensano che le richieste asincrone siano simili ai callback asincroni. È importante rendersi conto che non sono. Il vantaggio delle richieste asincrone è che il primo thread di lavoro può essere restituito al pool di thread per gestire le nuove richieste, riducendo così la contesa dovuta all'associazione di I/O e così via.

Script callback in ASP.NET 2.0

Gli sviluppatori Web hanno sempre cercato modi per evitare lo sfarfallio associato a un callback. In ASP.NET 1.x, SmartNavigation è stato il metodo più comune per evitare sfarfallio, ma SmartNavigation ha causato problemi per alcuni sviluppatori a causa della complessità dell'implementazione nel client. ASP.NET 2.0 risolve questo problema con i callback di script. I callback di script utilizzano XMLHttp per effettuare richieste sul server Web tramite JavaScript. La richiesta XMLHttp restituisce dati XML che possono quindi essere modificati tramite il DOM del browser. Il codice XMLHttp è nascosto dall'utente dal nuovo gestore WebResource.axd.

Esistono diversi passaggi necessari per configurare un callback di script in ASP.NET 2.0.

Passaggio 1: Implementare l'interfaccia ICallbackEventHandler

Affinché ASP.NET di riconoscere la pagina come partecipante a un callback di script, è necessario implementare l'interfaccia ICallbackEventHandler. È possibile eseguire questa operazione nel file code-behind come segue:

public partial class _Default : System.Web.UI.Page, ICallbackEventHandler

È anche possibile eseguire questa operazione usando la direttiva @ Implements come indicato di seguito:

<%@ Implements Interface="System.Web.UI.ICallbackEventHandler" %>

In genere si usa la direttiva @ Implements quando si usa codice ASP.NET inline.

Passaggio 2: Chiamare GetCallbackEventReference

Come accennato in precedenza, la chiamata XMLHttp viene incapsulata nel gestore WebResource.axd. Quando viene eseguito il rendering della pagina, ASP.NET aggiungerà una chiamata a WebForm_DoCallback, uno script client fornito da WebResource.axd. La funzione WebForm_DoCallback sostituisce la funzione __doPostBack per un callback. Tenere presente che __doPostBack invia il modulo a livello di codice nella pagina. In uno scenario di callback si vuole impedire un postback, quindi __doPostBack non sarà sufficiente.

Nota

__doPostBack viene comunque eseguito il rendering nella pagina in uno scenario di callback dello script client. Tuttavia, non viene usato per il callback.

Gli argomenti per la funzione lato client WebForm_DoCallback vengono forniti tramite la funzione sul lato server GetCallbackEventReference che normalmente viene chiamata in Page_Load. Una chiamata tipica a GetCallbackEventReference potrebbe essere simile alla seguente:

// Set up the JavaScript callback string cbRef = cm.GetCallbackEventReference(this, "document.getElementById('ddlCompany').value", "ShowCompanyName", "null", true);

Nota

In questo caso cm è un'istanza di ClientScriptManager. La classe ClientScriptManager verrà descritta più avanti in questo modulo.

Esistono diverse versioni di overload di GetCallbackEventReference. In questo caso, gli argomenti sono i seguenti:

this

Riferimento al controllo in cui viene chiamato GetCallbackEventReference. In questo caso, si tratta della pagina stessa.

document.getElementById('ddlCompany').value

Argomento stringa che verrà passato dal codice lato client all'evento lato server. In questo caso, Im passando il valore di un elenco a discesa denominato ddlCompany.

ShowCompanyName

Nome della funzione lato client che accetterà il valore restituito (come stringa) dall'evento di callback lato server. Questa funzione verrà chiamata solo quando il callback sul lato server ha esito positivo. Pertanto, per motivi di affidabilità, è in genere consigliabile usare la versione di overload di GetCallbackEventReference che accetta un argomento stringa aggiuntivo che specifica il nome di una funzione lato client da eseguire in caso di errore.

null

Stringa che rappresenta una funzione lato client avviata prima del callback al server. In questo caso, non esiste uno script di questo tipo, quindi l'argomento è Null.

true

Valore booleano che specifica se eseguire o meno il callback in modo asincrono.

La chiamata a WebForm_DoCallback sul client passerà questi argomenti. Pertanto, quando viene eseguito il rendering di questa pagina nel client, il codice sarà simile al seguente:

WebForm_DoCallback('__Page',document.getElementById('ddlCompany').value, ShowCompanyName,null,null,true)

Si noti che la firma della funzione nel client è leggermente diversa. La funzione lato client passa 5 stringhe e un valore booleano. La stringa aggiuntiva (che è Null nell'esempio precedente) contiene la funzione lato client che gestirà eventuali errori dal callback lato server.

Passaggio 3: Associare l'evento di controllo Client-Side

Si noti che il valore restituito di GetCallbackEventReference precedente è stato assegnato a una variabile stringa. Tale stringa viene usata per associare un evento sul lato client per il controllo che avvia il callback. In questo esempio il callback viene avviato da un elenco a discesa nella pagina, quindi si vuole associare l'evento OnChange .

Per associare l'evento sul lato client, è sufficiente aggiungere un gestore al markup lato client come indicato di seguito:

// Hook the JavaScript function to the onchange event of the dropdown ddlCompany.Attributes["onchange"] = String.Format("javascript:{0}", cbRef);

Tenere presente che cbRef è il valore restituito dalla chiamata a GetCallbackEventReference. Contiene la chiamata a WebForm_DoCallback illustrata in precedenza.

Passaggio 4: Registrare lo script Client-Side

Tenere presente che la chiamata a GetCallbackEventReference ha specificato che uno script lato client denominato ShowCompanyName verrebbe eseguito quando il callback sul lato server ha esito positivo. Tale script deve essere aggiunto alla pagina usando un'istanza clientScriptManager. La classe ClientScriptManager verrà illustrata più avanti in questo modulo. A tale scopo, eseguire questa operazione:

System.Text.StringBuilder clientScript = new System.Text.StringBuilder(""); ClientScriptManager cm = Page.ClientScript; // Create the client script clientScript.Append("function ShowCompanyName(companyName)"); clientScript.Append("{"); clientScript.Append("document.getElementById('CoClicked').innerHTML = \"You chose \" + companyName + \".\";"); clientScript.Append("}"); cm.RegisterClientScriptBlock(this.GetType(), "showCo", clientScript.ToString(), true);

Passaggio 5: Chiamare i metodi dell'interfaccia ICallbackEventHandler

ICallbackEventHandler contiene due metodi che è necessario implementare nel codice. Sono RaiseCallbackEvent e GetCallbackEvent.

RaiseCallbackEvent accetta una stringa come argomento e non restituisce nulla. L'argomento stringa viene passato dalla chiamata sul lato client a WebForm_DoCallback. In questo caso, tale valore è l'attributo value dell'elenco a discesa denominato ddlCompany. Il codice lato server deve essere inserito nel metodo RaiseCallbackEvent. Ad esempio, se il callback esegue un'operazione WebRequest su una risorsa esterna, tale codice deve essere inserito in RaiseCallbackEvent.

GetCallbackEvent è responsabile dell'elaborazione del ritorno del callback al client. Non accetta argomenti e restituisce una stringa. La stringa restituita verrà passata come argomento alla funzione lato client, in questo caso ShowCompanyName.

Dopo aver completato i passaggi precedenti, è possibile eseguire un callback di script in ASP.NET 2.0.

Aprire Full-Screen Video

I callback di script in ASP.NET sono supportati in qualsiasi browser che supporta l'esecuzione di chiamate XMLHttp. Che include tutti i browser moderni in uso oggi. Internet Explorer usa l'oggetto XMLHttp ActiveX mentre altri browser moderni (incluso il prossimo Internet Explorer 7) usano un oggetto XMLHttp intrinseco. Per determinare a livello di codice se un browser supporta i callback, è possibile utilizzare la proprietà Request.Browser.SupportCallback . Questa proprietà restituirà true se il client richiedente supporta i callback di script.

Uso dello script client in ASP.NET 2.0

Gli script client in ASP.NET 2.0 vengono gestiti tramite l'uso della classe ClientScriptManager. La classe ClientScriptManager tiene traccia degli script client usando un tipo e un nome. Ciò impedisce l'inserimento dello stesso script a livello di codice in una pagina più volte.

Nota

Dopo che uno script è stato registrato correttamente in una pagina, qualsiasi tentativo successivo di registrare lo stesso script comporterà semplicemente la mancata registrazione dello script una seconda volta. Non vengono aggiunti script duplicati e non si verifica alcuna eccezione. Per evitare calcoli non necessari, esistono metodi che è possibile usare per determinare se uno script è già registrato in modo da non tentare di registrarlo più volte.

I metodi di ClientScriptManager devono essere noti a tutti gli sviluppatori ASP.NET correnti:

Registerclientscriptblock

Questo metodo aggiunge uno script alla parte superiore della pagina sottoposta a rendering. Ciò è utile per l'aggiunta di funzioni che verranno chiamate in modo esplicito nel client.

Esistono due versioni di overload di questo metodo. Tre di quattro argomenti sono comuni tra loro. ovvero:

type (string)

L'argomento type identifica un tipo per lo script. In genere è consigliabile usare il tipo di pagina (questo. GetType()) per il tipo.

key (string)

L'argomento chiave è una chiave definita dall'utente per lo script. Deve essere univoco per ogni script. Se si tenta di aggiungere uno script con la stessa chiave e il tipo di uno script già aggiunto, non verrà aggiunto.

script (string)

L'argomento script è una stringa contenente lo script effettivo da aggiungere. È consigliabile usare stringBuilder per creare lo script e quindi usare il metodo ToString() in StringBuilder per assegnare l'argomento script .

Se si usa l'overload RegisterClientScriptBlock che accetta solo tre argomenti, è necessario includere gli elementi dello script (<script> e </script) nello script>.

È possibile scegliere di usare l'overload di RegisterClientScriptBlock che accetta un quarto argomento. Il quarto argomento è un valore booleano che specifica se ASP.NET deve aggiungere o meno elementi di script. Se questo argomento è true, lo script non deve includere in modo esplicito gli elementi dello script.

Usare il metodo IsClientScriptBlockRegistered per determinare se uno script è già stato registrato. In questo modo è possibile evitare un tentativo di registrare nuovamente uno script già registrato.

RegisterClientScriptInclude (novità nella versione 2.0)

Il tag RegisterClientScriptInclude crea un blocco di script che collega a un file di script esterno. Ha due overload. Una accetta una chiave e un URL. Il secondo aggiunge un terzo argomento che specifica il tipo.

Ad esempio, il codice seguente genera un blocco di script che si collega a jsfunctions.js nella radice della cartella scripts dell'applicazione:

ClientScriptManager cm = Page.ClientScript; if(!cm.IsClientScriptIncludeRegistered("jsfunc")) { cm.RegisterClientScriptInclude(this.GetType(), "jsfunc", "/scripts/jsfunctions.js"); }

Questo codice produce il codice seguente nella pagina sottoposta a rendering:

<script src="/scripts/jsfunctions.js" type="text/javascript"></script>

Nota

Il rendering del blocco di script viene eseguito nella parte inferiore della pagina.

Usare il metodo IsClientScriptIncludeRegistered per determinare se uno script è già stato registrato. In questo modo è possibile evitare un tentativo di registrare nuovamente uno script.

Registerstartupscript

Il metodo RegisterStartupScript accetta gli stessi argomenti del metodo RegisterClientScriptBlock. Uno script registrato con RegisterStartupScript viene eseguito dopo il caricamento della pagina, ma prima dell'evento sul lato client OnLoad. Nella versione 1.X gli script registrati con RegisterStartupScript sono stati inseriti subito prima del tag /form di chiusura <mentre gli script registrati con RegisterClientScriptBlock sono stati inseriti immediatamente dopo il tag del modulo> di apertura<.> In ASP.NET 2.0, entrambi vengono posizionati immediatamente prima del tag /form> di chiusura<.

Nota

Se si registra una funzione con RegisterStartupScript, tale funzione non verrà eseguita fino a quando non viene chiamata in modo esplicito nel codice lato client.

Utilizzare il metodo IsStartupScriptRegistered per determinare se uno script è già stato registrato ed evitare un tentativo di registrare nuovamente uno script.

Altri metodi ClientScriptManager

Ecco alcuni degli altri metodi utili della classe ClientScriptManager.

Getcallbackeventreference	Vedere i callback di script più indietro in questo modulo.
GetPostBackClientHyperlink	Ottiene un riferimento JavaScript (javascript:<call>) che può essere usato per eseguire il postback da un evento sul lato client.
GetPostBackEventReference	Ottiene una stringa che può essere utilizzata per avviare un postback dal client.
GetWebResourceUrl	Restituisce un URL a una risorsa incorporata in un assembly. Deve essere usato insieme a RegisterClientScriptResource.
RegisterClientScriptResource	Registra una risorsa Web con la pagina. Si tratta di risorse incorporate in un assembly e gestite dal nuovo gestore WebResource.axd.
RegisterHiddenField	Registra un campo modulo nascosto nella pagina.
RegisterOnSubmitStatement	Registra il codice lato client che viene eseguito quando viene inviato il modulo HTML.