Ever since the advent of the Internet, Web applications have lagged behind desktop applications in terms of interactivity and responsiveness. One of the biggest drawbacks in the conventional Web model has been the cycle of inactivity between the user request and the server response. Reducing this period of inactivity has been the point of focus for any developer who wants to improve the responsiveness of Web applications and raise the user experience to levels offered by desktop applications.

AJAX (Asynchronous JavaScript and XML) is one of the approaches that help Web developers improve the responsiveness and interactivity of Web applications. As the name suggests, it works by having asynchronous communication between the browser and the server thereby doing away with the need to re-create the entire page, and reducing the response time that translates into better interactivity. However implementing AJAX may not be easy since it involves writing a lot of code in a client-side scripting language like JavaScript and any developer who has worked with one would attest to the fact that developing and debugging complicated client scripts can sometimes be daunting. It can be even more daunting to maintain Web applications where the logic is interspersed between client and server code.

The Atlas framework from Microsoft promises to fill this gap and make it easier for the ASP.NET developer to easily develop interactive AJAX-enabled applications. In this article we'll look at what ATLAS is and focus on the server controls that an ASP.NET developer can use to "AJAX-ify" his applications.

What Is Microsoft Atlas?
Atlas is Microsoft's flavor of AJAX. It offers a comprehensive platform that marries client-scripting functionality with ASP.NET server-side features. Atlas promises to provide the AJAX capabilities minus the complexity associated with developing AJAX applications Atlas offers two sets of components, one for client-side functionality and another that offers server-side functionality.

On the client side, Atlas offers the following:

• A consistent set of APIs that adds object-oriented features to JavaScript such as Namespaces and type system which are very similar to the .NET Framework and let .NET developers easily develop in JavaScript
• Built-in browser compatibility. The libraries handle browser compatibility and there is no need to write browser-specific versions.
• An XML-based declarative syntax that lets developers do client-side scripting and easily attach Atlas behaviors to existing HTML elements.

Atlas also lets the developer integrate ASP.NET services like Profiles, membership roles, and personalization from the client-side script. All these translate into much better productivity for the ASP.NET developer.

Atlas Server Controls
Event though Atlas client-side bits expose a wide variety of functionality, I feel that it's the serve- side functionality and controls that endear it to the ASP.NET developer as they automatically emit all the client script needed for the AJAX functionality. For an ASP.NET developer used to doing server-side development these controls are a natural choice since they eliminate the need to master the new XML-based side-scripting model and write client-side scripts. They offer the easiest way to build rich user experiences because these controls are based on a programming model that's already familiar to the ASP.NET developer.

Another major advantage of using server controls is that the core application logic would still be on the server side. This means that a developer can go back and easily add Atlas/AJAX functionality to an existing ASP.NET 2.0 application. Out of the different Atlas server controls, two of them stand out, the Script Manager and Update Panel controls.

Script Manager
This control is single-handedly the most important Atlas server control and as the name suggests manages the different script pieces needed on an Atlas-enabled page. Every page that uses Atlas server controls should have one instance of the Script Manager. First and foremost what the ScriptManager does is to register the core script file needed for Atlas functionality.

<atlas:ScriptManager runat="server" ID="smgr1"
    EnableScriptComponents="True" EnablePartialRendering="True">
<ErrorTemplate>
      <span id="errorMessageLabel" runat="server"></span>
      <input id="okButton" type="button" value="OK" runat="server" />
    </ErrorTemplate>
   <Scripts>
    <atlas:ScriptReference ScriptName="AtlasUIMap" />
    <atlas:ScriptReference Path="~/MyScripts/MyScript.js" />
   </Scripts>
   <Services>
    <atlas:ServiceReference Path="ComplexService.asmx" />
   </Services>
</atlas:ScriptManager>

The code snippet above shows the markup of a ScriptManager. As you can see, the ScriptManager control exposes a set of attributes and elements that lets us define its functionality. Let's take a closer look at them.

1.  EnablePartialRendering - Setting this to true controls how the page is rendered and lets specific parts of the page content be updated instead of the whole page during post backs. In fact for most AJAX functionality to work, it has to be set to true.

2.  EnableScriptComponents - This attribute defines how the ScriptManager references scripts. If set to true, the ScriptManager automatically references other Atlas scripts that help provide UI behaviors. Some UI behavior scripts are AtlasUIDragDrop and AtlasUIglitz. However if set to false, it only downloads the scripts that are needed for Atlas's core functionality.

3.  ScriptReference - Instead of relying on automatic script registration, it's also possible to selectively reference and register scripts by using a collection of ScriptReferences. The ScriptReference object exposes three attributes, namely the ScriptName, Path, and Browser. ScriptName defines the name of the script being referenced. ScriptName can either be one of the pre-set Atlas script names like AtlasUIDragDrop or AtlasUIGlitz or it can be a custom script that the developer wants to register. If the ScriptName is set to one of the pre-set Atlas script names, it's automatically referenced. To reference a custom script the ScriptName is set to "custom" and the path of the script file has to be specified. The Browser attribute is used to specify the browser where the script will be downloaded.

4.  ServiceReference - ServiceReference is similar to ScriptReference, but it's used to register Web Services that may be used in the page. ServiceReference exposes three attributes: the Path that defines the path of the service, the GenerateProxy that decides if a proxy is generated for the referenced service, and the Type attribute used to reference the Web Service by type name.