Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Fundamentally, <a href="http://msdn.microsoft.com/en-us/library/ms178208.aspx" rel="noreferrer">Client Callbacks</a> and Ajax Page Methods are doing the same thing. They use an <code>XMLHttpRequest</code> object to send a request (usually asynchronous) to some URL, get the results of that request, then execute a callback method you've provided (<em>callback</em> with a lowercase <em>c</em>), passing the results of the request to your method. </p> <p>Having said that, there is one big difference between the two approaches:</p> <ul> <li><p><strong>Page Methods</strong> are implemented as static methods on your page. Your page class is just a convenient container for these methods, which could really be hosted anywhere (a web service, a custom <code>HttpHandler</code>, etc.). Since no instance is ever going to be constructed, the client doesn't have to send <code>ViewState</code> data and Asp.Net doesn't have to run through the <code>Page</code>'s lifecycle. The flip side is that you don't have access to to your <code>Page</code> class's instance methods and properties. However, in many cases you can work around this by refactoring instance methods into static methods. (See <a href="http://encosia.com/2008/04/16/why-do-aspnet-ajax-page-methods-have-to-be-static/" rel="noreferrer">this article</a> for more information.)</p></li> <li><p><strong>Client Callbacks</strong> are implemented as instance methods on your page. They have access to other instance methods on your page, including stuff stored in <code>ViewState</code>. This is convenient, but comes at a price: in order to build the <code>Page</code> instance, the client has to send a relatively large amount of data to the server and has to run through a fair chunk of the page lifecycle. (<a href="http://edndoc.esri.com/arcobjects/9.2/NET_Server_Doc/developer/ADF/ajax_callback.htm" rel="noreferrer">This article has a nice diagram</a> showing which parts.)</p></li> </ul> <p>Apart from that, the cost of setting them up varies quite a bit and clients use them differently:</p> <ul> <li><p><strong>Client Callbacks</strong> require a fair amount of idiosyncratic scaffolding code that is intimately coupled to Asp.Net (as shown in the link above). Given the much easier alternatives we have now, I'm tempted to say that this technology is obsolete (for new development).</p></li> <li><p>Calling page methods using <strong>ScriptManager</strong> requires less setup than Client Callbacks: you just have to pop a <code>ScriptManager</code> onto your page, set <code>EnablePageMethods = true</code>, then access your page methods through the proxy the <code>PageMethods</code> proxy.</p></li> <li><p>Calling page methods using <strong>jQuery</strong> only requires you to link the jQuery library (and familiarity with jQuery, of course).</p></li> </ul> <p>I prefer to use jQuery to access page methods because it's independent of the server framework and exposes just the right amount of implementation details, but it's really just a matter of taste. If you go with <code>ScriptManager</code>, its proxy makes the page method calls a little easier on the eyes, which some might consider more important.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload