Ajax-Enabled Server Controls

Since everything is becoming Ajax-enabled overnight these days, I’m really curious to see how the server control paradigm changes.

Case in point: while extending a third-party control I mentioned previously, I noticed—through the eyes of Reflector—the control was rebuilding itself three times (!) during its life cycle by calling CreateChildControls directly (not via EnsureChildControls, mind you): in OnInit, in DataBind and OnPreRender.

That’s some pretty wild coding, but I trust the vendor had a good reason to develop the control this way. Obviously, it goes through a shortened life cycle upon an out-of-band call, i.e. it pretty much is done rendering after OnInit, which creates some challanges to subclass this control.

Whichever way the changes swing, they’d better have little to no impact on the normal life cycle of server controls. Otherwise we’ll have to learn some pretty nasty hacks. I believe the Atlas team is on the right track:

Rather than performing a real postback, we simulate a postback using the familiar XMLHTTP object (or in Atlas using the Web.Net.WebRequest class). On the server, the page is processed as if it were a real postback in response to things like submit buttons or controls (including 3rd party ones) that call __doPostBack. For example Page.IsPostBack returns true. Server-side postback events continue to fire, and your event handlers continue to do work as they did before.

Way to go!