Learn More

• Introduction
• Key Features
• Online Samples
• Case Studies
• Customer Kudos

Getting Started

• Download
• Tutorials
• Extensions

Documentation

• Gaia TV
• API reference
• FAQ
• Forum
• Known issues
• How to report bugs

About Gaia Ajax

• Buy License
• Dual License
• About Gaiaware

Search

• All Pages
  
• New Page
  
• Categories
  

Whitepaper: Gaia Ajax

Why Gaia Ajax Is Not Just Yet another ASP.NET Library by Dino Esposito

Since 2001, ASP.NET made server controls a growingly popular tool for building effective and powerful Web sites and applications. In ASP.NET, a typical Web page is built as a combination of server controls that the developer arranges together to obtain the expected HTML markup. Because the server control is a sort of black-box with a programmable interface, a number of libraries came out over years to offer more and more powerful features that improved the base set of controls provided by ASP.NET. Today, ASP.NET component vendors are definitely an important part of the industry.

In more recent years, the advent of Ajax forced vendors to update their components to offer a family of server controls capable of leveraging the new emerging paradigm. At a relatively high level of abstraction, an Ajax server control is a component that emits HTML markup, plus some related JavaScript code. Microsoft is offering plenty of native Ajax support for the ASP.NET platform. However, only a few of the stock ASP.NET server controls can be fully considered Ajax server controls in the sense outlined above. Microsoft does provide an Ajax engine, but it is perceived more as a well-done extension to the platform than as a comprehensive implementation of Ajax within the set of ASP.NET controls.

What are ASP.NET component vendors doing?

Some vendors are actually building their own products on top of the Microsoft ASP.NET Ajax stack. In other words, they are replicating the same winning approach that brought to creating the industry of components—same base model, but many more features.

Ajax, however, cannot be simply reduced to a set of sexy features. It is much more than that—it is a brand new paradigm. So while the idea of server controls remains valid, the internal structure and interaction with the server needs be revisited. Each vendor seems to have its own personal recipe about Ajax server controls, but some of them are, in effect, just using ASP.NET Ajax as the foundation of their approach.

In the panorama of today’s server control libraries, Gaia Ajax is fairly unique for three main reasons:

• It looks like classic ASP.NET;
• It does Ajax indeed;
• It doesn’t use the Microsoft’s ASP.NET Ajax stack as a foundation;

Developed by Gaiaware, Gaia Ajax is a commercial (dual licensed) open-source Ajax library for ASP.NET. It is compatible with the .NET Framework 2.0 and newer versions, and Mono. Gaia Ajax abstracts away HTML, JavaScript, and Ajax and offers a server-side programming model that doesn’t require you to use and learn more than just .NET managed code. At the same time, though, Gaia Ajax endows your pages with top quality client-side features and capabilities.

This paper helps you making sense of Gaia Ajax and guides you to understand the reasons and the features that make the library so unique and overall powerful.

Patterns of Ajax Architecture

Web applications are a special variation of classic client/server applications and require an Internet connection between the two tiers. Connectivity is incorporated in the client application—the Web browser. Every browser includes an internal API to open the connection, send a request, and receive any response. For many years, browsers kept this internal API away from hosted pages and offered connectivity services only through a sort of all-inclusive travel package. When the page orders a HTTP request, the browser opens the connection, freezes the current user interface, sends the request, processes any received response and then updates the screen with the results.

In an Ajax scenario, instead, the client code gains the ability to access the connectivity API of the browser directly. In this way, the client code can manage the update of the user interface itself. For example, the client code can request the Web server fresh markup for only a fragment of the current user interface. Opposed to the typical behavior of erasing the current page and reloading an entire new content for it, the Ajax paradigm represents a great step forward towards the achievement of greater usability and a richer user experience.

An effective implementation of the Ajax paradigm poses two key requirements. One is the aforementioned availability of a client-side infrastructure that can manage the connection with the Web server. The other requirement is a server-side HTTP facade that exposes a bunch of functions for the client side to call.

Over the Web, regardless of the platform and paradigm, every client action originates a corresponding server action. In classic ASP.NET, the server action is invoked through a HTTP request known as the postback. A postback is merely a HTTP POST request sent to the same URL of the current page. A hidden field, known as the viewstate, maintains the state of server controls across two consecutive postbacks. In an Ajax scenario, the server action is commonly invoked via JavaScript code through the services of some helper client-side library, such as jQuery or the Microsoft Ajax library. All helper JavaScript libraries, though, perform their HTTP requests using the browser’s native XMLHttpRequest object.

