ASP.NET AJAX

jQuery e ASP.NET Ajax: $(document).ready() VS asynchronous postback

Dario Santarelli — Mon, 09 Mar 2009 22:58:18 GMT

Molto spesso capita di dover integrare, anche solo per semplici miglioramenti grafici, dei plugin jQuery all’interno delle nostre pagine ASP.NET. Gran parte delle volte l’impatto è indolore mentre in alcuni casi specifici occorre far riferimento ad accorgimenti non banali, soprattutto quando c’è di mezzo ASP.NET Ajax.
Il classico esempio si verifica quando ci si aspetta che la funzione $(document).ready() venga chiamata correttamente anche dopo un asynchronous postback tramite UpdatePanel. Infatti, la funzione $(document).ready() permette di determinare il momento in cui il DOM della pagina è caricato dal browser. Tuttavia, in caso di asynchronous postback il DOM può essere eventualmente modificato e non ricaricato nuovamente. Quindi il nostro codice javascript nella forma:

$(document).ready(function()
{
// codice...
});

... non verrà eseguito!
Un workaround molto semplice per questo tipo di situazione è quello di sfruttare l’evento client-side endRequest generato dopo un postback asincrono, quando il controllo viene restituito al browser. Agganciando il nostro codice jQuery che usa $(document).ready() all’interno di un opportuno event Handler per tale evento possiamo risolvere il problema. Ecco un semplice esempio:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>jQuery .ready() function and asynchronous postback</title>
</head>
<body>
<form id="mainForm" runat="server">
<div>
    <asp:ScriptManager ID="scriptManager" runat="server">
      <Scripts>
       <asp:ScriptReference Path="http://code.jquery.com/jquery-latest.js" />
      </Scripts>
    </asp:ScriptManager>
    <asp:UpdatePanel ID="updatePanel" runat="server">
      <ContentTemplate>
         <asp:Button ID="btnTest" runat="server" Text="Do Async PostBack" />
      </ContentTemplate>
    </asp:UpdatePanel>
   </div>
</form>

Technorati Tag: jQuery,ASP.NET,Ajax,DOM

Caricamento dinamico di UserControl via jQuery Ajax e HttpHandler

Dario Santarelli — Sun, 21 Dec 2008 20:57:48 GMT

In applicazioni Web di una certa complessità, spesso le classiche tecniche di caricamento dinamico di UserControl tramite PostBack o UpdatePanel rischiano di rendere lo sviluppo delle pagine molto complesso nonché, cosa più pericolosa, non performante. Di certo uno scenario maggiormente flessibile dovrebbe anzitutto ridurre al minimo il traffico da/verso il server (vedi "UpdatePanel e i suoi abusi") ma soprattutto permettere di richiedere il caricamento di contenuti on-demand sfruttando la potenza di AJAX.
In questo esempio voglio mostrare quanto sia semplice implementare un' infrastruttura di base che permetta il caricamento dinamico di UserControl tramite jQuery AJAX (client-side) e un HttpHandler (server-side). In breve:

Il client richiede all'HttpHandler uno UserControl con una richiesta JSON
L'HttpHandler processa la richiesta inizializzando solo lo UserControl desiderato ed inviando al client solo l' (X)Html di rendering dello UserControl
Il client posiziona l' (X)Html ricevuto in una zona specifica della pagina

Ovviamente esistono altri modi per creare dinamicamente UserControl con AJAX (es. tramite WebService), ma per brevità tralasciamo volutamente questo aspetto.

1. Il DataContract della richiesta
Anzitutto abbiamo bisogno di una classe che faccia da DataContract per la richiesta di uno UserControl. In particolare, la proprietà ControlParameters permette di specificare degli eventuali parametri da passare allo UserControl per pilotarne il corretto comportamento.

[DataContract]
public class ControlRequest
{
[DataMember]
public string ControlName { get; set; }

[DataMember]
public Dictionary<string, string> ControlParameters { get; set; }
}

2. HttpHandler
Server-side abbiamo un HttpHandler che deserializza le richieste JSON conformi al DataContract sopra specificato per caricare ed inizializzare correttamente (tramite reflection) lo UserControl richiesto. Il codice si commenta quasi da solo :D

