JSFL #include & classes.

I’ve been doing a lot of work with JSFL the last little while, and was starting to get frustrated with the inability to define my classes and methods in separate files. I did some hunting around, and found a couple of solutions that worked by putting objects in an implicit global scope, but this doesn’t seem to work in CS5.

After some messing around, I came up with an approach that seems to be working:

In MyClass.jsfl

MyClass = function() {}
var p = MyClass.prototype;
p.run = function() {

in main.jsfl:

var JSFL_PATH = fl.configURI+"path/to/jsfls/";
var included = {};
function include(file) {
	if (included[file]) { return; }
	included[file] = true;
var foo = new MyClass();

Grant Skinner

The "g" in gskinner. Also the "skinner".



  1. Thanks for that. It’ll be usefull.
    Working on JSFL this week too !

  2. Why do you don’t use runscript for globals scope?

  3. you may want to try xJSFL

  4. It might be smart to have an include_once() function, which would basically do the same thing as include() but it would keep track of all the included files, and help avoid including the same file twice.

    Therefore, if your included files include other files, it would help prevent accidental circular includes.

  5. This is really nice. But have you considered Coffeescript instead. Your example can be written in two lines as:

    class MyClass
    run: -> fl.trace "hello!"

    – Daniel

  6. ojes – that approach doesn’t seem to work in newer versions of Flash (scripts don’t seem to share a global space).

    darien – I’ve been keeping an eye on xJSFL, but thus far haven’t had a really compelling reason to use it (ie. benefits vs the pain of using pre-beta software).

    arbit – great minds think alike. Using this in a project last night, I immediately ran into that requirement. I’ve updated the post with the newer version.

  7. Is your ‘include’ function available globally so that you could reuse it within any other JSFL Classes in case they had dependencies to load too?

  8. You and I came to the same conclusion, although I handled importing and garbage collection a little differently.

    For instance, I use a statement like

    Assuming that Configuration/JavaScript is the root of the classPath, an import manager can resolve path and read/eval. If a file doesn’t exist, it will throw an informative runtime error.

    Import manager will keep a reference to the Class, and only import once if more import calls are made. (By other Classes, for example)

    Once the process is complete, a call to destroy() will cause Import manager to release all references of imported classes, essentially performing a form of “garbage collection”.

    Another idea I have successfully experimented with is pseudo-threading JSFL for longer processes, then caching results on hard drive as .json; it works on the same principal.

    For instance, I used this technique to add a “build state” to Flash to enable auto-complete of class names for Symbols. (Of course, I still use an Eclipse-based IDE for editing code, including JSFL)

    Here’s a question, do you think jangaroo (http://www.jangaroo.net/) could be effective for cross-compile Actionscript to JSFL? I’ve been toying with that idea to as a way to tackle more complex JSFL projects.

    Thanks for your thoughts!

  9. replace eval(FLfile.read(JSFL_PATH+file+”.jsfl”));
    with fl.runScript( JSFL_PATH+file+”.jsfl”);

    and you even get correct line-numbers and filepaths whenever an error is thrown.

Leave a Reply

Your email address will not be published. Required fields are marked *