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:
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:
- Navigate to Trace.axd in the root of your application. For example, if
the URL for your application is
https://localhost/SampleApplication
, navigate tohttps://localhost/SampleApplication/trace.axd
to view the trace information for that application. - Select the "View Details" link for the request that you want to investigate:
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