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.

Why Is Writing Large Applications in
JavaScript Really a Daunting Task?

Let’s
face it. The Web is a whole step backwards in terms of interactivity and
responsiveness if you compare it to desktop solutions. But the Web compensates
for this limitation with wide reach and ease of deployment. Today, the demand
for richer interfaces can’t be further sidestepped.

HTML—the
markup language used to express the user interface of a Web application—was not
originally designed to be an application delivery format. Although adapted and
improved over years, it is not as expressive as only a true and tailor-made UI
markup language (i.e., XAML) can be. Visual and input elements you find in HTML
are simple and scanty and anyway subject to browser’s implementation. You make
them richer by adding pieces of JavaScript code.

Chunks of
JavaScript code around HTML elements only represent the most superficial layer
of the user interface. A large client-side Web application needs a fully-fledged
presentation layer running within the browser that implements some presentation
logic. Unless you switch to a Rich Internet Application framework like Silverlight,
such a presentation layer can only be written with JavaScript.

This is just
where the rub lies.

JavaScript
was introduced more than a decade ago to give authors of Web documents the
ability to incorporate some logic and action in HTML pages. Before then, a Web
page was essentially a static collection of HTML tags and text. JavaScript was
not designed to be a classic and cutting-edge programming language—not even by
the standards of 15 years ago. The primary goal of its designers was to create
a language that resembled a simpler Java that could be used with ease by
nonexpert page authors. The predominant factor of the language was simplicity
and it was named JavaScript because essentially meant to be a powerful language
(like Java) just focusing on scripting.

Today, JavaScript
is clearly inferior to commonly used programming languages. The limitations of
JavaScript can be summarized as two elements: it is an interpreted language,
and it is not fully object oriented. The former drawback makes the language
significantly slower than a compiled language. The latter makes it harder for
developers to write complex code.

An
overall weakly typed language, JavaScript does support objects. However, a
“JavaScript object” is something significantly different from the “object” of a
classic object-oriented programming (OOP) language such as C#. In C#, you
create new objects by telling the runtime which class you want to instantiate.
A class, therefore, is a fixed template used for the object creation. A class
defines the properties and methods an object will have, and these properties
and methods are forever fixed. In C#, you can’t manipulate the structure of an
object by adding or removing properties and methods at runtime. In JavaScript,
an object is a container of name/value pairs that can be added at any time, and
especially at runtime.

In
addition, JavaScript doesn’t natively support all principles of OOP, such as
inheritance, encapsulation, and polymorphism. To some extent, some of these
principles can be recognized here and there in the language’s capabilities but
they obey to a set of different rules. Inheritance, for example, is based on
the prototype object—a specific feature of the JavaScript runtime environment.

The
interpreted nature of the language makes it impossible for developers to
receive compile time warnings and supports coding styles that make the code
extremely compact, rich of chained calls, and overall weird-looking and
difficult to read (and maintain).

Also,
tool support for JavaScript programming is a new field growing rapidly but
still largely insufficient when compared to tooling support for C# and other
classic OOP languages.

Finally,
any JavaScript code lives and runs within the browser, which is a
partially-trusted environment and provides access to a small set of native
objects. Remote connections are possible, but they cost a roundtrip and must be
coded manually.

Writing a
JavaScript presentation layer is not impossible. But researching an alternative
server-side model is a must for any team of developers.

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

A Component Library Open for
Extensions

Gaia Ajax
isn’t simply a component library to do some good Ajax client-side programming.
It isn’t just a collection of rich Ajax controls either. Gaia Ajax really offers
a new, and strongly Ajax-oriented, framework for building ASP.NET applications.

Gaia Ajax
replaces ASP.NET stock controls (Button, TextBox, DropDownList)
with new controls that support the Ajax paradigm from the grounds up. Gaia Ajax
controls, though, are entirely open for extensions.

Gaia Ajax
provides an extensible and easy-to-use infrastructure of container controls
that can be used to model richer controls and even full applications using the
familiar ASP.NET black-box server control approach. With Gaia Ajax you don’t
just look for an off-the-shelf, readymade control that suits your need as is.
More, you find all the tools you need to craft your own component just the way
you want and need it.

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.

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.

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.

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.

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:

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.

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.

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.

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:

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.

And Last, But Not Least, Performance

In
general, performance is hard to define and measure in the context of a
multi-layered application like a Web application is. The performance of a Web
application may be affected by two facts: the implementation of server-side
operations and the user interface. Implementing the Ajax paradigm obviously
helps to fix only the latter aspect. To improve the former aspect you should
review the design of back end layers such as the business and data access
layers.

Any Ajax
implementation produces an immediate and measurable benefit for the end user. However,
this doesn’t happen because any Ajax implementation is on average a good one.
More subtly, it happens because the touchstone is particularly poor. Any Ajax
implementation will easily stand out compared to a classic Web postback that repaints
the whole page over and over again. Even the most simplistic implementation of
ASP.NET partial rendering outshines the classic ASP.NET postback as far as the
user’s perception is concerned.

If you go
beyond the user’s perception of performance, though, and try to compare the
server-side performance of ASP.NET postbacks with Gaia Ajax postbacks you’ll
see that Gaia callbacks are clearly faster that ASP.NET postbacks.

A Gaia
Ajax request skips the rendering phase and goes through a much shorter
lifecycle on the server. In particular, the rendering phase loops over the
controls referenced in the page and accumulates their markup in the output
stream. This operation takes quite a few CPU cycles on the server and for each
and every request. A Gaia Ajax request tracks property changes on any (Gaia)
controls involved in the postback and serialize only property changes back in
the form of JavaScript calls. In doing so, you move smaller amount of
information and save HTML/DOM conversion work on both the server and client. That's the power of DRIMR.

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.