by Grant Skinner

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() {
	fl.trace("hello!");
}

in main.jsfl:

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

Grant Skinner

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

@gskinner

If you enjoyed this, you might like these articles…

Update: JSFL OpenBoundClasses, JSFL rocks., JSFL FLA Batch Compiler, Prep For Zoe JSFL Command

9 Comments

  1. Twinspirit November 7, 2011 at 9:39pm

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

  2. ojes November 8, 2011 at 5:03am

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

  3. darien November 8, 2011 at 6:45am

    you may want to try xJSFL

  4. artbit November 8, 2011 at 7:40am

    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. Daniel Ribeiro November 8, 2011 at 9:16am

    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!"

    Cheers,
    – Daniel

  6. Grant Skinner November 8, 2011 at 10:55am

    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. Pierre Chamberlain November 9, 2011 at 10:35am

    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. Evan Gifford December 8, 2011 at 4:29am

    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
    import(“org.pinky.utils.LibraryUtils”);

    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. ScrambledRK June 20, 2012 at 2:14am

    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.

Comments are closed.