I'm going to continue digging into the UpdatePanel control since the last post I made on this subject, so if you haven't read it, I would recommend doing so first...

The UpdatePanel is a wonderful utility for quickly taking a non-Atlas'ized ASP.Net website and Atlas'izing it, as it empowers you to simply surround traditional controls with <atlas:UpdatePanel> tags to enable them for partial postbacks. However, UpdatePanels can be somewhat misleading too: most people fail to realize (at least I did at first) that the UpdatPanel itself does not post back to the server, instead it is updated on the client using clever DHTML tricks (all controls within an UpdatePanel are surrounded, on the client, by either a span or div tag which is easily identified and whose children are easily over-written and modified). What actually posts back to the server is the PageRequestManager control script which is aided by the dealings of the ScriptManager control on the server. This simple fact - that the UpdatePanel doesn't post back - is important to realize, especially when one begins to think in terms of setting up triggers to update the content of the UpdatePanel. It becomes more of a mindset shift, really...but one that's important to make....let me explain...

Triggers are client-side controls that give developers the ability to say, basically, "I want the content of the UpdatePanel to refresh when such-n-such happens". Out of the box, Atlas comes with two types of triggers: a ControlEventTrigger and a ControlValueTrigger, which "trigger" the update of the UpdatePanel when either a clientside event occurs (button click, etc.) or value changes (text box content) respectively. Asigning triggers to an UpdatePanel is simple and is done like the following:

            <atlas:UpdatePanel runat="server" ID="UpdatePanel3" Mode="Conditional">
                <Triggers>
                    <atlas:ControlEventTrigger ControlID="btnTrigger" EventName="Click" />
                </Triggers>
                <ContentTemplate>
                    <asp:Label runat="server" ID="lblTime2" /><br />
                </ContentTemplate>
            </atlas:UpdatePanel>

...Note the <Triggers></Triggers> tags and the encapsulated instance of the <atlas:ControlEventTrigger>. Again, what this says to the Atlas runtime is that when the control btnTrigger is Click'd that the UpdatePanel ought to have its controls refreshed. Since the <Triggers> control exists "within" the UpdatePanel control (parent/child relationship in the XML), you can see how one would think the UpdatePanel is responsible for doing all clientside postbacks. The result of thinking this way would lead you to think you could simply point to any control you wanted and hook any event you wanted and the UpdatePanel will blindly post back for you, updating the content. The truth is, however, that the UpdatePanel relies on other controls to start the postback sequence in motion; this postback sequence gets "intercepted" by the Atlas clientside framework and re-submitted as a specially formatted postback (for the Atlas serverside framework to deal with). So, let me reiterate this fact: the control that has the trigger attached must initiate the postback!

Why is this important? If the control doesn't start a postback on its own then 1) the browser won't try to postback, 2) the clientside framework won't intercept the postback event, and 3) the framework won't be able to re-submit the post as a partial one and allow the serverside framework to take over, and so forth. As programmatic proof, take a gander at this XML Script statement declaring the PageRequestManager on a page with UpdatePanels and triggers for those panels:

<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
  <components>
    <pageRequestManager id="_PageRequestManager" updatePanelIDs="Panel1,Panel2,Panel3" asyncPostbackControlIDs="AsyncPostBackButton,Panel3bButton" scriptManagerID="TheScriptManager" form="form1" />
  </components>
</page></script> 

Note the instance of the _PageRequestManager object of type pageRequestManager above between the <components> tags. It has a property, asyncPostbackControlIDs, whose value is a comma-delimited array of control names who, you guessed it, have triggers assigned to them from within UpdatePanels. When an event that triggers a postback is fired on the page, it goes through the follow method at one point in the client code base:

this._doPostBack = function(eventTarget, eventArgument) {
   ...
   _postbackSettings = null;
   var postbackElement = findNearestElement(eventTarget);
   if (postbackElement) {
      _postbackSettings = getPostbackSettings(postbackElement);
   }
   else {
      _postbackSettings = createPostbackSettings(true, _scriptManagerID);
   }
   if (!_postbackSettings.async) {
      _originalDoPostBack(eventTarget, eventArgument);
      return;
   }

   var form = _form;
   form.__EVENTTARGET.value = eventTarget;
   form.__EVENTARGUMENT.value = eventArgument;
   this._onFormSubmit(); 

   if (window.event) {
   window.event.returnValue = false;
   }
}

The _postbackSettings.async property holds a boolean value stating with (True) the control is flagged for partial postbacks or (False) it's not. A status of True is given to any clientside control within an UpdatePanel or pointed to by a trigger from within an UpdatePanel. If this boolean switch is False, then an old-style postback occurs (refreshing the entire page), else the _onFormSubmit method is called which spawns an asynchronous postback to the server, etc.

One final question exists, however - and that's how does the <PageRequestManager> gets its property values? Or, who sets the asyncPostbackControlIDs property on the <PageRequestManager> object for the page? The answer is the ScriptManager control when it renders on the server. After this control's PreRendering phase on the server, it calls the following method which, as you can see at the end, is responsible for setting the property names and values (the values were built using StringBuilder objects):

private void RenderPageRequestManager(ScriptTextWriter writer)
{
   GenericScriptComponent component1 = new GenericScriptComponent(new ScriptTypeDescriptor("pageRequestManager", ScriptNamespace.Default));
   component1.ID = ScriptManager.PageRequestManagerID;
   StringBuilder builder1 = new StringBuilder();
   if (this._allUpdatePanels != null)
   {
      for (int num1 = 0; num1 < this._allUpdatePanels.Count; num1++)
      {
         ...
         builder1.Append(",");
         ...
         builder1.Append(this._allUpdatePanels[num1].UniqueID);
      }
   }
   StringBuilder builder2 = new StringBuilder();
   if (this._asyncPostbackControls != null)
   {
      for (int num2 = 0; num2 < this._asyncPostbackControls.Count; num2++)
      {
         ...
         builder2.Append(",");
         ...
         builder2.Append(this._asyncPostbackControls[num2].ClientID);
      }
   }
   component1.AddValueProperty("updatePanelIDs", builder1.ToString());
   component1.AddValueProperty("asyncPostbackControlIDs", builder2.ToString());
   component1.AddValueProperty("scriptManagerID", this.UniqueID);
   component1.AddValueProperty("form", this._page.Form.ClientID);
   ...
}

Each trigger adds an entry for itself in theScriptManager's _asyncPostBackControls array when the control is being built and each trigger is being initialized on the server by its UpdatePanel.