public class UserControlHandler : IHttpHandler
{
public void ProcessRequest (HttpContext context)
{
    // 1. Deserializzazione della richiesta JSON
    DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(ControlRequest));
    ControlRequest controlRequest = serializer.ReadObject(context.Request.InputStream) as ControlRequest;

// 2. Caricamento dello UserControl
    Page page = new Page();
    UserControl userControl = (UserControl)page.LoadControl("~/Controls/" + controlRequest.ControlName + ".ascx");
    userControl.EnableViewState = false;

   // 3. Inizializzazione dei parametri dello UserControl via Reflection
    SetControlParameters(controlRequest, userControl);

    // 4. Esecuzione dello UserControl all'interno di un form
    HtmlForm form = new HtmlForm();
    form.Controls.Add(userControl);
    page.Controls.Add(form);

    StringWriter textWriter = new StringWriter();
    HttpContext.Current.Server.Execute(page, textWriter, false);

// 5. Invio dell'html di rendering dello UserControl (senza il form contenitore)
    context.Response.ContentType = "text/html";
    context.Response.ContentEncoding = System.Text.Encoding.UTF8;
    context.Response.Write(Regex.Replace(textWriter.ToString(), @"<[/]?(form)[^>]*?>", string.Empty, RegexOptions.IgnoreCase));
}

private void SetControlParameters(ControlRequest request, UserControl userControl)
{
    foreach (string parameterName in request.ControlParameters.Keys)
    {
      PropertyInfo property = userControl.GetType().GetProperty(parameterName);
      if (property != null) property.SetValue(userControl, request.ControlParameters[parameterName], null);
    }
}

...
}

Let's try!!!
Supponiamo di avere nella nostra soluzione uno UserControl CustomersGridView.ascx il cui codebehind include la complicatissima logica per popolare e filtare la classica griglia di Customers.

public partial class CustomersGridView : System.Web.UI.UserControl
{
public string FilterExpression { get; set; }

protected void NorthwindSqlDataSource_Selecting(object sender, SqlDataSourceSelectingEventArgs e)
{
e.Command.Parameters["@ContactName"].Value = FilterExpression;
}
}

Come possiamo notare la proprietà FilterExpression esposta serve proprio per determinare il filtraggio dei customer in fase di popolamento della GridView.
A questo punto non rimane che creare la nostra pagina di test:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" 
         EnableViewState="false" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Dynamic UserControl Loading via jQuery Ajax and HttpHandler</title>
</head>
<body>   
    <form id="form1" runat="server">
     <asp:ScriptManager ID="scriptManager" runat="server">
        <Scripts>
            <asp:ScriptReference Path="~/scripts/jquery-1.2.6.pack.js" ScriptMode="Release" />
            <asp:ScriptReference Path="~/scripts/jquery.json-1.3.min.js" ScriptMode="Release" />
        </Scripts>
    </asp:ScriptManager>
    <div>                
        ContactName: 
        <input id="txtCustomer" type="text" /> 
        <input type="button" value="Search" onclick="SearchCustomer()" />
        <br /><br />
    </div>
    <div id="testDiv"></div>
    </form>
    <script type="text/javascript">
        function getData(request) 
        {           
            $.ajax
            ({
                type: "POST",
                contentType: "application/json; charset=utf-8",
                url: "UserControlHandler.ashx",
                data: $.toJSON(request), // Uso del plugin jquery.json                                               
                success: function(msg) { $('#testDiv').html(msg); }, // 'testDiv' viene popolato con l'Html di rendering dello UserControl
                error: function(XMLHttpRequest, textStatus, errorThrown) { alert("Error Occured!"); }
            });
        }

        function SearchCustomer()
        {
            var filterExpression = $('#txtCustomer').val();
            var request = {ControlName:'CustomersGridView',ControlParameters:[{Key:'FilterExpression',Value:filterExpression}]};                  
            getData(request);
        }        
    </script>
</body>
</html>

