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.
|