Ultimately, an Ajax application contains a lot of JavaScript code and requires a HTTP facade to address calls to. This model, however, can be implemented explicitly or implicitly. Choosing the model that works better for your application is definitely an architectural choice—that is, it fixes a firm point about the application that is hard to modify later.

The most common approach to Ajax consists in the explicit definition of a JavaScript-based client API and a server-side HTTP facade. In the .NET space, the HTTP facade mostly, even though not necessarily, consists of REST services created using Windows Communication Foundation (WCF). The JavaScript-based client API is a layer of application code that forwards calls to the facade. This architectural pattern is referred to as the Ajax Service Layer pattern. (In some literature this pattern is also referred to as the UI Web Service layer or RIA Service Layer.)

Gaia Ajax incarnates a different model where the definition of the JavaScript-based client API and server-side HTTP facade is implicit into the framework. In other words, no JavaScript awareness and skills are required on the developer’s end. At the same time, no explicit HTTP facade is expected to exist. The Gaia Ajax framework shields developers from such details by offering an ASP.NET-like programming model made of conventional server controls and server helper objects. This architectural pattern is referred to as the Ajax Server Pages pattern. Figure 1 compares the two patterns graphically.

Figure 1. Graphical comparison of Ajax architectural patterns.

As you can see, some JavaScript is required in both cases. So where’s the difference between the two architectural patterns?

In Ajax Service Layer, any script code is your own JavaScript code written to start requests, process server responses and update the user interface. Your presentation logic is written in JavaScript. In the Ajax Server Pages, the client code is part of the code of the page and is emitted by the server controls you use to trigger the postback. Most of that JavaScript code is transparent to you as a developer.

The data being returned by the server is also different. It is often plain JSON in the Ajax Service Layer pattern; it is an internal format managed by the server controls in the Ajax Server Pages pattern.

In a solution based on the Ajax Service Layer pattern, you don’t need ASP.NET server controls. Or, at least, server controls are not a core part of the implementation. The logic expressed by the page, and the use-cases it implements, is coded using handwritten JavaScript. Because the code expresses pieces of the application logic and scripts public endpoints in the HTTP facade, no black-box server control can ever be configured to emit that code for you.

At the same time, a solution based on the Ajax Server Pages pattern is heavily based on server controls as it moves the burden of Ajax within each control that is enabled to do a postback. The granularity of Ajax building blocks is fairly different in the two patterns.

Let’s review more in details the differences between the two patterns from a developer’s perspective.

Ajax Architectural Patterns: Make Your Choice

Any Ajax solution requires JavaScript on the client and public HTTP endpoints on the server. This is a common, basic fact that never changes whatever Ajax library or approach you decide to take. Differences exist at the programming level, but those mostly refer to who-does-what scenarios. More specifically, differences between patterns exist to determine who writes the JavaScript code, how this code works, and how remote calls are triggered.

Differences between Ajax architectural patterns also determine the set of skills a developer is required to have. And the actual skills of a development team are not a factor an architect can afford to overlook when he’s called to make a choice.

In an Ajax Service Layer scenario, the development team must be able to handle JavaScript calls either to fully implement the required presentation logic or to script a set of rich controls that some commercial library also provides. Your exposure to JavaScript is significant, even though an ad hoc set of controls may save you from writing critical presentation code in JavaScript and leave to you mostly glue code.

The idea behind the Ajax Server Pages pattern is in a way simpler. It just focuses on enhancing the existing ASP.NET and upgrading it to Ajax. Developers will be able to reuse the totality of their ASP.NET skills and the mentality of building applications following the Web Forms model. The Ajax Server Pages pattern requires a brand new set of ASP.NET server controls specifically designed with Ajax in mind.

This pattern is implemented in the ASP.NET framework through the UpdatePanel and ScriptManager controls. This pair of controls adds Ajax capabilities to existing pages without switching to a significantly different programming model. The underlying engine, though, has some known limitations that make it suitable mostly for relatively simple application scenarios.

Benefits of the Server-side Approach

The Ajax Server Pages pattern pushes a server-side programming model nearly identical to the classic ASP.NET programming model. This means that, as a developer, you will keep on working with server controls. Well-done controls, appropriate for the Ajax paradigm, are the only guaranteed way to boost productivity. The combination of a pattern that just adds Ajax to the postback model with a powerful library of controls also saves from the costs of getting familiar with JavaScript and a radically different programming model.

The benefits of having a server-side programming model don’t end here, however. To start off, you will keep the security bar higher than with client-side code. In a server-side model, before reaching the application context any requests have to be authenticated and authorized by the run-time code. There’s no increased risk of script-related attacks and no risk of overlooking new security aspects. The security countermeasures remain exactly the same as in classic ASP.NET.

A server-side model allows you to program using powerful, first-class programming languages and gets you full access to the .NET framework as well as the ASP.NET runtime infrastructure. Among other things, this means that you are not limited to using a subset of the base class library as in Silverlight and are not limited to making only asynchronous calls to remote services.

Accessibility is another key topic to consider that gains importance every day. Accessibility ultimately refers to how the content displayed via the client browser makes itself available to users with disabilities. The client browser, though, only displays the HTML it receives from the server. Based on first-class programming languages, a server-side model lets you express the logic to generate accessible user interface in a much more comfortable and powerful way.

In the end, an effective implementation of any Ajax patterns passes through the use of a specialized library of controls. Is there any product out there that fully supports the Ajax Server Pages pattern? Enter Gaia Ajax.

Gaia Ajax at a Glance

Gaia Ajax is a RAD framework for ASP.NET that eases the development of Ajax applications. The main trait of the library is that it abstracts away any JavaScript thus allowing you to write 100% of your ASP.NET Ajax pages using .NET managed code such as C# and VB.NET. The latest release of Gaia Ajax is 3.6. You can find all details at http://gaiaware.net.

The Gaia Ajax engine works on top of ASP.NET (version 2.0 and superior) and builds any of its features over that. The core engine includes runtime components and utility classes that top-level server controls then use to implement their features. The set of controls you find in Gaia Ajax can be split in two groups: basic controls and advanced controls. In turn, the family of basic controls can be divided in three distinct groups: ASP.NET-style stock controls, aspects controls, and effects controls. Under the umbrella of advanced controls, instead, you find many of the most typical controls that a commercial ASP.NET library offers, including TreeView, Menu, TabControl, Accordion, Window and so forth.

What does it make a control an advanced control from an Ajax perspective?

It is essentially the control’s ability to do most of its work on the client while updating only the (small) portion of the user interface that really needs repainting. Any Ajax server control needs some JavaScript code to accomplish this task; an advanced Ajax server control can emit itself almost all the JavaScript it needs and offers hooks to bind to external and even remote data sources and HTTP endpoints to get data. In both cases, though, the need for some extra glue code remains. This code ranges from plain glue code that just scripts client-side components to a real portion of the presentation logic. In classic Web Forms, any glue code belongs to a code-behind Page class. In a common Ajax scenario, this glue code is mostly JavaScript code that the developers have to write. With Gaia Ajax, this glue code belongs (again) to the code-behind ASP.NET Page class, except that now the page is fully aware of the Ajax paradigm.Ajax

The latest Gaia Ajax library features server controls whose level of abstraction is really close to that of standard ASP.NET controls. Most of the Gaia Ajax controls inherit from their ASP.NET counterparts. This means, for instance, that every single property you have in, say, System.Web.UI.WebControls.Button will also be available in the Gaia Ajax Button control. The key difference between a classic Button control and the Gaia’s Button control is all in that the latter, when clicked, can perform an Ajax postback. An even better example is the Gaia Ajax GridView control which inherits from ASP.NET GridView but features intelligent Ajax capabilities for paging and sorting.

Figure 2. The Visual Studio 2008 toolbox once Gaia Ajax 3.6 is installed.

All Gaia controls end up firing a server-side event when their state is changed on the client. For example, when a Gaia Button control is clicked, or a Gaia DropDownList has its selection changed, a server-side “postback” event is fired. This mechanism is no way different (yet) from classic ASP.NET Web Forms. The form submission, and the subsequent connection to the server, is nearly identical to a classic ASP.NET postback, except that it occurs in an asynchronous manner. As a developer, you don’t need to write a single line of JavaScript code to trigger such an asynchronous event and no markup is explicitly returned to the client.

The suite of Gaia Ajax controls is probably the natural evolution of original ASP.NET Web Forms controls towards Ajax. Gaia Ajax represents a complete rethinking of the ASP.NET component model in light of Ajax. The net result is that developers have a renewed, but still largely familiar, model to work with. Figure 2 shows how the Visual Studio 2008 toolbox looks like once the Gaia Ajax framework is successfully installed.