Al click del button "Search" viene invocata la function SearchCustomer() che inizializza la stringa JSON da inviare all' HttpHandler, specificando il nome dello UserControl desiderato (CustomersGridView) ed i parametri richiesti (FilterExpression). Viene quindi invocata la funzione getData(...) che si occupa di gestire la comunicazione AJAX con l' HttpHandler. Infine, l' Html di rendering dello UserControl CustomersGridView viene posizionato all'interno del div "testDiv" della pagina.

Technorati Tag: jQuery,AJAX,HttpHandler,JSON

[ASP.NET AJAX] UpdatePanelPopupExtender

Dario Santarelli — Mon, 15 Dec 2008 18:50:17 GMT

Un controllo AJAX molto "cool": UpdatePanelPopupExtender.

Si tratta di un ASP.NET AJAX extender che può essere agganciato ad un UpdatePanel in modo tale che quest'ultimo appaia dietro ad un qualsiasi controllo che specifichiamo come PopUp.

In questo post vengono evidenziati alcuni interessanti scenari che si possono implementare con questo controllo:

Master Details
Master Multiple Details
AJAX search

Un grazie a Manuel per la segnalazione.

Technorati Tag: ASP.NET AJAX

[ASP.NET AJAX] Modal Progress con jQuery

Dario Santarelli — Mon, 27 Oct 2008 13:45:26 GMT

In questo post viene mostrato un utilizzo del jQuery BlockUI plugin per visualizzare un Modal Progress personalizzato durante il partial postback di un UpdatePanel. Il risultato che si può ottenere con questo approccio è ad esempio il seguente:

Molto interessante :)

Technorati Tag: AJAX,jQuery

[ASP.NET AJAX] Accesso sicuro al DOM

Dario Santarelli — Tue, 12 Aug 2008 15:31:44 GMT

Un po' di tempo fa mi sono imbattutto in un post dell' IEBlog in cui viene mostrato come l'aggiunta "prematura" di elementi al DOM tramite javascript ( ovvero prima che il parser rilevi la corretta chiusura del tag padre dell'elemento aggiunto dinamicamente ) può indurre IE7 alla visualizzazione di un messageBox "Operation aborted" che preclude addirittura la visualizzazione della pagina. Viceversa, se il DOM viene acceduto "troppo tardi" - ad esempio per nascondere degli elementi della pagina come immagini o oggetti embedded - si possono ottenere degli effetti indesiderati di lampeggiamento ("flickers"). Dunque, sorge spesso il dubbio circa quando e come modifcare il DOM della pagina in base al browser per evitare inconsistenze/risultati non ottimali. Certamente la questione non è banale!
Anzitutto, modificare il DOM dopo che si è scatenato l'evento window.onload costituisce un'operazione sicura, ma talvolta ci troviamo di fronte all'esigenza di non poter attendere il completo caricamento della pagina (DOM + oggetti) in quanto può avvenire troppo tardi rispetto alle nostre esigenze: potremmo infatti desiderare che il nostro script venga eseguito subito dopo che il DOM viene parserizzato dal browser ma prima che le immagini vengano scaricate.
Prima di vedere come questo scenario sia gestito automaticamente (e in maniera cross-browser) dal framework client-side di ASP.NET AJAX, spendiamo un attimo due parole sull' attuale supporto fornito dai principali browser per la manipolazione client-side del DOM.

Firefox, Opera e Safari prevedono un evento DOMContentLoaded che viene scatenato subito dopo il caricamento del DOM ma immediatamente prima del download dei vari oggetti della pagina. Quindi, l'unica cosa da fare è aggiungere un EventListener per l'evento DOMContentLoaded e il gioco è fatto.

if (document.addEventListener)
{
document.addEventListener("DOMContentLoaded", function() {
// Codice che accede al DOM in maniera sicura...
}, false);
}

Internet Explorer (almeno fino alla versione 7) non rende la vita così semplice, in quanto l'evento DOMContentLoaded non è supportato. Siamo dunque costretti ad affidarci a qualche workaround che lo emuli. Nello specifico, i due workaround più conosciuti sono:

