Each Ajax-enabled web form must contain a single instance of the ScriptManager server control (if using MasterPages then this instance can just appear on the MasterPage), and it must be marked up before the controls that it manages. By default it is placed just beneath the form element, like this:
<form id="form1" runat="server">
<asp:ScriptManager ID="ScriptManager1" runat="server" />
The ScriptManager control has no visual impact, its purpose being simply to coordinate the various client-side and server-side Ajax functionality.
The ScriptManagerProxy control is used for web server controls or for pages which are embedded in MasterPages. It stands as proxy for the real ScriptManager which will be present on the page the control is embedded in.
After the ScriptManager control, the primary Ajax control is the UpdatePanel. This supports functionality known as ‘Partial Page Update’, whereby any controls placed within an UpdatePanel can be made to update visually in isolation from any other controls, and do so asynchronously (ie. without a visible page refresh). So, for instance, you might have the latest stock values within an update panel, set to periodically update, while on another part of the page the user fills out a form.
Let’s dig into this slightly more. Suppose that we have two standard ASP.NET Server controls, a Label and a Button, embedded within an UpdatePanel:
|
Because the button is within the scope of the UpdatePanel, clicking on it triggers a Partial Page Update rather than a standard post back. Under the covers, this partial update is organised thus:
- a client-side script uses an XmlHttpRequest object to make a POST request back to the server, passing back all the page form data.
- on the server, the page goes through its full lifecycle (so, for instance, server-side events which involve elements outside the UpdatePanel get fired).
- having run through its lifecycle, the page then passes back to the calling XmlHttpRequest i) the HTML for the UpdatePanel, rather than the full page; ii) updated ViewState data.
- the client-side script then switches the UpdatePanel’s HTML for the new HTML and replaces the old ViewState with the new.
In terms of our example, the text within the Label, as well as any changes to the Button, would get passed back to the page.
It is worth noting that it is also possible to wire up UpdatePanels to button presses (and other events) from objects which are not contained within the UpdatePanel. This is achieved by setting the Triggers property of the UpdatePanel to contain the IDs of the triggering objects and the names of the triggering events.
The UpdateProgress control is used to display to the user that an UpdatePanel (identified via its AssociatedUpdatePanelID property) is in the process of updating. This is particularly useful for controls which involve user input. For example, suppose that we have a DropDownList which dynamically updates based upon some user input on the page (eg. a choice between radio buttons). If there could be a significant latency in getting back the dropdown HTML from the server, we should give the user some kind of sign that it is updating, otherwise he may start to use the outdated dropdown, or else get confused about what he is supposed to do.
What kind of sign that progress is happening is given to the user is left up to the developer – the UpdateProgress element is just a panel which takes controls within itself and shows itself at the appropriate time. It contains a number of properties which can tweak its behaviour - for instance DisplayAfter, which sets a time in milliseconds before it shows itself.
The Timer control causes an UpdatePanel to update on a schedule, after the number of milliseconds specified by its Interval property. As with Buttons, when the Timer is embedded within an UpdatePanel it causes the containing UpdatePanel to update. Alternatively, UpdatePanels can subscribe to the Timer’s Tick event by setting appropriate properties in their Triggers collection.