This project is read-only.

Control-level AJAX Methods

A Sharp Distinction From ASP.NET AJAX or Anything Else You've Used

One of the most empowering characteristics of the AJAX Control Framework is that it lets mimic your server-side custom controls on the client-side as JavaScript objects. It doesn't mimic your controls exactly but gives you what you need to model it on the client-side to the point where it is seamlessly interconnected with its server-side representation. What I mean by this is that you can build your custom controls so that it's client-side version is synced with that of the server-side. In the end, AJAX Controls are meant to be server driven. Their implementation is meant to be centralized on the server. You shouldn't need to re-write 1000s of lines of control code in JavaScript in order to have your custom controls function as they do when all state is maintained on the server through postbacks. If an AJAX Control needs information or a refresh of itself, it'll contact the server and get the info it needs and update itself. I hope you agree with me what I say its stupid to build out and change the markup of a control with JavaScript when the server could be doing it for you, using the markup and code-behind have you already spent a ton of time writing. I'm sure many of those reading this have written markup into their JavaScript in order to quickly update content. You'll never be able to scrape those horrible memories from your brain.

But, it's still common to manipulate markup on the client-side with JavaScript instructions. Why? Because it's fast. Because there is no ASP.NET framework out there that will help you retrieve markup like you really need it to. Oh and remember folks, JavaScript may be interpreted, but hardcoding markup is still hardcoding. Markup files like .html, .aspx, and .ascx are meant to be changed way more so than .js are. The AJAX Control Framework is here now. Never fear!

The Purpose of Control-level AJAX Methods

The purpose of this delightful feature (and one that has certainly been done before) is to help custom control developers talk with the server to drive the state and presentation of their controls. Now don't forget, this library is meant for everyone, not just those who sit in their basement drinking sweet sweet iced tea with the lights off architecting custom control libraries (much like Telerik or DevExpress).... I wish I could do that.

Be sure to have read the Ensuring your AJAX control on the client-side loads after the DOM - Load functions and The 4 Base Methods sections before reading further. Or if you've used PageMethods before...just keep reading.

You define a Control-level AJAX Method by annotating a method with the AjaxControlMethod attribute. This attribute has only a default constructor and no properties so there are no parameters to pass to it. Here's an example of this from the BingMapsSample project.


public void ShowNextPage(int currentPage)
    resultsDataPager.SetPageProperties((currentPage * resultsDataPager.PageSize), resultsDataPager.PageSize, false);


(function($) {
    window["load_BingMapsSample_ucSearchResultsList"] = function(obj) {

        $(".pager a.next_page").click(function(event) {

            obj.ShowNextPage(parseInt($(".pager .current").text()), {
                autoUpdateHtml: true,
                onSuccess: function() { ucSearchResultsList.updateMap(); }


Whenever you annotate a method of an AJAX enabled control with the AjaxControlMethod attribute, that method will be mimicked automatically and attached to the client-side object representation, as a function of the same name, that is passed to that control's specific loading function. You may do this style of method annotating within any class of yours that implemented the IAjaxControl interface (so you're not restricted to defining methods in a Page class).

Last edited May 2, 2010 at 9:43 PM by peanutbutterlou, version 8


No comments yet.