70-562 Server-side AJAX

Server-Side AJAX is conceptualy simialr to normal asp.net full page processing. But instead of posting data back to the server and recieving an entire page in response, the  server returns a small chunck of HTML to update only a small section of the page, code in teh client browser takes care of updating for that section of the page, without redering the whole page, with less data passed between client and server.

One nice thing about Microsoft's implementation of server side AJAX, unless you're doing something unusual, you dont need to know javascript or even know AJAX mechanism that cause AJAX request and response. This makes it easy to both create new web pages or retro fit existing ones to make them more responsive to user without writing a single line of Javascript code. There is a cost for this simplicity of course, every action on the client requires a round trip to the server, admitedly it's a more lightweight request than response, but it has much of the same processing overhead as a normal page PostBack.
Nevertheless, Server-side AJAX can vastly improve the resopnsivness of a typical webpage that posts back to itself.

Microsft implementation of AJAX are through 5 server side controls, alot of work can be done with only these 5 controls and they fit seamlessly in the existing ASP.Net model.
The page designer allows ot swithc back and forth to add the control in design and tweak them in source view, or you can write raw HTML in source view and check it in design view once in a while to see how it looks.
Unfortunetly it doesnt support all of the features of the server controls. Often features have to be added in source view.

ScriptManager: One per page, it has no runtime interface, and manages the script and AJAX features on the page.

It also magages messages passed to and from the server, he can marshal messages using SOAP or JSON, 2 of the common web data formats.

When adding a UpdatePanel, the ContentTemplate element has to be added manually within the UpdatePanel, and all controls added need to be within the updatepanel and the ContentTemplate.


In the case of a drop down list and list view, master/slave model, the drop down list doesnt require to be regenerated each request, only the list view.To do this, make a seperate datasource and put it outside of the update panel. Other important thing that needs to be fixed is since the drop down list is outside of the panel, it's event wouldn't trigger the AJAX request.

This can be done by selecting the update panel in design view, going to it's properties, Trigger property, Collection, we want a AsyncPost abck, and we will add one, selsect the control(the drop down list in this case) and the event name(SelectedIndexChanged).So, include in the UpdatePanel, only the controls that are going to CHANGE as a result of the AJAX request, don't include teh triggering control.

AJAX calls are async, so it doesnt block the interface, but this can take some time, but the page should should an UpdateProgress control. It's possible to set a message but also an image for the UpdateProgress control.

We can introduce a delay with DisplayAfter attribute in milliseconds, so that the UpdateProgress doesnt show unless it's needed.

You can use mutliple update panel, all of the updatepanel update on every AJAX request and reponse, but it has all the tools to coordinate the requests. The UpdateMode of an update panel can be set to Conditional.

A page can only have one outstanding request at a time on the page, all other earlier requests in panels launch at the saem time, only the last one is kept.Sometimes instead of having mutliple panels, it can be done with a mix of server and client side AJAX.

Timer: the timer can update the page at intervals, without flashing the page, so if a user goes away, the page will stay current. The timer is not contained without an UpdatePanel. REckless use of the Timer control, for thousand of users on your server could add alot of trafic.

ScriptManagerProxy: Access a master page's script mananager from a content page. Infact, there is no need to add a script manager control if it already exists in the master page. But the proxy allows to change the script manager if needed in the case when that specific page need to use special settings, in this case the settings in the proxy would override the ones in the SCriptManager, and the rest of the settings of the ScriptManager would still be used. If a proxy is added to a page when the master page does NOT contain a SCriptManager, this will show an error messge.