13.7 Testing Server-Side Code | Flash Remoting: The Definitive Guide

Your server-side code should be tested and debugged in isolation, by using your own server-side pages that you've set up for debugging purposes only ”taking Flash and Flash Remoting completely out of the equation. You should be able to call your server-side methods from a basic page that contains calls to your remote methods using test data. By doing this, the server-side logic can be verified (and debugged , if necessary) in a much more logical and structured manner. One of the advantages of using Flash Remoting is that you can separate your business logic from your presentation logic. The server-side methods can be viewed as if they were modules in your overall application. Debugging modules individually can often be more productive than trying to look at the whole picture. Let's look at some of the debugging tools available in the major server environments supported by Flash Remoting. This is not an exhaustive list, as you can use many different server-side development environments and each will have its own debugging tools.

13.7.1 Debugging in ColdFusion

ColdFusion MX allows debugging information to be displayed, including the following information:

Execution times
Database activity
Exception information
Variables (Application, CGI, Client, Cookie, Form, Request, Server, Session, and URL)

Debugging must be turned on from the ColdFusion Administrator, as shown in Figure 13-5. There are two modes of debugging: Classic and Dockable. The Classic mode of debugging simply lists the information at the bottom of the page when you execute a ColdFusion page. The Dockable style opens a separate window with the debugging information contained in a handy tree. The panel can also be docked with your page, as shown in Figure 13-7.

Figure 13-7. Dockable ColdFusion MX debugging

Flash Remoting allows you to work with ColdFusion Components (CFCs) from within Flash. As an example, look at the searchProducts.fla file that we've been examining in this chapter. The service that it calls is a CFC named searchProducts.cfc . ColdFusion Components can also be called from regular ColdFusion pages that use HTML for user interaction. This can be very helpful when debugging your Flash Remoting applications, because it allows you to verify your server-side code separate from your client-side code.

The best environment for building ColdFusion pages that utilize CFCs is Dreamweaver MX, which is part of Studio MX. Building a sample page that uses the searchProducts.cfc can be done in five simple steps:

Set up a sample site in Dreamweaver (using the Site New Site option). Consult the Dreamweaver documentation for details on how to set up sites. Be sure to specify the server model as ColdFusion. If the site is set up correctly, Dreamweaver's Components panel will be populated with all the CFCs on your server.
Create a test page with a .cfm extension.
Drag the getSearchResult( ) method from the Components panel to the Code view of your .cfm page. This will create a complete <cfinvoke> tag for calling the remote method.
Add a <cfdump> tag to the page below your component invocation. The tag should look like this:
```
 <cfdump var=#getSearchResultRet# /> 
```
Press the F12 key to test the page in a browser.

The <cfinvoke> tag calls the method of the component, and the <cfdump> tag displays the result in the browser.

Returning momentarily to Flash, if debugging is turned on in the ColdFusion Administrator, you will be able to see all variables and error messages clearly in Flash's NetConnection debugger. For example, if the data source has not been set up yet, the NetConnection debugger would respond with an error message like this:

"Service threw an exception during method invocation: java.sql.SQLException: No such binding: Northwind"

With some experience, you will realize that this error most likely means that there is no data source set up in ColdFusion.

However, viewing the .cfm page that utilizes the same component in a browser gives you a much more descriptive error message than Flash's NetConnection debugger. As shown in Figure 13-8, the error message is much easier to decipher, gives line numbers for the error, and shows the actual code that caused the error. The actual error message on this page is:

"Data source Northwind could not be found."

It couldn't be any easier.

Figure 13-8. Error message in ColdFusion MX

Unfortunately, there is no debugging environment for ColdFusion MX coding, per se. In ColdFusion 5, you could do step-debugging with ColdFusion Studio, but the functionality was removed in the move to MX. Future generations of ColdFusion MX might contain step-debugging. For that reason, the <cfdump> tag is still the ColdFusion programmer's best friend. You can think of it as the ColdFusion cousin of Flash's trace( ) command. It dumps the contents of a variable or structure easily with one simple tag and attribute.

Along with the <cfdump> tag, you also have a < cftrace > tag at your disposal. You can use this tag in a fashion similar to <cfdump> , but it gives information that a simple dump of a variable won't, such as execution times. Also, <cftrace> tags are logged in the ColdFusion application logs, located in your ColdFusion_root \logs folder. If you use the <cftrace> tag in a page, the result will be written to the cftrace.log file.

The <cftrace> tag supports the following attributes:

abort: Yes or no
category: Any valid string
inline: Yes or no
text: Any valid string
type: Information, warning, error, or fatal information
var: Name of a variable to display

The category and text attributes allow you to set messages that can be useful in complex applications. You could, for example, set a category called " FlashRemoting " that you use in your ColdFusion Components. You can sort the log file on this category in the ColdFusion Administrator when examining your log files.

The <cftrace> tag also gives you the elapsed time between <cftrace> tag executions, so you can use it as a rudimentary timer as you debug and optimize your code.

The ColdFusion IsDebugMode( ) function can be used hand-in-hand with debugging. Using this function, you can sprinkle your code with <cfdump> and <cftrace> tags that are selectively called only when debugging is on. To do this, you can wrap the code in conditional logic, like this:

 <cfif IsDebugMode( )>   <cftrace category="TestingPhase2" var="rsGetProducts" /> </cfif>

