Before
you really get started with Ajax, it's important to understand its
capabilities and limitations. Only then will you know how to fit it into
your web applications.
1. Ajax: The Good
The key benefit of Ajax is
responsiveness. An Ajax application, when done properly, provides a
better experience for the user. Even if the user can't do anything new
(or do anything faster), this improved experience can make your web
application seem more modern and sophisticated. If you're creating a
website that's competing against other similar sites, you just might
find that Ajax allows you to distinguish your work from the rest of the
pack.
Ajax can also provide
genuinely new features that aren't possible in traditional web pages.
For example, Ajax pages often use JavaScript code that reacts to
client-side events like mouse movements and key presses. These events
occur frequently, so it's not practical to deal with them using the
postback model. For example, imagine you want to highlight a TextBox
when the user moves the mouse over it. With the postback approach, you'd
need to send the entire page back to the web server, regenerate it, and
refresh it in the browser—by which point the mouse might be somewhere
completely different. This approach is clearly impractical. However, an
Ajax page can deal with this scenario because it can react immediately,
updating the page if needed or requesting additional information from
the web server in the background. While this request is under way, the
user is free to keep working with the page. In fact, the user won't even
realize that the request is taking place.
NOTE
Ajax isn't really a whole
new technology. More accurately, it's a set of techniques, some of
which extend existing practices. For example, you've already seen quite a
few ASP.NET controls that use client-side JavaScript to provide a
richer experience, such as the validation controls and the Menu control .
However, Ajax pages use much more JavaScript than normal, they often
require interactions between controls, and they often request additional
information from the web server using a special browser object called
XMLHttpRequest, which is available to client-side JavaScript code.
2. Ajax: The Bad
There are two key
challenges to using Ajax. The first is complexity. Writing the
JavaScript code needed to implement an Ajax application is a major feat.
Fortunately, you'll sidestep this problem in this article, because
you'll use ASP.NET's Ajax-enabled features. That means you'll let
Microsoft manage the complexity instead of worrying about it yourself.
The other challenge to
using Ajax is browser support. The technology that supports Ajax has
existed for several years, but it's only now found consistently in all
major browsers. If you use the Ajax features that ASP.NET provides,
they'll work in Internet Explorer 5 and newer, Opera 7.6 and newer,
Safari 1.2 and newer, Firefox, and Google Chrome. This captures the
overwhelming majority of web users. (The actual percentage depends on
your audience, but over 95 percent is a good, conservative assumption.)
But what about the minority of users who are
using old browsers or have JavaScript switched off? It all depends on
the feature you're using and the way it's implemented. If you're using
the partial rendering support that's provided by ASP.NET's UpdatePanel
control, your page will
continue to work with non-Ajax-enabled browsers—it will simply use full
postbacks instead of more streamlined partial updates. On the other
hand, if you're using a more advanced Ajax-enabled web control, you may
find that it doesn't work properly or at all. The only way to know is to
switch JavaScript off in your browser and try it out. Either way,
there's a price to be paid for slick Ajax features, and that price is
increased web browser requirements.
Finally, Ajax applications
introduce a few quirks that might not be to your liking. Web pages that
use Ajax often do a lot of work on a single page. This is different than
traditional web pages, which often move the user from one page to
another to complete a task. Although the multiple-page approach is a
little more roundabout, it allows the user to place bookmarks along the
way and use the browser's Back and Forward buttons to step through the
sequence. These techniques usually don't work with Ajax applications,
because there's only a single page to bookmark or navigate to, and the
URL for that page doesn't capture the user's current state. This isn't a
showstopper of an issue, but it might cause you to consider the design
of your web application a little more closely.
3. The ASP.NET AJAX Toolkit
There are a variety of
ways to implement Ajax in any web application, including ASP.NET. To
implement it on your own, you need to have a thorough understanding of
JavaScript, because it's JavaScript code that runs in the browser,
requesting the new information from the web server when needed and
updating the page accordingly. Although JavaScript isn't terribly
complex, it's remarkably difficult to program correctly, for two
reasons:
The
implementation of key JavaScript details varies from browser to browser,
which means you need a tremendous amount of experience to write a solid
web page that runs equally well on all browsers (or the help of a
higher-level JavaScript library, such as jQuery).
JavaScript
is a notoriously loose language that tolerates many minor typos and
mistakes. Catching these mistakes and removing them is a tedious
process. Even worse, the mistakes might be fatal on some browsers and
harmless in others, which complicates debugging. (However, if you find
yourself in the unenviable position of trying to correct misbehaving
JavaScript code, you can get some help from Visual Studio's top-notch
JavaScript debugger.)
In this article, you
won't use JavaScript directly. Instead, you'll use a higher-level model
called ASP.NET AJAX. ASP.NET AJAX gives you a set of server-side
components and controls that you can use when designing your web page.
These components automatically render all the JavaScript you need to get
the effect you want. The result is that you can create a page with Ajax
effects while programming with a familiar (and much more productive)
model of server-side objects. Of course, you won't get quite as much
control to customize every last detail about the way your web pages
work, but you will get some great functionality with minimal effort.
NOTE
It's generally accepted
that Ajax isn't written in all capitals, because the word isn't an
acronym. (Technically, it's a short form for Asynchronous JavaScript and XML,
although this technique is now considered to be just one of several
possible characteristics of an Ajax web application.) However, Microsoft
chose to write the term in uppercase when it named ASP.NET AJAX. For
that reason, you'll see two capitalizations of Ajax in this article —Ajax when talking in general terms about the technology and philosophy of Ajax, and AJAX when talking about ASP.NET AJAX, which is Microsoft's specific implementation of these concepts.
4. The ScriptManager
In order to use ASP.NET AJAX,
you need to place a new web control on your page. This control is the
ScriptManager, and it's the brains of ASP.NET AJAX.
Like all ASP.NET AJAX
controls, the ScriptManager is placed on a Toolbox tab named AJAX
Extensions. When you can drag the ScriptManager onto your page, you'll
end up with this declaration:
<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
At design time, the
ScriptManager appears as a blank gray box. But when you request a page
that uses the ScriptManager you won't see anything, because the
ScriptManager doesn't generate any HTML tags. Instead, the ScriptManager
performs a different task—it adds the links to the ASP.NET AJAX
JavaScript libraries. It does that by inserting a script block that
looks something like this:
<script src="/YourWebSite/ScriptResource.axd?d=RUSU1mI ..."
type="text/javascript">
</script>
This script block doesn't
contain any code. Instead, it uses the src attribute to pull the
JavaScript code out of a separate file.
However, the ScriptManager is a
bit craftier than you might expect. Rather than use a separate file to
get its JavaScript (which would then need to be deployed along with your
application), the src attribute uses a long, strange-looking URL that
points to ScriptResource.axd. ScriptResource.axd isn't an actual
file—instead, it's a resource that tells ASP.NET to find a JavaScript
file that's embedded in one of the compiled .NET 4 assemblies. The long
query string argument at the end of the URL tells the ScriptResource.axd
extension which file to send to the browser.
The JavaScript files that
ASP.NET AJAX uses contain hundreds of lines of highly complex, concise
code that forms the basis for all the Ajax features you'll see in this article. However, these files are quite compact, requiring the client to
download less than 200 KB of script code (depending on the features
that you're using). When you're visiting an ASP.NET AJAX–powered site,
the script code is only downloaded once, and then cached by the browser
so it can be used in various ways by various pages in the website. (In
addition, ASP.NET sends a compressed version of the script document, if
the browser supports it. Currently, ASP.NET uses compression when
receiving requests from Internet Explorer 7 or later.) The bottom line
is pages that use ASP.NET AJAX features don't require significantly
longer download times.
Each page that uses
ASP.NET AJAX features requires an instance of the ScriptManager.
However, you can only use one ScriptManager on a page. ASP.NET
AJAX-enabled controls can interact with the ScriptManager, asking it to
render links to additional JavaScript resources.
If you're using ASP.NET
AJAX features throughout your website, you might choose to place the
ScriptManager in a master page. However, this can occasionally cause
problems, because different content pages may want to configure the
properties of the ScriptManager differently. In this scenario, the
solution is to use the ScriptManager in the master page and the
ScriptManagerProxy in your content page. (You can find the
ScriptManagerProxy on the same AJAX Extensions tab of the Toolbox.) Each
content page can configure the ScriptManagerProxy control in the same
way it would configure the ScriptManager—in fact, all the
ScriptManagerProxy settings are applied to the ScriptManager control
when the page is executed.
|
|
Now that you've taken a brief
overview of Ajax, it's time to start building Ajax-enabled pages. In
this article, you'll consider the following topics:
Using partial refreshes to avoid full-page postbacks and page flicker
Using progress notifications to deal with slower updates
Using timed refreshes to automatically update a portion of your page
Using the ASP.NET AJAX Control Toolkit to get a range of slick new controls with Ajax features