The main.asc File

The main.asc file is the heart of your application. You have used it already in previous chapters as a place for server-side ActionScript. Macromedia Flash Communication Server always looks for the main.asc file when it is loaded the first time. If the main.asc file is not available, Flash Communication Server looks for a file with the name of the application. For example, Communication Server would look for a file called myApp.asc within an application called myApp. main.asc is always loaded first, if it exists. All SSAS must stem from either of these files. The server looks first for main.asc, and then it looks for myApp.asc. If both files exist, main.asc takes priority, and myApp.asc is ignored. This does not mean that all SSAS must exist solely in the file. You can "include" external scripts inline. You saw this in earlier exercises when the components.asc file was loaded. This particular load reference includes the server-side counterparts for the Flash UI components that are nothing more than SSAS object classes.

The process of including scripts is handled by the load method. This method loads any ASC files relatively located to the main.asc or application-named file. Loaded scripts are inserted inline just like server-side includes, or a <CFINCLUDE> for those Macromedia ColdFusion buffs out there. They are compiled after being loaded with scripts inside the main.asc file. Their libraries are made available to the Application instances.

SSAS is compiled into the application each time it is instantiated . When a change is made to server-side files (ASC files), those changes do not take effect in an Application instance until it is reloaded. This can get tricky if you have multiple instances running. It is possible to have multiple versions of the application running, if you do not reload each instance. There are three ways to reload your application: through the Communication App Inspector, the Administration Console, or by using the ActionScript API.