This allows you to turn off debugging until you need it while you are in your testing phase. Having ColdFusion debugging turned on at all times increases the execution time of your pages and components substantially. For this reason, it is best not to use debugging until you need it.

Flash Remoting keeps its own log as well. In ColdFusion_root \logs , there is a flash.log file, which keeps all error messages that occurred through Flash Remoting ”in other words, any onStatus event messages that were returned to the Flash movie. These can be useful in debugging, and they can also be useful after an application is deployed.

Dreamweaver MX also has a Server Debug mode, but it simply lists the same information in the Results panel in the Dreamweaver environment.

13.7.2 Debugging in Java

Java environments are varied and diverse, and they number in the dozens. If you are writing and compiling Java code to form your Flash Remoting services, you likely have all the tools necessary to debug the server-side code at your disposal. It is important to choose a Java IDE that has a capable debugger. Some of the best are Borland's JBuilder, the open source NetBeans, and IntelliJ Idea. Each of these environments contains the step-debugging functionality that you will need for debugging Java code.

One of the nice things about the Flash NetConnection debugger when using Java services is that the Java stack trace is sent to the debugger's Call Stack pane. You can examine exactly where the error might have occurred. In many cases, line numbers pinpoint the errors for you.

13.7.2.1 Server logs

Logs for Flash Remoting can be found in the flashremoting-event.log file in JRun 4, and in the individual server log folders for other J2EE servers. In the log file, you will find stack traces for the errors in a Flash Remoting call.

13.7.3 Debugging in ASP.NET

Building applications and services in ASP.NET can be done from a variety of different places, including Notepad and a command-line compiler. There are several more sophisticated tools available that can be used to create and deploy ASP.NET applications.

13.7.3.1 Visual Studio.NET

Visual Studio.NET (VS.NET) contains some of the most sophisticated debugging tools around, making it almost a pleasure to look for bugs in your code. The Visual Studio tools are similar to those in the Flash interactive debugger but much more responsive and versatile. For example, breakpoints are set and remembered by the program. There is an Immediate window that allows you to type in any variable or expression and have the current value printed to the screen. Also, hovering your cursor over a variable in the code while debugging will pop up a tooltip with the current value of that variable, as shown in Figure 13-9.

Figure 13-9. The Visual Studio debugging environment gives immediate feedback via tooltips

Some of the features available in Visual Studio include:

Immediate window: Allows you to type in an expression and display the resulting value.
Watches: Multiple watch windows allow you to watch several variables.
Locals: All local variables within a function are displayed here.
Call stack: See the tree of functions that got you to where you currently are in the code.
Threads: Breakdown of the threads that are currently active.
Breakpoints: Listing of all current breakpoints, with the ability to temporarily turn them on and off without removing them from your code.
Step Into, Step Over, and Step Out: Buttons act just like the Flash interactive debugger variants.
Show Next Statement: Allows you to preview the next statement before stepping into it.

Building SOAP-based web services for Flash Remoting is also easy to do in Visual Studio. While you are building your web service, you can test from a browser; Visual Studio creates HTML-based interfaces to your web service that also allow you to trigger the debugger while you build the web service. For example, the HelloUser web service shown earlier in this chapter takes one argument. Figure 13-10 shows the temporary test page that is generated by Visual Studio as you debug the web service. You can supply the argument and hit the Invoke button to transfer the focus back to Visual Studio to continue to step-debug your code.

Figure 13-10. Web services can be debugged in Visual Studio

Of course, one of the best features is the ability to edit and change your code as you debug. If you come to an error while you are debugging, you can fix it on the spot and continue the debugging process from that point.

The temporary HTML files that are built by Visual Studio also contain all the SOAP packets that are used by the web service; both the request and response packets are shown in the browser.

If you are building DLLs, you can debug those as well, but Visual Studio generally requires that you set up test projects to be able to test and debug your DLLs.

13.7.3.2 ASP.NET Web Matrix

Visual Studio is a great programming environment, but it's not the only game in town for ASP.NET developers. Microsoft has also released a free IDE, called ASP.NET Web Matrix, that can be used to create ASP.NET pages, DLLs, and web services used in Flash Remoting, among other things. ASP.NET Web Matrix can be downloaded from:

http://www.asp.net

Although the IDE is similar to Visual Studio in look and feel, it is a lightweight application that doesn't contain all the bells and whistles of Visual Studio. One of the major missing features is the integrated debugger. Still, for building simple services, the Web Matrix can be the perfect environment.

The one area where it truly shines is in the building of SOAP-based web services. When you create a service, you have the same previewing features that can be found in Visual Studio. Still, without the step-debugging features of Visual Studio, you have to do some detective work to find bugs in your applications.

13.7.3.3 Server logs

Flash Remoting keeps a log in the bin folder of your ASP.NET application. If you are having troubles tracking down an error, look in the server log called flash.log . One error that I had trouble tracking down, because I received no error message in the NetConnection debugger, was found in the flash.log ; the trial version had expired and I had neglected to install the full version! Needless to say, when you don't have an error message to point you to an error, you often go around in circles looking for an answer. I could have saved a couple hours by going to the flash.log file right away.