Developers don’t have that many new things to learn and will reuse all skills they already matured on classic ASP.NET Web Forms. In addition, developers have (sort of free-of-charge) Ajax capabilities in their pages.

Gaia Ajax works with and without ASP.NET controls. However, automatic Ajax postbacks and automatic glue code management is possible only for Gaia Ajax native controls. This is not surprising as these features need to rely on a specific infrastructure that the control’s code must be aware of.

With Gaia Ajax, you can do Web programming without learning a new programming model and without endowing yourself with new skills. One of the key factors to the rapid adoption of the ASP.NET Web Forms programming model years ago was certainly the limited gap between ASP.NET and classic server-side, object-oriented programming. Now that the Web has definitely turned towards Ajax, and now that adding the attribute Ajax to any Web-related expression starts sounding a bit pleonastic, to do good and effective Ajax programming you are still requested to switch back to JavaScript.

JavaScript is an interpreted and not fully object-oriented language that, in addition, requires nontrivial skills to be effectively programmed and it is still subject to browsers’ implementation. However, JavaScript is still the only available tool that can enable Ajax features. Gaia Ajax shields developers from any form of JavaScript awareness and returns a programming model as clean and effective as old-fashioned Web Forms; only Ajax-enabled.

Let’s compare and contrast Gaia Ajax with Microsoft’s built-in solutions for adding Ajax to ASP.NET.

Gaia Ajax and ASP.NET Partial Rendering

Gaia Ajax silently replaces classic postbacks with asynchronous postbacks and does all the work of managing request and response internally. Therefore, the developer focuses on ASP.NET programming and may blissfully ignore everything else.

Isn’t just this also the promise of Microsoft’s ASP.NET partial rendering? What’s the difference between ASP.NET partial rendering and Gaia Ajax?

Differences occur at two levels. At the highest level of abstraction, ASP.NET partial rendering and Gaia Ajax share the idea of an underlying core framework that manages asynchronous postbacks. The overall approach of ASP.NET partial rendering, though, is just simpler and less sophisticated.

In first place, ASP.NET partial rendering introduces just one control—the UpdatePanel control—to intercept any postbacks from any child, or related, controls. Next, the UpdatePanel control sets up an asynchronous postback whereas a classic ASP.NET postback was requested. The control manages data transfer and parses any response to the user interface. The UpdatePanel control relies on an internal platform that has both a client and server API.

The partial rendering engine is merely a wrapper around the classic postback model and doesn’t change the overall programming model of ASP.NET. However, it doesn’t even attempt to introduce some improvements over the standard postback dynamics.

In Gaia Ajax all controls that support the postback semantics (Button, DropDownList, TextBox) are directly connected to the underlying Ajax infrastructure. As a result, any Gaia Ajax controls you may use will always trigger an asynchronous postback without the need of adding ad hoc container controls to your pages such as the UpdatePanel control.

Here’s a brief example of how it would work with Gaia. The code snippet presents a simple server-side form that contains a Label and a Button control. The Button control defines an OnClick handler that fires as the user clicks on it.

<form id="form1" runat="server">
    <gaia:Label ID="Label1" runat="server" /> <br />
    <gaia:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Click me" />
</form>

When the user clicks the button, the following code runs. Note that this code belongs to the page’s code-behind class and is plain C# code.

protected void Button1_Click(object sender, EventArgs e)
{
    Label1.Text = "Hello! This is Gaia Ajax.";
}

Where’s Ajax in this code? Isn’t it plain ASP.NET, instead? That’s just the magic of Gaia Ajax actually.

Under the hood, any Gaia control with a postback semantics (i.e., the Button control) emits some JavaScript code that will be evaluated and executed on the client. This JavaScript code detects control-specific client events and replaces any ASP.NET-style postback with an Ajax postback. In this regard, the overall mechanism is not really different from partial rendering. The notable exception is that you don’t need to host any posting control in an UpdatePanel area. In addition, you don’t need a ScriptManager control in the page. In Gaia Ajax, every single component is in total control of its postbacks and knows how to post back asynchronously.

Like in ASP.NET partial rendering, some extra information is uploaded to the Web server in the context of an asynchronous request. The content of the response packet is much more interesting than the content of the request. Unlike ASP.NET partial rendering, any Gaia Ajax request returns a piece of script code rather than plain markup or properly formatted text. Figure 3 shows the browser-to-server conversation at the HTTP level for the previous HTML page.

