Nel precedente articolo è stato esaminato in dettaglio il lato client del framework ASP.NET AJAX. In questo articolo viene illustrato il lato server e tutti i controlli in esso contenuti. Questi controlli si sono evoluti nel tempo ed ora rappresentano un ottimo compromesso tra performance, velocità e semplicità di sviluppo. Tra questi controlli ci sono l'UpdatePanel, l'UpdateProgress ed il Timer. Anche se molto utili, questi controlli non sono tutto ciò che il lato server offre. Esistono due Web Service che espongono un sottoinsieme delle Membership API e delle Profile API così come esiste la possibilità di invocare Web Service o metodi di una pagina direttamente da Javascript a costo quasi zero.

L'inizio: ScriptManager

Il controllo dal quale tutto ha origine è lo ScriptManager. Tutti i javascript necessari al colloquio asincrono e senza postback tra client e server vengono renderizzati sulla pagina grazie a questo controllo. Non solo, è sempre attaverso lo ScriptManager che si possono rendere visibili i Web Service o aggiungere nuovi javascript alla pagina. Inoltre molti comportamenti vengono definiti proprio tramite alcune proprietà di questo controllo come l'abilitazione del PartialRendering, il timeout di risposta del server, la possibilità di accedere a dati globalizzati o localizzati, ecc. Insomma ScriptManager rappresenta il cuore del framework server dal quale dipendono tutti gli altri controlli.

Quando si pensa ad AJAX, si pensa ad un livello di interazione utente notevolmente migliorato grazie alla soppressione dei postback ed all'uso di aggiornamenti parziali della pagina solo laddove serve. In ASP.NET AJAX questa evoluzione del modello di aggiornamento è stata definita PartialRendering ed è abilitata attraverso la proprietà booleana EnablePartialRendering. Il valore predefinito di questa proprietà è pari a true, quindi questo comportamento è abilitato di default.

Il controllo Javascript XMLHTTP, su cui AJAX in generale si basa, è supportato sulle ultime versioni di tutti i browser, ma nel mondo esistono ancora molte installazioni di vecchie versioni di browser dove l'oggetto non è ancora supportato. Non solo, sul browser potrebbe essere disabilitato l'uso di javascript. Queste situazioni portano all'impossibilità sfruttare il PartialRendering e quindi AJAX. Fortunatamente lo ScriptManager viene in aiuto con la proprietà SupportsPartialRendering che specifica se questa feature è abilitata sul client. Ovviamente, se il PartialRendering non è supportato, automaticamente la proprietà EnablePartialRendering viene impostata a false; tuttavia, anche se questa proprietà viene gestita automaticamente dal framework, la si può ugualmente impostare via codice in caso di necessità, ad esempio, per abilitare/disabilitare una particolare versione di un browser o una particolare tipologia di utenti o altro ancora.

Particolare attenzione è stata data anche alla gestione degli errori attraverso due proprietà fondamentali del controllo ScriptManager: AllowCustomErrorsRedirect e AsyncPostBackErrorMessage. La prima proprietà di tipo booleano permette di scegliere la modalità di gestione dell'errore durante una chiamata AJAX al server. Il comportamento predefinito prevede che, nel caso in cui la modalità di gestione personalizzata degli errori sia impostata a On nel web.config, si venga redirezionati automaticamente alla pagina di errore di default. In caso contrario viene semplicemente mostrato il messaggio di errore restituito da ASP.NET direttamente all'interno della pagina.

Quest'ultima opzione non è certo delle migliori sia per sicurezza che per eleganza ed è proprio per risolvere situazioni come queste che è stata introdotta la seconda proprietà. Tramite AsyncPostBackErrorMessage è possibile impostare il messaggio da visualizzare all'utente qualora si decida di utilizzare la classica finestra di alert come veicolo per segnalare l'errore.

