• Choose a category
• All
• Classic-Fiction

By Root 5598 0

is any JavaScript object, filled with any information that makes sense to you, that gets passed automatically to any callback that handles the success or failure of the call.

Note

The JavaScript code injected for the proxy class uses the path property to define the URL to the Web service. You can change the property programmatically to redirect the proxy to a different URL.

Remote Calls via Page Methods

If you don’t feel like using Web or WCF services, a quick solution to expose Ajax-callable endpoints is based on page methods. Page methods are simply public, static methods exposed by the code-behind class of a given ASP.NET page. The run-time engine for page methods and Ajax-enabled Web services is nearly the same. Using page methods saves you from the burden of creating and publishing a service; at the same time, though, it binds you to having page-scoped methods that can’t be called from within a page different from the one where they are defined.

Public and static methods defined on a page’s code-behind class and flagged with the WebMethod attribute transform an ASP.NET page into a Web service. Here’s a sample page method:

public class TimeServicePage : System.Web.UI.Page

{

[WebMethod]

public static DateTime GetTime()

{

return DateTime.Now;

}

}

You can use any data type in the definition of page methods, including .NET Framework types as well as user-defined types. All types will be transparently JSON-serialized during each call.

Note

The page class where you define methods might be the direct code-behind class or, better yet, a parent class. In this way, in the parent class you can implement the contract of the public server API and keep it somewhat separated from the rest of the event handlers and methods that are specific to the page life cycle and behavior. Because page methods are required to be static (shared in Microsoft Visual Basic .NET), you can’t use the syntax of interfaces to define the contract. You have to resort to abstract base classes.

Alternatively, you can define Web methods as inline code in the .aspx source file as follows (and if you use Visual Basic, just change the type attribute to text/VB):

Page methods are specific to a given ASP.NET page. Only the host page can call its methods. Cross-page method calls are not supported. If they are critical for your scenario, I suggest that you move to using Web or WCF services.

When the code-behind class of an ASP.NET AJAX page contains WebMethod-decorated static methods, the run-time engine emits a JavaScript proxy class nearly identical to the class generated for a Web or WCF service. You use a global instance of this class to call server methods. The name of the class is hard-coded to PageMethods. Its usage is nearly identical to the proxy for Web or WCF services.

function getTime()

{

PageMethods.GetTime(methodCompleted);

}

function methodCompleted(results, context, methodName)

{

// Format the date-time object to a more readable string

var displayString = results.format("ddd, dd MMMM yyyy");

document.getElementById("Label1").innerHTML = displayString;

}

Note, however, that page methods are not enabled by default. In other words, the PageMethods proxy class that you use to place remote calls is not generated unless you set the EnablePageMethods property to true in the page’s script manager:

For the successful execution of a page method, the ASP.NET AJAX application must have the ScriptModule HTTP module enabled in the web.config file:

type="System.Web.Handlers.ScriptModule, System.Web.Extensions" />

For page method calls, therefore, there’s no page life cycle and child controls are not initialized and processed.

Note

From page methods, you can access session state, the ASP.NET Cache, and User objects, as well as any other intrinsic objects.