Figure 3. Request and response for a simple Gaia Ajax request.

ASP.NET controls track their own state on the server and use that information to add markup to the output stream during the rendering stage. A Gaia Ajax control does the same except that it uses internal state managers. When it comes to generating the response for the client, changes operated server-side on Gaia controls are rendered as script code.

The emitted script code targets functions and objects of the client-side Gaia Ajax library. For example, the $G and $FChange functions you see in Figure 3 just belong to the Gaia client JavaScript library. Let’s briefly analyze the response:

$G('Label1').setText('Hello! This is Gaia Ajax.');
$FChange('__VIEWSTATE', 22, 'APZBYCAg…OkAD+FsV4IZQADQeE=');
Gaia.SU(true);

The response instructs the client-side Gaia Ajax manager to update the Text property of the JavaScript object that represents the client-side component for the HTML element with the Label1 ID. It also tells the Ajax manager to update the HTML element with an ID of __VIEWSTATE—the well-known view state hidden field.

As you can see, the viewstate is not downloaded entirely, but only the section of it that has changed to the effect of the operation is returned. This is a huge difference between Gaia Ajax and ASP.NET partial rendering and also a point that differentiates Gaia from other third-party libraries that rely on the ASP.NET infrastructure.

Unlike ASP.NET partial rendering, Gaia Ajax supports multiple calls going on simultaneously. One of limitations of partial rendering is that every time an asynchronous call is placed it kills any ongoing asynchronous call that is still pending. In the end, you can operate at most one asynchronous call at a time in ASP.NET. With Gaia Ajax, you don’t have such a limitation. If multiple calls are made that run concurrently then the library queues them and executes all calls sequentially. More importantly, call queuing just happens silently and automatically.

From Partial Rendering to DRIMR

However, to fully express the real difference that exists between Gaia Ajax and ASP.NET partial rendering you should put it down in terms of paradigms. It may seem that that Gaia Ajax and ASP.NET follow the same paradigm and just differ for technological aspects. The Gaia Ajax uses, instead, a different approach that goes under the name of DRIMR, an acronym for Dynamic Removals, Inserts, Moves and Replacements. As the name suggests, partial rendering renders out only a portion of the page. The ASP.NET underlying machinery is mostly intact and has changed only for what it takes to produce a segmented rendering. Server-side, the philosophy of DRIMR and partial rendering are nearly the same. The huge difference that really qualifies DRIMR as a new Ajax paradigm—what I abstractly referred to as Ajax Server Pages earlier in this paper—is on the client. Partial rendering updates the page by re-rendering the root of updateable panel. The larger is the panel, the more work is required on the client by the browser. However, even if you use a granular approach and wrap each ASP.NET control in an updatable panel, you are still left re-rendering the full DOM tree for each modified control.

DRIMR does more and targets the HTML element rather than the subtree of a server control.

DRIMR aims at keeping the server-side control tree synchronized with the client-side DOM tree. In this way, all that Gaia Ajax controls are required to do is sending small requests for updating client controls--and updating is significantly different from rebuilding even a small DOM tree. A technical perspective of DRIMR can be found here: http://www.janblomquist.com/blog/2009/09/11/TheAnatomyOfTheDRIMRTechnologyForASPNET.aspx.

Inside Gaia Controls

Figure 4. Architecture of Gaia Ajax.

As mentioned, Gaia Ajax leverages part of the ASP.NET infrastructure, but not the ASP.NET Ajax framework. Gaia derives most of its controls from existing ASP.NET controls and takes advantage of ASP.NET runtime components (providers, HTTP handlers, HTTP modules) to implement its additional features.

With very few exceptions (i.e., validators) all Gaia Ajax basic controls are inherited from corresponding native ASP.NET controls. The set of properties remains nearly the same plus some Gaia-specific extensions. Ajax capabilities are built directly into the controls and are not leveraged from the surrounding environment. To get the point, have a look at the following code snippet taken from the source code of the Gaia TextBox control.

public class TextBox : System.Web.WebControls.TextBox
{
// Some code
:

[AjaxSerializable("setText")]
public string Text
{
get { return base.Text; }
set { base.Text = value; }
}

// Some code
:
}