utilizzare l'attributo defer nel tag script: <script type="text/javascript" defer="defer" src="onload.js" />
implementare un meccanismo di controllo alternativo come questo per attendere il corretto caricamento del DOM.

In framework client-side di ASP.NET AJAX invece risolve il problema alla radice!
Anzitutto, per ovvi motivi non è prevista alcuna ottimizzazione dedicata ad un browser specifico (es. agganciamento dell'evento DOMContentLoaded a seguito dello sniffing del browser), tuttavia l'inizializzazione dei vari componenti viene sempre eseguita dopo il caricamento del DOM. Come avviene tutto questo? Vediamo.
Nel codice sorgente dell' AJAX Library viene definita una classe Sys.Application che viene istanziata automaticamente in ogni pagina:

Sys.Application = new Sys._Application();

Il costruttore _Application() al suo interno include il seguente codice:

Sys.UI.DomEvent.addHandler(window, "load", this._loadHandlerDelegate);
Sys.UI.DomEvent.addHandler(window, "unload", this._unloadHandlerDelegate);

La prima istruzione aggancia l'evento Application.load all'evento window.load del browser mentre la seconda istruzione associa l'evento Application.unload all'evento window.unload. Dunque, quando viene scatenato l'evento window.load viene invocato il metodo _loadHandlerDelegate() di ASP.NET AJAX, il quale a sua volta invoca il metodo _Application.initialize():

function Sys$_Application$initialize()
{
if(!this._initialized && !this._initializing)
{
this._initializing = true;
window.setTimeout(Function.createDelegate(this, this._doInitialize), 0);
}
}

A cosa serve l'ultima istruzione window.setTimeout(...)? Da quanto ho avuto modo di apprendere, impostare l'invocazione di un metodo a seguito di un timeout di 0 millisecondi forza il browser ad eseguire la funzione prima possibile. In questo caso, si suppone che il metodo _doInitialize venga eseguito dopo che il DOM viene caricato ma prima che venga scaricato il contenuto binario di immagini, oggetti flash/silverlight etc. In questo modo il runtime di javascript non permette lo scadere del timeout e forza l'esecuzione di _doInitialize finché il DOM non sarà completamente caricato.
Di conseguenza il metodo _doInitialize verrà eseguito solo quando sarà sicuro modificare il DOM e nello stesso tempo ci preserverà dall'attesa della completa esecuzione dell' evento window.load (il quale - ricordiamolo ancora - attende il download degli oggetti binari nella pagina).

In conclusione, ASP.NET AJAX fornisce un proprio meccanismo analogo al DOMContentLoaded che permette il corretto accesso al DOM indipendentemente dal browser utilizzato. A questo punto la domanda finale è: dove viene posizionata la chiamata Sys.Application.initialize() ?
Lo ScriptManager si prenderà cura di posizionarla appena prima della chiusura del tag </form> in fondo alla pagina, assumendo ovviamente che non ci siano altri script "a rischio" dopo di esso.

Technorati tags: AJAX, DOM

AjaxControlToolkit v1.0.10606: uno strano comportamento del ModalPopupExtender

Dario Santarelli — Wed, 13 Jun 2007 18:01:00 GMT

Vorrei segnalare uno strano comportamento della nuova versione del ModalPopupExtender che ho avuto modo di notare proprio oggi nell' ultima release di AjaxControlToolkit.
Supponiamo di avere il seguente scenario, in cui ci sono due ModalPopupExtender aventi TargetControlID diversi ma lo stesso PopupControlID:

...
        <asp:Panel ID="MyTestPanel" runat="server">
            My content...<br /><br />
            <asp:Button ID="OKButt" runat="server" Text=" OK " />            
            <asp:LinkButton ID="Close_LB" runat="server" Text="Chiudi"></asp:LinkButton>
        </asp:Panel>
        <asp:LinkButton ID="ShowPanel1_LB" runat="server" Text="Show1"></asp:LinkButton>
        <asp:LinkButton ID="ShowPanel2_LB" runat="server" Text="Show2"></asp:LinkButton>
                
         <ajax:ModalPopupExtender ID="ModalPopupExtender1" runat="server"
            TargetControlID="ShowPanel1_LB"
            PopupControlID="MyTestPanel" 
            OkControlID="OKButt"
            CancelControlID="Close_LB" 
            DropShadow="true" />     
            
         <ajax:ModalPopupExtender ID="ModalPopupExtender2" runat="server" 
            TargetControlID="ShowPanel2_LB"
            PopupControlID="MyTestPanel" 
            OkControlID="OKButt"
            CancelControlID="Close_LB" 
            DropShadow="true" />     
...

Con la nuova versione del controllo, al momento del click su uno dei due TargetControlID viene scatenata dal framework client-side la seguente eccezione:

"Sys.InvalidOperationException: Two components with the same id '<nomePanel>$DropShadowBehaviour' can't be added to the application."

Come si può intuire immediatamente, si tratta di un problema legato alla proprietà DropShadow del ModalPopupExtender. Infatti, se la si imposta a "false", automaticamente tutto torna a funzionare correttamente.
Nei prossimi giorni dovrò cercare di trovare una spiegazione plausibile a questo problema, anche perché sono rimasto veramente amareggiato dal fatto che nella release precedente questo scenario era supportato e funzionante (come logicamente è normale che sia).

Forzare l'Update() di un UpdatePanel tramite un evento Javascript... una scelta corretta?

Dario Santarelli — Fri, 04 May 2007 00:54:00 GMT

Oggi mi è stato chiesto a bruciapelo (cito testualmente) "...un modo per eseguire il refresh di un UpdatePanel tramite un evento javascript (ad esempio onblur di un input text)...".
Se ci pensiamo bene, questo tipo di scelta implementativa va "filosoficamente" contro i principi di AJAX. Infatti (assumendo che il browser supporti Javascript :)), è maggiormente corretto utilizzare il più possibile le API AJAX del framework client-side per gestire il comportamento dei controlli client-side, al fine di evitare round-trip dispendiosi e spesso inutili verso il server (uno degli obiettivi primari di AJAX, d'altronde, è proprio questo :)).
Si pensi al caso di un' invocazione di un Web Service: gestirla direttamente tramite il framework lato client permette di risparmiare un round-trip!
Potremmo discutere sulla questione all'infinito...;)
Ad ogni modo, una soluzione veloce al problema potrebbe consistere nel forzare da Javascript il PostBack della pagina nei confronti di un controllo impostato come Trigger del nostro UpdatePanel. Come controllo potremmo usare ad esempio un HiddenField:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Test UpdatePanel 'OnBlur' su Input Text</title>
    <script type="text/javascript">
         function postBackHF(hiddenFieldID)
         {
            var hiddenField = $get(hiddenFieldID);
            if (hiddenField)
            {
              hiddenField.value = (new Date()).getTime();
              __doPostBack(hiddenFieldID,'');
            }
         }
    </script>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <h1>Test UpdatePanel 'OnBlur' su Input Text</h1>

        <asp:ScriptManager ID="TestScriptManager" runat="server" />
        <asp:UpdatePanel ID="UpdatePanelTest" runat="server" UpdateMode="Conditional" ChildrenAsTriggers="False">
            <ContentTemplate>
                <div style="background-color: #FFFF00; padding: 10px;">
                  <h2>UpdatePanel</h2>
                 <input type="text" id="testTB" value="Scatena l'OnBlur..."
                        onblur="postBackHF('<%=HiddenFieldTest.ClientID %>')" />
                    <br />
                    <asp:HiddenField ID="HiddenFieldTest" runat="server" />
                    <asp:Label ID="Outputlbl" runat="server" Text="Label"></asp:Label>
                </div>
            </ContentTemplate>
            <Triggers>
                <asp:AsyncPostBackTrigger ControlID="HiddenFieldTest" EventName="ValueChanged" />
            </Triggers>
        </asp:UpdatePanel>
    </div>
    </form>
</body>
</html>

E nel CodeFile...

...
protected void Page_Load(object sender, EventArgs e)
{
   if(IsPostBack)
   {
     Outputlbl.Text = "UpdatePanel Refreshed: " + DateTime.Now.ToString();
   }
}
...

Come si può osservare, all'occorrenza dell' evento "onblur" della nostra textbox, andiamo a cambiare il valore lato client del nostro HiddenField di appoggio. Quindi, forziamo il __doPostBack() in modo da scatenarne, lato server, l'evento ValueChanged, ovvero il Trigger che invocherà automaticamente il metodo Update() del nostro UpdatePanel.
In questo caso si è scelto di impostare l'evento ValueChanged dell' HiddenField come AsyncPostBackTrigger in quanto la proprietà ChildrenAsTriggers dell'UpdatePanel è impostata su "False". E' chiaro che si può pensare di implementare questo scenario in tanti altri modi diversi :)...

