Load process

xJSFL comprises multiple executable files that the developer will use to build JSFL scripts and applications. In order for the various parts to be used, they need to be loaded from disk, and be made available globally in the Flash Window object, just like a regular Internet browser.

This happens in a sequence of events when Flash starts, called the bootstrap, which runs as follows:

1. The xJSFL Loader runs, setting some initial variables
2. The Loader then loads the following files:
1. The core bootstrap. This in turn is responsible for loading:
1. The xJSFL Core
2. All core libraries and classes
3. All core modules
2. The user bootstrap. The user can put any code he or she likes here, such as:
1. Code to load user libraries (set as default)
2. Initialization code

Initialization

Once the bootstrap has finished, all framework and specific user code will be loaded and ready for use.

Making this code available for subsequent script executions is as simple as calling a single function, before running any other JSFL code:

xjsfl.init(this);

Once init()ed, you will be able to access and run use the framework as expected.

Note that:

• For External scripts, you need to init() every time.
• For SWF panels, you only need to init() once per panel.
• For Commands, you only need to init() once per document.

The reasons for this are due to scope and persistence in the JSFL environment, and are discussed (if you want to know more) in the following section.

Environment, scope and persistence

In order to better understand why you need to init() your xJSFL scripts every time, it's worth going over some of the finer points regarding the environment in which JSFL runs; specifically how scope and persistence vary depending on where code is run from, and how xJSFL gets round these limitations.

In the same way that browsers run sites in separate windows (scopes) Flash runs JSFL code in separate scopes, some of which retain variables between calls (persistent) and some of which do not (non-persistent).

The scopes and persistence are:

• Externally-run scripts (non-persistent)
• Commands Menu (persistent per-document, non-persistent if no documents open)
• SWF Panels (persistent per-panel)

What this means in practice is that for general JSFL development (externally-run scripts) where the scope is non-persistent, JSFL code needs to be loaded each and every time a script is run. As you can imagine, this could be an expensive operation!

As described above, the strategy that xJSFL uses in order to initialize (or re-initialize) the framework between non-persistent external calls, is upon loading for the first time (the bootstrap) it caches classes, libraries, and global functions in the global window.xjsfl namespace (the actual xJSFL extension), then each time framework code is needed, it copies all objects from RAM into the desired scope as necessary (the init() function).

For persistent scopes (document Commands and Panels) this is not a big issue, but for external development, it's a big time-saver as it's RAM, not disk-based.

Next steps

• Folder structure