The Gaia TextBox exposes the same set of standard properties, but decorates them with custom attributes such as the AjaxSerializable attribute. Server-side changes that alter the state of a control are recorded and serialized to script method calls to execute on the client at rendering time. The AjaxSerializable attribute indicates the name of the function to use to repeat on the client any changes applied to the decorated property on the server. In addition, each Gaia Ajax control is matched to a client-side component that gets downloaded into the page as an embedded script and cached as any other script files.

Gaia Ajax and State Maintenance

Although Gaia Ajax allows you to build even large applications with pure server-side code with no markup and no use of JavaScript, it still remains an Ajax library. This means that developers can write JavaScript code to orchestrate the behavior of the page elements. Because page elements of a Gaia Ajax page abstract typical components such as buttons, lists, and text fields state must be maintained on the client too. In Gaia Ajax each control maintains its own state on the client; the client state is then uploaded to the server during asynchronous postbacks.

In classic ASP.NET, control state is stored in the viewstate. The viewstate content is downloaded to the client but is never used by any client code. Ultimately, the reason why the viewstate is appended to the output stream of every ASP.NET page is to establish a strong link between an instance of the viewstate and the instance of the page it refers to. Each instance of the page has its own state stored in the viewstate. Keeping the viewstate on the server is definitely possible, but it would require you to store multiple copies for each page—typically, one copy for each level of Back/Forward navigation you want to support.

Classic ASP.NET was not designed for Ajax, so the viewstate is perceived as a read-only field on the client. In Gaia Ajax, instead, state is stored and managed both on the client and the server. To avoid breaking compatibility, and to reuse as much as possible of ASP.NET, Gaia Ajax still supports the viewstate but pairs it with a client-side state management infrastructure.

While the ASP.NET viewstate plays a fundamental role in the whole ASP.NET architecture, many developers just hate it because it burdens pages. What’s the “real” role of the viewstate in a true Ajax architecture? In ASP.NET Ajax, the viewstate works and is consumed in exactly the same manner as in classic ASP.NET. This means that a partial rendering operation that involves only a couple of controls will still return the viewstate of the whole page. Gaia Ajax does it better.

In particular, Gaia Ajax implements a partial viewstate approach, meaning that for every asynchronous postback it only returns the delta of the viewstate. Combined with script serialization (no markup, just script instructions), partial viewstate makes Gaia Ajax postbacks quite slim in absolute terms and significantly smaller than with ASP.NET partial rendering.

Gaia and Rich Controls

In Gaia Ajax you also find a set of rich controls such as TreeView, Window, GridView and Menu. The nice fact about advanced controls is that all of them are built on top of basic controls. In particular, basic Gaia controls are used as building blocks and assembled together to provide a richer user interface and functionality. For example, the Window control you see in Figure 5 is made of a combination of child Gaia controls. The title of the window is a Label control; the button bar is a collection of LinkButton controls. The window is also moveable and resizable; these two features are obtained via a couple of very special Gaia components—Gaia aspects.

Figure 5. A Window Gaia Ajax control.

Rich controls also offer a compelling experience at design time, as shown in Figure 6 for the TabControl control.

Figure 6. The design time experience of a Gaia TabControl.

The GridView control is one of the most popular controls of ASP.NET. It is a powerful control because it delivers rich and highly interactive functionality including paging, sorting, in-place editing. Using the classic GridView can be painful because of the frequent refreshes of the page the users may cause as they work with the page. Using the GridView in the context of ASP.NET partial rendering is acceptable; but using the new Gaia Ajax GridView is a blast—for how simple it is to use and compose into nested grids and for how fast it is in updating only the smallest portions of the control area that changed. Here's the code you need to create a nested grid.

<gaia:GridView
     ID="zGridParent" 
     runat="server" 
     AutoGenerateColumns="false" 
     DataSourceID="XmlDataSource1" 
     Width="100%">
     <Columns>
        <gaia:BoundField 
              HeaderText="Customer" 
              DataField="Name" 
              ItemStyle-CssClass="customer-cell" />
        <asp:TemplateField>
             <ItemTemplate>
                <uc1:OrderGridView 
                     ID="ogv" 
                     runat="server" 
                     GridDataSource='<%# XPathSelect("Order") %>' />
             </ItemTemplate>
        </asp:TemplateField>
     </Columns>
</gaia:GridView>

It is not really different from plain ASP.NET code; except for how it works: no re-rendering when paging or sorting, limited updates and JSON-ish data exchange between control and its backend.

The Plus of Gaia Ajax