Usare lo ScriptManager per determinare quale controllo run-time ha causato un evento in AsyncPostBack

Dario Santarelli — Mon, 30 Apr 2007 00:55:00 GMT

Spesso nelle nostre applicazioni ASP.NET ci troviamo di fronte all'esigenza di aggiungere controlli in fase di run-time in modo da rendere completamente dinamico il comportamento delle nostre pagine. Ultimamente mi sono scontrato con la necessità di utilizzare questa tecnica all'interno del controllo UpdatePanel di ASP.NET AJAX.
Anzitutto, è importante precisare come non sia possibile aggiungere controlli direttamente nell'UpdatePanel (non possiamo quindi fare una cosa di questo tipo: MyUpdatePanel.Controls.Add(...)). Siamo quindi vincolati a prevedere dei container (es. Panel) da collocare nel ContentTemplateContainer dell' UpdatePanel per procedere all'aggiunta dei nostri controlli.
Uno dei modi più veloci e funzionali per poter poi riuscire a determinare quale controllo run-time all'interno dell' UpdatePanel ha generato un evento in modalità AsyncPostBack, sfrutta semplicemente l'oggetto Request della pagina relativamente allo ScriptManager dichiarato.
Andando in ordine, questa è una pagina di esempio:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>UpdatePanel con controlli Run-Time</title>
</head>
<body>
    <h1>UpdatePanel con controlli Run-Time</h1>
    <form id="form1" runat="server">
        <div>
            ID="MyScriptManager" runat="server" EnablePartialRendering="true" />
            ID="MyUpdatePanel" runat="server" UpdateMode="Conditional" RenderMode="Block">

                    ID="StatusLbl" runat="server"></asp:Label>
                    <br />
                    <br />
                    ID="ControlsPanel1" runat="server"></asp:Panel>
                    <br />
                    ID="ControlsPanel2" runat="server"></asp:Panel>
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>
    </form>