La proprietà IsInAsyncPostBack di ScriptManager si rivela molto utile in un'ottica di ottimizzazione delle performance. Come il nome lascia intuire, questa proprietà indica se ci si trova nell'ambito di un postback asincrono o meno. Per dare un'idea dell'importanza di questa proprietà ci si può rifare al seguente scenario: nella pagina sono contenuti due controlli DropDownList, uno dentro ed uno fuori da un UpdatePanel, entrambi con ViewState disabilitato. Quando si cambia la selezione del controllo DropDownList all'interno dell'UpdatePanel, il postback che ne deriva è asincrono e questo significa che solo l'area all'interno dell'UpdatePanel cambia. Di conseguenza, non c'è bisogno di ricaricare il controllo DropDownList esterno in quanto questo non viene aggiornato. In senso ampio, testare la proprietà IsInAsyncPostBack permette di risparmiare tempo e risorse saltando elaborazioni inutili.

L'ultima proprietà "semplice" da prendere in considerazione è AsyncPostBackTimeout tramite la quale si decide la durata massima, espressa in secondi, di un postback AJAX. Allo scadere del timeout specificato, la chiamata viene interrotta lato client ed un messaggio di errore viene riportato tramite finestra di alert. É importante notare che in questa tipologia di errore le proprietà precedenti relative all'errore vengono ignorate poichè l'errore non viene intercettato lato server. Il valore di default del timeout è di 90 secondi, ma questo valore rappresenta in molte situazioni una quantità di tempo eccessiva (e anche dannosa), dal momento che per la maggior parte delle pagine di un'applicazione un intervallo di qualche secondo (10-15) è generalmente più che sufficiente.

Alla luce di quello che si è visto, si può dire senza ombra di dubbio che la configurazione ottimale per uno ScriptManager sia la seguente (alcuni valori sono così già di default, ma sono stati inclusi per completezza):

<asp:ScriptManager ID="ScriptManager1" runat="server" AllowCustomErrorsRedirect="True" AsyncPostBackErrorMessage="Errore generico. Contattare HelpDesk" AsyncPostBackTimeout="15" EnablePartialRendering="true"></asp:ScriptManager>

Come si è avuto modo di dire già nel corso del precedente articolo, una delle caratteristiche di ASP.NET AJAX è la semplicità con cui è possibile invocare Web Service direttamente dal client. Per fare questo, oltre a creare il Web Service ad hoc, occorre aggiungere un riferimento ad esso all'interno della pagina. Il punto più ovvio dove inserire questo riferimento è lo ScriptManager e, più precisamente, nella proprietà Services, che contiene l'insieme di tutti i riferimenti ai Web Service a cui la pagina deve accedere.

<asp:ScriptManager ID="ScriptManager1" runat="server">
  <Services>
    <asp:ServiceReference Path="~/MyService.asmx" />
  </Services>
</asp:ScriptManager>

Infine, lo ScriptManager è dotato di una serie di metodi per registrare javascript sulla pagina a seguito di un postback asincrono. Questi metodi servono in quanto la classe ClientScriptManager non è AJAX-aware e quindi qualunque script registrato tramite di essa durante un postback asincrono non viene poi realmente spedito al client. Anche i nomi dei metodi di ScriptManager sono praticamente gli stessi (RegisterClientScriptBlock, RegisterClientScriptInclude, RegisterHiddenField, ecc.). Lo stesso discorso per altri metodi come SetFocus che ha una corrispondenza sia su Page che su ScriptManager.

Il tramite: ScriptManagerProxy

Un aspetto importante da tener ben presente è che ci può essere un solo ScriptManager all'interno di una pagina. Qualunque tentativo di aggiungere un secondo elemento dello stesso tipo porta sempre alla stessa conclusione, cioè un'eccezione. Questa "finta" limitazione è piuttosto ovvia in quanto non ha molto senso avere più ScriptManager per pagina. Tuttavia, il contenuto di una pagina non sempre è presente in un unico file, anzi in molti casi è distribuito in file separati. Basta pensare, per esempio, ad una pagina a cui è associata una Master Page e che funge da contenitore per diversi User Control. Ciascuno di questi User Control non possono accedere direttamente alla pagina e quindi allo ScriptManager relativo, anche se potrebbe eventualmente presentarsi la necessità di eseguire un postback asincrono proprio all'interno di uno di essi. In situazioni come queste torna utile il controllo ScriptManagerProxy. In generale questo controllo funge da surrogato per l'oggetto ScriptManager contenuto in un diverso file. In questo modo tutte le tipologie di file associate ad una pagina possono accedere allo stesso ScriptManager senza doverne specificare uno, ma semplicemente utilizzando un riferimento ad esso.