What separates Web development with ASP.NET AJAX from "normal" development with ASP.NET?
Ajax applications have changed the way the user interacts with a Web page. An example is how user input gets processed. Before Ajax, for example, the user typically filled a form, submitted it and then had to wait for the page to re-load and notify him on the status of the operation. This resulted in intermittent interaction due to the Web page being refreshed to process the user input. On the other hand, the user was aware that the page was being reloaded because the server was processing the form.
With Ajax, we could process the same form in the background and even eliminate page refreshing, thus dramatically enhancing the user experience; but now we need to find new ways for keeping the user informed on what's going on, maybe by displaying a progress bar or an animated gif to signal that something is happening on the server. Moreover, with Ajax the user interface remains responsive while the input is being processed; therefore we have to handle new scenarios where multiple requests are sent to the server from the same page.
More on ASP.NET AJAX in Action
Listen to a podcast with co-authors David Barkol and Rama Krishna Vavilala
Check out the book (Manning Publications Co.)
Regarding its limitations, I think that one could be, at the moment, the very young age of the framework. Compared to other frameworks and libraries, the 1.0 release has been out recently and needs to pass the "test" of real-life, enterprise Web applications. Moreover, the young age of the framework makes it difficult to find documentation, online literature and books on the subject.
In fact, the library offers the possibility to debug code with dedicated methods, to perform browser detection, to use an API that offers a cross-browser interface to DOM programming. Given the various implementations of the DOM that exist around, having an API that automatically calls the right function based on the detected browser avoids writing duplicated code for each browser targeted.
The Ajax Control Toolkit aims at becoming the biggest collection of open-source (shared-source) Ajax-enabled controls. The Toolkit is an open source project created by Microsoft and owned by the Agility Team. Quickly, it became one of the most downloaded libraries of Ajax-enabled controls. As a result, the Agility Team decided to open it for contributions from the community.
I'm amazed by the works made by the numerous contributors who submitted powerful controls like the Calendar or the TabControl. In the Toolkit we find many controls Web developers need to add Ajax capabilities to Web sites, like the classic auto-complete textbox, Ajax-enabled validators, a dynamic modal popup and many more. I've contributed to the Toolkit with a Slider control, which uses an internal drag and drop engine embedded in the Toolkit.
More on ASP.NET AJAX
The Toolkit doesn't offer only Ajax-enabled controls. Instead, it provides also tools for making it easier to develop such controls. For example, the Toolkit puts in our hands a powerful framework for realizing animations and visual effects. It also offers an API for creating Ajax-enabled controls, which leverages the one provided by ASP.NET AJAX. When Microsoft released ASP.NET AJAX 1.0, it said it would be releasing the source code as well. What does that mean for developers?
The source code has been released and this opens new possibilities for developers to study and modify the code to fit their needs. Having the source code means having the possibility to debug the code in Visual Studio, for example. In turn, this can help developers to find bugs more quickly and to potentially have them fixed by the Microsoft Ajax team in less amount of time. Ajax is a great innovation, but are there any scenarios in which a developer should avoid Ajax?
Surely there are some scenarios in which using Ajax would result in a poor user experience and even in security-related issues. Let's take the two typical scenarios where Ajax is used, the dynamic update of the layout of the page and data processing happening in the background.
In the first case, we may think that manipulating the HTML on client side would always lead to better performance. Actually, this is not true in many cases, especially when large chunks of markup are processed. As a consequence, abusing Ajax in this case could even result in a huge performance drop.
Another common mistake is to perform some activity in the background without properly informing the user on what's going on, or without handling multiple requests submitted to the server. In this case, we may experience a slow-down and the page could become un-responsive or behave in unexpected ways.
My suggestion is to always stick to existing Ajax patterns. At the moment, many patterns have been defined and catalogued, and many are being defined day after day, as soon as developers continue to experiment with Ajax and use it in production scenarios. Tell me a little bit about your book. What do you focus on? How is it structured? Is it geared toward beginners or more advanced developers?
In the server-centric model, we use of the glorious UpdatePanel control together with Ajax-enabled controls like Extenders and Script Controls. For this reason, the book has a chapter that introduces the server-centric model by upgrading an existing ASP.NET application to ASP.NET AJAX. Two chapters are dedicated to the UpdatePanel and one is dedicated to developing Ajax-enabled controls. There is also a chapter dedicated on how to leverage the ASP.NET AJAX Control Toolkit API and its animation framework.
An interesting chapter is the last, where we give examples of common AJAX patterns implemented using ASP.NET AJAX. We also provide re-usable code for extending the Microsoft Ajax Library itself. For a developer who is new to Ajax, what is the best way to get started with ASP.NET AJAX?
These are my suggestions:
- Buy our book, ASP.NET AJAX In Action.
- Buy a good book entirely dedicated to Ajax and Ajax patterns, without being tied to a specific Ajax framework.