MSDN Magazine - October 2007 - (Page 49)

sarily involved with an ASP.NET AJAX service. But the support for SOAP clients is guaranteed, unless it is explicitly disabled in the web.config file. For an ASP.NET AJAX service to work as expected, the incoming request must have the content-type HTTP header set to application/json. This is also an excellent remedy against cross-site attacks conducted through the tag. Figure 3 Parameters of the ScriptMethod Attribute Parameter ResponseFormat Description Specifies whether the response will be serialized as JSON or as XML. The default is JSON, but the XML format can be handy when the return value of the method is XmlDocument. Indicates whether an HTTP GET verb can be used to invoke the Web service method. For security reasons, this is set to false by default. Indicates whether all return types, including strings, are serialized as XML. The default is false. The value of the property is ignored when the response format is set to JSON. UseHttpGet Invoking AJAX Services To invoke an AJAX service, an AJAX client follows the same pattern used to reference Web services in Windows and classic ASP.NET applications. A proxy class provides the same interface locally as the remote service. In ASP.NET AJAX applications, this proxy is a JavaScript class that the runtime generates when the page is downloaded. The JavaScript proxy class has the same name as the script service and a number of additional properties. It features the same set of methods, although with a slightly extended signature. In general, there’s no need for you to snoop into the source code of the proxy class. But if you want to take a look at its structure, try invoking the following URL from the browser’s address bar: http:// /service.asmx/js XmlSerializeString a successful call, the results parameter is an object that contains the JavaScript version of the method’s return value. For the failure callback, instead, this represents a Sys.Net.WebServiceError object. Building the User Interface AJAX is all about the user’s experience in the broadest sense— continuous feel, flicker-free updates, interface facilities, mashups, live data, and so on. But you can only utilize the browser and its set of programmability features—primarily, the browser’s object model, DOM implementation, support for DHTML extensions, CSS, JavaScript, and plug-ins. JavaScript is the main tool for building and manipulating the UI. The typical pattern for user interface tasks entails the client using JavaScript to invoke remote services, receiving JSON or perhaps XML data, and then rearranging the page to show changes. Such a simple model is not necessarily effective when projected to the size and complexity of a real application. Rearranging the page to incorporate fresh data following a remote call poses nontrivial issues as the structure of the UI gets increasingly sophisticated. The point is, where’s the threshold at which a sophisticated UI becomes a problem? There are essentially three user interface features that each realistic application, especially line-of-business applications, depend upon: Figure 4 Properties of the JavaScript Proxy Class Property Path Timeout Description Indicates the URL of the underlying Web service. Indicates for how many milliseconds the method is allowed to run before a timeout is called. Indicates the default JavaScript callback function to invoke for a successful call. Indicates the default JavaScript callback function, if any, to invoke for a failed or timed-out call. Indicates the default JavaScript object, if any, to be passed to success and failure callbacks. The browser will download a JavaScript file that you can save to your local disk for later perusal. The JavaScript proxy class inherits from a base class named Sys.Net.WebServiceProxy. This provides the basic capabilities for placing JSON calls. The code download for this column provides a proxy class for a Web service with the following interface: interface ITimeService { DateTime GetTime(); string GetTimeFormat(string format); } The JavaScript proxy class features the properties listed in Figure 4. Each method mirrored has three parameters in addition to its regular set of arguments. They are the callback function to call if the method is successful, the callback function to call if the method fails or times out, and the context object to pass to both callbacks. The three default-related properties shown in Figure 4 allow you to reuse the same function for multiple calls—a unique JavaScript function to handle errors, for instance. Here’s some sample code that invokes a remote AJAX service from an ASP.NET AJAX page: function getTime() { IntroAjax.WebServices.TimeService.GetTimeFormat( “ddd, dd MMMM yyyy [hh:mm:ss]”, onMethodComplete); } function onMethodComplete(results) { $get(“Label1”).innerHTML = results; } defaultSucceededCallback The callbacks invoked at the end of a method call (regardless of the result) have the following prototype: function method(results, context, methodName) defaultFailedCallback The context parameter represents the context object specified when the call was made. The methodName parameter is a string set to the name of the service method. Finally, for a callback invoked for defaultUserContext Cutting Edge october2007 49

Table of Contents Feed for the Digital Edition of MSDN Magazine - October 2007

Cover Contents Toolbox CLR Inside Out Basic Instincts Data Points Cutting Edge Pooled Threads WPF Threads Parallel Linq Parallel Performance Mobile Apps Test Run Foundations Windows with C++ Netting C++ .NET Matters { End Bracket } Net Nuptials

MSDN Magazine - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.