Overview of Popular JavaScript Frameworks - ASP.NET AJAX | 3 | WebReference

Overview of Popular JavaScript Frameworks - ASP.NET AJAX | 3


[prev]

Overview of Popular JavaScript Frameworks - ASP.NET AJAX [con't]

HTTP Requests

More complex client-server interactions can be performed using the Sys.Net.WebRequest class. Calling its methods directly gives you the ability to set HTTP request properties, subclass the Sys.Net.WebRequestExecutor class, access header information, check the HTTP status code and other advanced functionality. Here's an example of a GET request that retrieves and displays the contents of a static HTML page. Unlike our last example, this time a ScriptReference is created to point to an external JavaScript file:

Here'is the JavaScript code in the asynch_comm.js file that performs the Ajax request. The GetWebRequest() function creates the Sys.Net.WebRequest object and manually sets a number of its properties before invoking the GET call. The OnWebRequestCompleted() function displays the data in the resultElement:

XML and JSON Serialization

Using either of the methods described above allow you to accomplish many different tasks, such as sending parameters, returning values and setting the data type. For complex data, XML and JSON are your two best data format choices. In the following example, we have a server-side method called GetXmlDocument(), which accepts three arguments: the onSuccess callback function, the onFailure callback function and the context object. As we will see, this allows us to do different things, based on the context. The SucceededCallback() function accepts the results of the server call, the context and the name of the calling method (which we won't be using). Depending on the user context, we either parse the XML document to retrieve the value we want, or we simply display the entire string as plain text:

The last line in the script tells the ASP.NET AJAX Framework that the client script has completed loading. All registered external scripts should include this as the last line.

Here's a snippet from the WebService.asmx file that we called in the client-side script above. The "ASM" part of the ".asmx" extension stands for Active Server Method. The "X" distinguishes an ASP.NET file from the older "classic ASP." The code defines a Web service to be called by an Active Server Page (.aspx). The server-side script, which is typically written in C# or Visual Basic, is automatically compiled by the server when a request to the service is made. Our example is written in VB:

The next example retrieves a more complex data type in JSON format. Here, the ResponseFormat is explicitly set to the ResponseFormat.Json enumerated type, although it's not necessary because JSON is the default return type. The Person class (not shown) contains three properties: The individual's name, Date of Birth, and an array of friends (also of type Person):

The JavaScript file calls the GetPerson Web service with the userContext of "JsonPerson" this time so that the SucceededCallback knows what to do with the result. There's no need to parse the JSON return object; its properties can immediately be accessed using dot notation:

Debugging your Scripts

The combination of server and client code inherent in Web applications can make testing and debugging a real challenge. With so many components in play, it can be difficult to ascertain exactly where an error is being generated. This is one area where a good framework can really shine. ASP.NET AJAX provides several ways of debugging your Web apps, such as type and argument checking, exception throwing and tracing capability. It also has separate architecture models for release and debug modes. Release mode provides error checking and exception handling optimized for performance, with minimized script size; debug mode provides more robust debugging features, using the Sys.Debug class. It has methods for displaying objects in readable form at the end of a Web page, shows trace messages, enables you to use assertions, and lets you break into the debugger. To enable debugging for the whole site, add a compilation element to the site's root Web.config file, and then set its debug attribute to true:

Alternatively, you can perform debugging on a page-by-page basis by setting it at the top of the .aspx file:

Tracing Server-Side Execution

There are two ways to view trace output: at the end of the page, or in the Trace Viewer tool. The latter is best for debugging asynchronous calls because they don't refresh the whole page. If you want trace information to appear at the end of the page that it's associated with, you can set the trace element's PageOutput attribute to true. For example, the following application trace configuration collects trace information for up to 40 requests and allows browsers on computers other than the server of origin to display the trace information at the bottom of the page. The PageOutput attribute is usually used in conjunction with the localOnly attribute, which specifies whether or not the debugging is limited to the server:

Here's the line for setting it on a page-by-page basis:

To view trace details for a specific request in the Trace Viewer:

  1. Navigate to Trace.axd in the root of your application. For example, if the URL for your application is http://localhost/SampleApplication, navigate to http://localhost/SampleApplication/trace.axd to view the trace information for that application.
  2. Select the "View Details" link for the request that you want to investigate:

The Trace Viewer Tool

More on the Debug Helper Class

Use the Sys.Debug class to display objects in readable form at the end of the page, show trace messages, use assertions, and break into the debugger. You can attach the Visual Studio debugger to Internet Explorer to view debugger trace messages in the Output window. Even if you're not using Visual Studio, you can still view debugger messages in Internet Explorer by creating a <Textarea> element on the page with an ID of "TraceConsole." In other browsers, such as Mozilla Firefox, you can view debugger trace messages by using tools that are available as extensions. The Apple Safari and Opera browsers have debugging consoles in which to view trace messages. Here's a JavaScript function that validates a number (n) and output a debug message if it fails:

The Decision

Now it's time for you to narrow down your list of candidates. While it's bound to be a difficult decision, as all of the frameworks that we've explored in this series have their share of strengths; the following factors should help you to hone in on the one that best suits your needs:

  • the Framework's particular strengths (visual effects vs. OO extensions)
  • support
  • documentation
  • language emphasis (HTML vs JavaScript)
  • scalability
  • acceptance in the Web development community
  • personal style preferences (succinct vs. explicit coding style)

I hope that the information that was presented in this series gives you all the information you need to make a sound and educated decision. At the very least, one could expect that these articles have impressed on you the myriad of benefits that frameworks can offer you. There are too many to ignore!

Original: December 17, 2008


[prev]