• Programmazione » ASP.NET » Guida ASP NET

Gli eventi generati da controlli server ASP.NET funzionano in modo differente rispetto agli eventi nei form per applicazioni client tradizionali o nelle applicazioni Web basate su client. La differenza principale è rappresentata dalla separazione dell'evento stesso dalla posizione in cui l'evento viene gestito.

Nelle applicazioni basate su client gli eventi vengono generati e gestiti sul client. Nelle pagine Web Form, invece, gli eventi associati ai controlli server vengono generati sul client ma gestiti sul server Web dal framework di pagine ASP.NET.

Per gli eventi generati sul client, il modello di eventi dei controlli Web Form richiede che le informazioni sugli eventi vengano acquisite sul client e che un messaggio di evento venga trasmesso al server mediante un HTTP Post. Il framework di pagine deve interpretare l'invio per determinare quale evento è stato generato e chiamare il metodo appropriato nel codice del server per gestire l'evento.

Modello di eventi dei controlli Web Form

In ASP.NET sono gestiti praticamente tutti i meccanismi di acquisizione, trasmissione e interpretazione degli eventi. È possibile creare dei gestori eventi in una pagina Web Form senza preoccuparsi di come le informazioni sugli eventi vengano acquisite e rese disponibili al codice. È possibile invece creare i gestori eventi attenendosi alle stesse procedure eseguite in un form per applicazioni client tradizionali. Anche in questi casi è tuttavia necessario tenere presente alcuni aspetti della gestione degli eventi nelle pagine Web Form.

Insieme di eventi intrinseci

Poiché la maggior parte degli eventi di Web Form richiede un percorso di andata e ritorno al server per l'elaborazione, tali eventi possono influenzare le prestazioni di un form. Pertanto, i controlli server offrono un insieme limitato di eventi intrinseci, in genere i soli eventi Click. Alcuni controlli server supportano una versione speciale dell'evento onchange generato in caso di modifica del valore del controllo. Il controllo server Web CheckBoxgenera ad esempio un evento di modifica quando l'utente fa clic sulla casella. Gli eventi che si verificano di frequente e possono essere generati senza segnalazione all'utente, ad esempio gli eventi onmouseover, non sono supportati per i controlli server.

Nota   Alcuni controlli server supportano un insieme di eventi di livello superiore. Ad esempio, il controllo server Web Calendar genera un evento SelectionChanged che rappresenta una versione più astratta di un evento Click.

Argomenti degli eventi

Gli eventi dei controlli server Web e HTML seguono un modello .NET Framework standard per i metodi dei gestori eventi. Tutti gli eventi passano due argomenti: un oggetto che rappresenta l'oggetto che ha generato l'evento e un oggetto evento contenente le eventuali informazioni relative agli eventi. Il secondo argomento è in genere di tipo System.EventArgs, ma per alcuni controlli assume il tipo specifico del controllo. Per un controllo server Web ImageButton, ad esempio, il secondo argomento è di tipoImageClickEventArgs e include informazioni sulle coordinate relative al punto in cui l'utente ha fatto clic.

Eventi di postback e non postback nei controlli server Web

Nei controlli server Web determinati eventi, in genere gli eventi Click, comportano il rinvio del form al server. Gli eventi di modifica nei controlli server HTML e Web, quale il controllo TextBox, vengono acquisiti, ma non causano un invio immediato. Vengono infatti memorizzati nella cache dal controllo fino al successivo invio. Quando la pagina viene elaborata di nuovo sul server, tutti gli eventi in sospeso vengono generati ed elaborati.

Nota   I controlli di convalida possono verificare l'input dell'utente utilizzando lo script client, senza effettuare un percorso di andata e ritorno al server, se tale comportamento è supportato dal browser.

Durante l'elaborazione delle pagine sul server, vengono dapprima elaborati gli eventi, senza un particolare ordine. Una volta terminata l'elaborazione di tutti gli eventi di modifica, viene elaborato l'evento Click che ha causato l'invio del form.

Nota   Si consiglia di non creare una logica dell'applicazione basata sugli eventi di modifica generati in un ordine specifico, a meno che non si disponga di informazioni dettagliate sull'elaborazione degli eventi delle pagine.