Gaia is a third-party commercial ASP.NET library for Ajax. Just like any other similar product, it attempts to catch the developer’s eye with some fairly unique features. Sometimes it is full and optimized support for Web services and JSON streams; sometimes it is just a rich and variegated collection of controls that, properly customized, deliver half the application. As far as Gaia Ajax is concerned, a peculiarity that is worth noting is that the library is made of robust building blocks, simple and effective if taken alone, but expressive and powerful if merged together.

Building blocks include basic controls, functionally similar to basic ASP.NET controls, but also two new categories of controls—aspects and effects.

An Ajax library distinguishes itself from the plethora of classic Web libraries because it offers components and functionalities that heavily leverage the programming power of the client browser and JavaScript. Typical features are drag-and-drop, element resize, visual tricks such as fading, shadows, and rounded borders. In Gaia Ajax, these client-only features are exposed via special components known as aspects and effects.

Each Gaia control exposes a collection named Aspects that can be programmatically (or declaratively) populated with specific aspects such AspectResizable or AspectMovable. Here’s a piece of code that shows how to do it:

protected void Page_Load(object sender, EventArgs e)
{
    // This makes the specified resizable at run time
    Panel1.Aspects.Add(new AspectResizable());
}

In addition, frequently used aspect-related events are also exposed as events on controls. This means that, say, a Window control will be able to fire an event when it is moved or resized.

Gaia also offers a nice collection of programmable visual effects that are enabled via the Effect class, as in the code snippet below:

protected void Button1_Click(object sender, EventArgs e)
{
    new Effect(Panel1, Effect.TypeOfEffect.Highlight);
}

The net effect of the preceding code is that when the Button1 element is clicked, the specified panel (Panel1 in the example) is highlighted.

Needless to say, aspects and effects are common user interface features that every Ajax application should have; with Gaia Ajax you have an effective API just out-of-the-box. Furthermore, in Gaia Ajax 3.6 effects can also be chained to create custom animations. Another special group of controls you find in Gaia that now fully work the Ajax way are validators and image maps.

Gaia Ajax Top Ten Facts

Gaia Ajax is definitely an Ajax library that is worthy a deep dive. Here are some fast-but-key facts about the library.

Gaia enhances the today’s ASP.NET model up to Ajax.
The library comes with a revised version of most popular ASP.NET stock controls. These controls emit HTML markup plus some script and always perform asynchronous postbacks in a way that is transparent to developers.

Gaia enhances productivity through rich controls.
Rich controls are probably not the best-selling point of Gaia Ajax. However, you find quite a few controls with a rich and compelling interface that abstract away some common pieces of a Web page. And, maybe more importantly, Gaia Ajax makes it easy and effective for you to build your own custom controls of a fairly high level of complexity by combining together native components such as stock controls, containers, effects and aspects.

Seamless integration with ASP.NET container controls.
Gaia controls and ASP.NET controls cannot be used interchangeably in the sense that each has its own unique set of features. This doesn’t mean, though, that interoperability between Gaia controls and ASP.NET controls is not possible. In particular, you can wrap ASP.NET controls into a Gaia container (i.e., the Gaia Panel) and have Gaia postbacks to automatically replace classic (and expensive) ASP.NET postbacks.

Gaia Ajax is easy to debug.
The availability of the Gaia source code makes debugging server-side code a piece of cake. To debug client code you obviously need either FireBug or Internet Explorer 8 or perhaps latest Visual Studio. However, the main point here is not much the fact that Gaia itself is easy to debug because its source code is available. An application based on Gaia Ajax is also fairly easy to debug as any requests trigger the full page lifecycle on the server and makes it possible for you to set breakpoints just as you would normally do in classic ASP.NET programming.

Gaia loves all browsers and all browsers love Gaia.
Gaia Ajax controls emit HTML markup and script code that works great with most popular browsers including Internet Explorer 8, Firefox, Opera, Chrome and Safari.

Gaia doesn’t prevent using Web services.
Although Gaia Ajax is designed around the Ajax Server Pages pattern it works well in the context of pages that download remote data via Web services. Gaia controls have a client-side object model that can be explored and configured via JavaScript and populated with fresh data, no matter how you happen to get it.

Gaia Ajax controls are written using optimized DOM/CSS code.
All Gaia controls use CSS extensively and are based on DOM code optimized for speed. In addition, a made-to-measure XhtmlTextWriter internal component ensures 100% valid markup.

