Section 4.8. Testing and Debugging Server-SideScript Files

4.8. Testing and Debugging Server-SideScript Files

Currently, no debugger that provides a way to examine data directly or step through code is available for testing and debugging server-side scripts. The primary way to get a view into the state of an executing script is to use trace( ) statements to output information. Trace output can be examined in different ways.

The NetConnection Debugger, discussed in "Using the NetConnection Debugger" in Chapter 3, will list trace( ) events under its Events tab and the output under its Details tab. This is most useful when you are working on a Flash movie and want to see server-side output as you make changes to the movie and have it connect and reconnect to FlashCom.

To test and fix server-side code, the primary tool for seeing trace output is the App Inspector movie ( app_inspector.swf ). Whenever a change is made in a server-side script, the instance must be reloaded so that the source files that contain the updated code are recompiled and executed. The App Inspector can be used to load, reload, and unload an application instance at any time. You can also easily select any running instance from a list and view connection and bandwidth statistics, stream and shared object status, and a live log that includes system messages and trace output.

Unlike other server development environments, trace output cannot easily be piped to a text file for later examination. However, FlashCom does provide a facility to record trace output in a recorded stream file. To enable application logging (Macromedia's term for recording trace output), an Application.xml file must contain the XML tag and value as follows :

 <RecordAppLog>true</RecordAppLog> 

Logging can create very large files over time, so it is often best to not make this adjustment in an Application.xml file for an entire virtual host. An Application.xml file can be placed in the home directory of the application that is being developed. When logging is turned on, a stream file with an .flv extension and named after the instance will be saved within a folder named after the application within the applications/admin/streams/logs/application directory. The file can be read using the Flash Communication Server Log reader available as a separate download from Macromedia. Please see Technote 16464:

http://www.macromedia.com/support/flashcom/ts/documents/flashcom_logging.htm

There are other alternatives for generating log output and log files. Flash Remoting can be used to send data to an application server where it can be stored in a database or written to a text file. When Remoting is used, a custom logging function must be called in place of trace( ) . Similarly, custom Flash clients can receive data via remote method calls where they can sort and analyze data before presenting it. Remoting is described in Chapter 11, and remote method calls are covered in Chapter 9. An application-level logging system is discussed in Chapter 12.

4.8.1. Organizing Test Scripts

During program development and testing, load( ) can be used to make testing of many different SSAS files a little easier to manage. If you had to create a new application home directory for every test script, you would end up with many different test folders. One trick is to use different instances to test different scripts within a single application home directory. One way to do this is to create a main.asc file with this one statement in it:

 load(application.name.split('/').pop(  ) + ".asc"); 

Then you can create as many test files as you like in the application's home directory. To run a test file, connect to an instance of your application with the same name. Suppose, for example, you are working on an application named courseChat and want to run different versions of the application's main file. You may have several main files named mainVersion1.asc , mainVersion2.asc , and so on. You can run any one of these files by using the App Inspector to load the right instance name, such as courseChat/mainVersion2 , and then reload it to check the output. If client interaction is required, a test client can be set up to connect to rtmp:/courseChat/mainVersion2 .

Using the main.asc file to load other files in the application's home directory works well for testing different main file versions. When a main file is ready to go into production, it can be moved into a production directory and renamed main.asc .

Testing individual objects and functions is also an important part of developing applications, and you may not want to clutter the application home directory with many test script files. As an alternative, a main.asc file can be created that contains this short script:

 this.tempPath = application.name.split("/"); this.tempPath.shift(  ); load(this.tempPath.join("/") + ".asc"); //delete this.tempPath;  // Uncomment this if you want to delete tempPath. 

The script will load files based on the full instance name. For example, if a client connects to an instance named rtmp:/courseChat/testBed/userClassTests , then the userClassTests.asc file in the testBed directory will be loaded and executed.