È possibile specificare che un evento di modifica generi l'invio di un form. I controlli server Web che supportano un evento di modifica includono una proprietà AutoPostBack. Quando questa proprietà è impostata su true, l'evento di modifica del controllo causa l'invio immediato del form, senza attendere la generazione di un evento Click. Per impostazione predefinita, ad esempio, l'evento CheckedChanged di un controllo CheckBox non causa l'invio della pagina. Tuttavia, impostando la proprietà AutoPostBack del controllo su true, si specifica che la pagina verrà inviata al server per l'elaborazione appena l'utente seleziona la casella di controllo.

Nota   Affinché la proprietà AutoPostBack funzioni correttamente, è necessario che il browser dell'utente sia abilitato per l'esecuzione di script. Nella maggior parte dei browser lo script è attivato in base all'impostazione predefinita. Tuttavia alcuni utenti disattivano lo script per motivi di protezione.

Eventi trasmessi

I controlli server Web, quali Repeater, DataList e DataGrid, possono contenere controlli pulsante che generano eventi. Ciascuna riga in un controllo DataGrid può ad esempio contenere uno o più pulsanti creati dinamicamente dai modelli.

Anziché essere generati singolarmente da un singolo pulsante, gli eventi dei controlli nidificati vengono trasmessi, ovvero inviati al contenitore. Il contenitore a sua volta genera un evento generico denominato ItemCommand con parametri che consentono di identificare il singolo controllo che ha generato l'evento originale. Rispondendo a questo singolo evento, è possibile evitare la creazione di singoli gestori eventi per i controlli figlio.

L'evento ItemCommand include i due argomenti degli eventi standard, un oggetto che fa riferimento all'origine dell'evento e un oggetto evento contenente informazioni specifiche sull'evento.

Nota   I controlli server Web DataGrid e DataList supportano eventi aggiuntivi, quali EditCommand, DeleteCommand e UpdateCommand, che rappresentano esempi particolari di eventi trasmessi.

Con i pulsanti è possibile utilizzare la proprietà CommandArgument per passare una stringa specificata dall'utente al gestore eventi in modo da identificare il pulsante che ha generato l'evento. In un controllo DataList, ad esempio, i pulsanti generano l'evento ItemCommand. È possibile impostare la proprietà CommandArgument di ciascun pulsante su un valore differente, ad esempio un pulsante sul valore "ShowDetails" e un altro sul valore "AddToShoppingCart" , quindi acquisire tali valori nel gestore eventi in un secondo tempo.

Delegati di eventi nelle pagine Web Form

Un evento è un messaggio che informa che è stata eseguita un'azione, ad esempio è stato fatto clic su un pulsante. Nell'applicazione in uso è possibile convertire il messaggio in una chiamata di metodo nel codice, ad esempio "Button1_Click". L'associazione tra il messaggio dell'evento e un metodo specifico, ovvero un gestore eventi, viene eseguita tramite un delegato dell'evento.

Nelle pagine Web Form non è in genere necessario codificare i delegati in modo esplicito. Se si utilizza la finestra di progettazione Web Form in Visual Studio, viene generato del codice che associa automaticamente gli eventi ai metodi. In Visual Basic tale operazione viene eseguita mediante la parola chiave Handles nella dichiarazione del gestore eventi, come nel seguente esempio:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

In Visual C# la finestra di progettazione genera un delegato del gestore eventi esplicito nella pagina, simile al seguente:

private void InitializeComponent()  {        this.Load += new System.EventHandler(this.Page_Load);  }

In alternativa, il framework di pagine ASP.NET consente inoltre di associare gli eventi di pagina ai metodi in modo automatico. Se l'attributo AutoEventWireup della direttiva Page è impostato su true (o è mancante, dato che true è il valore predefinito), il framework di pagine chiamerà gli eventi di pagina automaticamente, in particolare i metodi Page_Init e Page_Load. In tal caso non è necessario alcun delegato o clausola Handles esplicita.

L'attributo AutoEventWireup presenta tuttavia lo svantaggio di richiedere che i gestori eventi di pagina abbiano siano identificati da nomi specifici e significativi. Ciò limita la flessibilità concessa nella denominazione dei gestori eventi. Per questo motivo, in Visual Studio l'attributo AutoEventWireup è impostato su false in base all'impostazione predefinita e la finestra di progettazione genera codice esplicito per associare gli eventi di pagina ai metodi.