Gaia Ajax is more sophisticated than ASP.NET partial rendering.
Architecturally speaking, Gaia Ajax is quite similar to ASP.NET partial rendering, but it relies on a significantly different implementation. Gaia Ajax controls ensure much smaller payloads, partial viewstate rendering, and can queue concurrent calls.

No new skills required to use Gaia Ajax.
Gaia Ajax represents a new flavor of ASP.NET that just knows how to add Ajax capabilities from the grounds up. To use Gaia Ajax controls, you need no skills other than plain ASP.NET programming skills. You will still do a lot of work in code-behind classes writing managed code. The magic of recording and serializing server actions to JavaScript instructions is left to the infrastructure of the library.

Gaia Ajax offers all typical bells and whistles of Ajax.
An Ajax user interface is extremely interactive and responsive. Interactivity and responsiveness are not attributes of Ajax only. You find these attributes associated with any Windows desktop user interface either. For Web applications it has always been a different story. Among other things, Ajax means the ability of letting the end user do many more things within the browser. And it also means the ability of providing the end user with a unique experience where visual effects and rich controls behavior blurs the distinction between Web and desktop. Gaia Ajax makes it particularly easy (and effective) to program visual effects and rich controls behavior.

Gaia on the Web

A portal for finding out more about Gaia Ajax is http://gaiaware.net. Plenty of examples, with companion source code, can be found at http://samples.gaiaware.net. Blogs and a forum can be found at http://blogs.gaiaware.net and http://forum.gaiaware.net respectively. Finally, technical documentation is available at http://docs.gaiaware.net and videos are available at http://tv.gaiaware.net. Licensing information is available at http://gaiaware.net/product/dual-licensing.

Gaiaware also offers public source code access (Subversion) and nightly builds of the software which makes it possible for eager followers and community members to track the development of Gaia Ajax on a daily basis.

Summary

Everybody in the software industry is committed to Ajax. Everybody understands the impact of it. Everybody recognizes the enormous power that can be derived from the employment of the Ajax paradigm in real-world solutions. Not so many people, though, know exactly what the right way to make Ajax happen is. There are so many variations to Ajax and so many implementations that even after you have found one that suits your needs, you are left wondering whether that is the best possible option.

A few years ago, Microsoft offered a set of Ajax extensions to the ASP.NET platform. There are two distinct souls in ASP.NET Ajax extensions: partial rendering and script services.

ASP.NET partial rendering introduces the principle of “selective updates”, by means of which only the delta of the page is returned after each Ajax postback. Partial rendering was implemented by adding a couple of new controls to the toolbox and defining a client side JavaScript library. Everything else remained intact.

Script services refer to a set of JavaScript extensions that reference server-side Web services and generate a JavaScript proxy for them. In this way, developers may start building the user interface entirely on the client and code all, or in part, their presentation logic using JavaScript.

Most of the component vendors in the industry use ASP.NET Ajax as the foundation of their solutions and products.

ASP.NET partial rendering doesn’t force you away from the standard programming model of ASP.NET, but it forces you to use additional controls and still takes you to consider postbacks and Ajax postbacks as two distinct things. In addition, partial rendering suffers from a number of technical limitations. ASP.NET script services take you towards a pure Ajax approach padded with JavaScript code and direct calls to services. It’s close to be an ideal scenario, except that it forces you write a lot of code in JavaScript.

Gaia Ajax is different.

Gaia Ajax proposes an alternative way of doing Ajax in ASP.NET applications. For one thing, it doesn’t offer a rich JavaScript library for you to program explicitly. You will keep on writing your pages using C# or VB code in combination with classic ASP.NET markup. The hidden infrastructure of Gaia Ajax will transform any apparently old-style postback into an asynchronous Ajax postback.

This effect is obtained by using a new set of basic controls (such as TextBox, Button, DropDownList, LinkButton) that look like classic ASP.NET controls but behave in an Ajax-compliant manner. Any data-binding skills you may have will be fully reusable. And you won’t write a single line of JavaScript. Until, like in classic ASP.NET, you see a special benefit in doing so.

In a way, Gaia Ajax is ASP.NET Ajax as it should have always been: same postback mechanism, same programming model, same controls—just ajaxified. In addition, Gaia Ajax has aspects, effects, a bunch of ready-made rich controls, a client-side object model for every control, Visual Studio 2008 designers, full browser compatibility, debugging facilities, plenty of online examples, documentation, and possibility of licensing the source code.

If you’re looking for an effective and creative and original solution for your Ajax applications, Gaia Ajax is definitely worth more than just a deep dive.