ScriptManager class is the heart of ASP.NET Ajax. Before elaborating more on ScriptManager, note that ScriptManager is class and a control (both) in Ajax.
The ScriptManager class in ASP.NET manages Ajax Script Libraries, partial page rendering functionality and client proxy class generation for web applications and services. By saying client proxy class, this means an instance of the Ajax runtime is created on the browser.
This class is defined in the System.Web.Extensions.dll. You will find this DLL in your system’s Global Assembly Cache at C:\Windows\Assembly (For XP)
The ScriptManager control (that we may drag on a web form) is actually an instance of the ScriptManager class that we put on a web page. The ScriptManager manages all the ASP.NET Ajax controls on a web page. Following tasks are taken care by the ScriptManager class:
Essentially, a true AJAX application uses the XMLHttpRequest object to bypass the browser and establish direct communication with the Web server and any hosted HTTP endpoints. The application is capable of asynchronously retrieving necessary data and independently refreshing blocks of the user interface. Based on this key behavior, a number of AJAX frameworks have been designed that have different doses of syntactic sugar, larger or smaller feature sets, and richer or simpler families of user interface widgets. ASP.NET AJAX is one of these frameworks.
A canonical example to illustrate the power of the AJAX approach is an application that retrieves stock quotes in real time. The non-AJAX Web sites that offer this feature today are using either meta-refresh tags or a plugin-based approach such as Flash, Silverlight™, or ActiveX® controls. Typically, the list of stock values to display is bound to a server-side grid control, and the grid is then refreshed with the rest of the page with the next postback or page request. A page like this can be quickly enhanced with a sprinkle of partial rendering. Let’s see how. The markup in Figure 1 wraps a grid control in an UpdatePanel control that is periodically refreshed by a Timer control.
How would a pure AJAX approach affect the design of a live quote page?
Firstly, the invoked URL is not the page itself. The page invokes an HTTP endpoint backed by a scriptable Web or WCF service. There’s no page lifecycle, no postback events, no view state restoration. As a result, network traffic is significantly reduced.
FRONT END AND BACK END CODE SPLIT AND VIEW MODEL
In partial rendering, there’s no natural separation between the user interface elements (the view) and the core application logic (the model).
SEPARATION LEADS TO BETTER CACHING
CLIENT SIDE CONTROL SUPPORT AND TEMPLATING REQUIRED
Unfortunately, there’s no client-side GridView control as there is in the server-based ASP.NET approach. You need a form of client-side data binding, preferably with some templating support. Currently, ASP.NET AJAX is not of much help here. For further explanation on this topic, straight from the Microsoft ASP.NET team, see the sidebar, “Insights: ASP.NET AJAX.”
BROWSER SIDE TEMPLATING PATTERN
Let’s start from this last point to explore the ways in which you can build your own small but effective data binding and templating framework. Note that the final output has to be a string of HTML markup. The initial input is a collection of objects with a few public properties. Your job is to build a piece of HTML that fulfills the user’s expectations. Generally, you start by looping over the bound collection and concatenating the template’s text with the value of the object’s properties.
What’s wrong with this approach? Actually, nothing is wrong with this approach. In fact, there’s no radically different approach that I can think of that doesn’t do the exact same thing at some point. This means that you can certainly create a framework that abstracts this basic routine. In the catalog of AJAX patterns (see http://www.ajaxpatterns.org), the key steps for defining a client-side templating model go under the name Browser-Side Templating pattern (BST).
The markup builder returns an HTML string based on a reference to one or more HTML templates in the page document object model (DOM) and the downloaded data. Finally, the callback injects the string in the page’s DOM.
VIEW STATE CONSISTENCY IS NOT REQUIRED
What’s the point? Remember that with partial rendering, you can only have one request pending at a time per session—just like in a normal non-AJAX page. Of course, you can have any number of simultaneous calls if you control them directly through XMLHttpRequest. Furthermore, if you make direct service calls, you have no view state around and no worries about keeping it consistent across multiple partial rendering calls (which is the real reason why the partial rendering implementation prevents you from executing concurrent operations).
The HTML Message Pattern
To top off this column, let me just make a quick comment on another pattern that really deserves more attention in a future column—it’s called the HTML Message pattern. The goal of the HTML Message pattern is to have the server generate blocks of HTML markup to be displayed in the browser. As you can see, it falls somewhere between partial rendering and other models for building true AJAX applications.
AJAX Service Layer
I’ll refer to the server-side part of a typical AJAX presentation layer as the AJAX service layer to distinguish it from the service layer that generally represents the point of contact between the presentation and middle tier in a standard multitier architecture. Figure 1 illustrates the model.
PARTIAL RENDERING ALLOWS CONTROL BASED DESIGN
Partial rendering preserves the view state and server page lifecycle and allows you to declaratively design the user interface using controls and properties.
DATA TO THE FRONT END HTML TRANSFORM
Solutions for Now