Se si imposta AutoEventWireup su true, verrà generato il codice per associare gli eventi e il framework di pagine chiamerà automaticamente gli eventi in base al nome. È quindi possibile che lo stesso codice di evento venga chiamato due volte durante l'esecuzione della pagina. Si consiglia pertanto di lasciare AutoEventWireup impostato su false quando si lavora in Visual Studio.

Risposta a eventi client e server nei controlli server ASP.NET

Lo sviluppatore è principalmente interessato agli eventi generati nel codice server. Se tuttavia l'applicazione in uso lo consente, è anche possibile gestire eventi del lato client per i controlli server ASP.NET scrivendo script client.

Nota   Non è possibile utilizzare la sintassi HTML per eseguire l'associazione a eventi del lato client per i controlli server Web. È invece necessario aggiungere gli attributi di associazione eventi nel codice. Per un esempio, vedere la tabella riportata di seguito.

È ad esempio possibile che si disponga di un elemento di un pulsante immagine HTML convertito in un controllo server HTML. In genere, in una pagina Web Form l'evento Click del pulsante immagine viene gestito nel codice server. Tuttavia, è anche possibile utilizzare il codice client per modificare l'immagine quando l'utente sposta il mouse su di essa. Per eseguire questa operazione, creare uno script client per l'evento onmouseover del pulsante immagine. In questo esempio si presume l'utilizzo di un browser che supporti HTML 4.0, quale Microsoft Internet Explorer 4.0 o versione successiva.

Nota   Nel caso in cui il gestore eventi del lato client e il gestore eventi del lato server abbiano lo stesso nome, il gestore eventi del lato client verrà sempre eseguito prima del gestore eventi del lato server. Tuttavia, poiché questo scenario potrebbe generare confusione, si consiglia di stabilire una convenzione di denominazione.

Gestione di un evento Click in codice client e server

L'evento client onclick presenta alcune difficoltà qualora si desideri gestirlo sia sul client che sul server. Il problema è causato dal fatto che tutti i controlli server Button, oltre ad alcuni altri controlli la cui proprietà AutoPostBack è impostata su true, inviano la pagina al server. In HTML, tuttavia, solo alcuni controlli inviano effettivamente un form:

• Il pulsante di invio HTML (), ovvero il controllo HtmlInputButton con il tipo impostato su Submit o Image. È possibile aggiungere questo controllo dalla scheda HTML della Casella degli strumenti.
• Il controllo server Web Button ().

Per tutti gli altri controlli impostati per l'invio della pagina, viene scritto un breve script client nella pagina, che viene chiamato per inviare il form quando si da clic sul controllo. Pertanto, tali controlli utilizzano già l'evento OnClick del lato client per chiamare lo script di invio.

È possibile creare gestori OnClick del lato client per tutti i controlli, ma è necessario farlo in un modo che funzioni con ogni tipo di controllo. Nella tabella che segue sono riepilogate le strategie utilizzate per i differenti tipi di controlli.

onclick="clientfunction()"  ...>

onclick="clientfunction();"  ...>

Button1.Attributes.Add("onclick" , "clientfunction();")

Eventi a livello di applicazione e sessione

Oltre agli eventi di pagina e di controllo, il framework di pagine ASP.NET consente di utilizzare eventi che possono essere generati all'avvio o alla chiusura dell'applicazione o di una sessione utente:

• Gli eventi a livello di applicazione vengono generati per tutte le richieste passate a un'applicazione. Application_BeginRequest viene ad esempio generato quando viene richiesta una pagina Web Form o un servizio Web XML nell'applicazione. Questo evento consente di inizializzare le risorse da utilizzare per ciascuna richiesta all'applicazione. Un evento corrispondente, Application_EndRequest, consente di chiudere o eliminare le risorse utilizzate per la richiesta.
• Gli eventi a livello di sessione sono simili agli eventi a livello di applicazione (sono disponibili gli eventi Session_Start e Session_End), ma vengono generati con ogni singola sessione all'interno dell'applicazione. Una sessione inizia quando un utente richiede una pagina per la prima volta all'applicazione e termina quando l'applicazione chiude in modo esplicito la sessione o quando si verifica il timeout della sessione.