</body>
</html>

E questo è il relativo CodeFile.

   ...

protected void Page_Load(object sender, EventArgs e)
{
     AddMyControls(); // Aggiunta dei controlli alla Pagina

     if (MyScriptManager.IsInAsyncPostBack)
     {
       string MyScriptManagerRequest = Request[MyScriptManager.ID];

       // Visualizziamo il contenuto della richiesta dello ScriptManager
       StatusLbl.Text = MyScriptManagerRequest ;

       if (MyScriptManagerRequest.Contains("Button1"))
       {
          // Fai qualcosa...
       }
       else if (MyScriptManagerRequest.Contains("Button2"))
       {
          // Fai qualcosa...
       }
     }
}

private void AddMyControls()
{
   Button button1 = new Button();
   button1.ID = "Button1";
    ...
   Button button2 = new Button();
   button2.ID = "Button2";
    ...
   ControlsPanel1.Controls.Add(button1);
   ControlsPanel2.Controls.Add(button2);
}

...

Occorre porre attenzione al fatto che il contenuto di Request[MyScriptManager.ID] , ovvero la stringa nel POST Http corrispondente al nostro ScriptManager (MyScriptManager), contiene qualcosa del tipo "<ID UpdatePanel>|<ID Controllo>" (nel nostro caso ad esempio "MyUpdatePanel|Button1").
Possiamo quindi processare questa stringa per capire quale controllo ha causato il PostBack asincrono e quindi procedere con la nostra logica di business.