You're probably used to my "it's not quite ready yet" updates, so here's another one, albeit with much less uncertainty than previous posts.

I presented at the LFPUG a few weeks ago, and it was great for many reasons. To see the presentation and download the slides, click here. The audio's not the best, it was fairly freeform, and I didn't show as much of the framework as I would have liked, but there you go.

Firstly, it was a great impetus to move the framework on to a stage where it HAD to work in front of an audience. Secondly, the physical process of presenting really made it clear to me which bits of the whole JavaScript / JSFL relationship were not fully understood by users. And thirdly, questions and feedback about WHAT JSFL can and can't do made it clear that many users still aren't clear on the role of JSFL within Flash, let alone xJSFL.

There's definitely going to be as much communication and design work to to be done as there is programming, that's for sure.

Just for fun, here's the final element I ended up demoing at the talk. Everything you see below is happening live, on the stage, and in the authoring environment:

It's not really representative of what the framework delivers, but it is a bit of fun, and hopefully shows what the ecosystem of using a decent editor and thinking more freely about JSFL can achieve.

Anyway - onto the framework progress, as that's pretty much what most of you will be interested in.

xJSFL core and bootstrap process

The xJSFL core, which includes folder structure, core libraries, file loading and running is now pretty much locked down. Here's how it works:

• xJSFL can be installed to any folder on your hard drive. You're no longer have to install to some ridiculous path like C:\Users\User\AppData\Local\Adobe\Flash CS4\en\Configuration\Commands
• Once installed, xJSFL boots automatically on Flash startup, loading and copying JSFL scripts to the xJSFL extension. My xJFSL bootup currently looks like this:

> xjsfl: running core bootstrap...
> xjsfl: loading "<xjsfl>/core/jsfl/xjsfl.jsfl"
> xjsfl: loading "<xjsfl>/core/jsfl/libraries/output.jsfl"
> xjsfl: loading "<xjsfl>/core/jsfl/libraries/class.jsfl"
> xjsfl: loading "<xjsfl>/core/jsfl/libraries/filesystem.jsfl"
> xjsfl: loading "<xjsfl>/core/jsfl/libraries/collections.jsfl"
> xjsfl: loading "<xjsfl>/core/jsfl/libraries/config.jsfl"
> xjsfl: loading "<xjsfl>/core/jsfl/libraries/module.jsfl"
> xjsfl: loading "<xjsfl>/modules/Snippets/jsfl/Snippets.jsfl"
> xjsfl: setting environment variables
> xjsfl: running user bootstrap...
> xjsfl: loaded!

• Once these scripts are loaded, they're available for as long as Flash is open, whether you run a script externally (which is normally sandboxed per execution), from a command, or from within a Flash panel.
• The trick is to initialize the current namespace you're running in with the following command:

xjsfl.init(this);

• That essentially copies any pre-registered classes / global methods to the namespace passed to init (usually, window).

There is also a core and user bootstrap. The core bootstrap loads the core framework files, in the correct order, so everything is available to you when you run your own JSFL scripts, as you can see above. This is how it looks:

try
{
	// feedback
		fl.outputPanel.clear();
		fl.trace('> xjsfl: running core bootstrap...');

	// load framework
		fl.trace('> xjsfl: loading "/core/jsfl/xjsfl.jsfl"');
		fl.runScript(xjsfl.uri +'core/jsfl/xjsfl.jsfl');

	// libraries
		xjsfl.classes.load
		([
			'output',
			'class',
			'filesystem',
			'collections',
			'config',
			'module'
		]);

	// modules
		xjsfl.modules.load
		([
			'Snippets',
		]);

}
catch(err)
{
	fl.runScript(xjsfl.uri + 'core/jsfl/libraries/output.jsfl');
	Output.error(err);
}

Note how classes and modules are loaded by name alone. The framework automatically works out how to find them if you don't supply a path, as they reside in a structured directory format.

There's also a user bootstrap, which runs after the core bootstrap. This allows you to run / register files or libraries you use often in your own JSFL development. Again, load once, use often.

Module framework

The next thing I want to tell you about is the module framework. It took a while to really nail this one down, but I think I'm at a stage where I can safely say "this is how it's going to be".

First of all, what is a module? Well, at the moment, its definition is this:

• A self-contained collection of  files, that can include
  • core JSFL code
  • JSFL libraries
  • user interface files (XUL definitions or SWF panels)
  • preferences (saved as XML files)
  • assets, such as icons, templates, or FLAs
  • any other files

An example of a module is the Snippets panel that comes with xJSFL. It holds the following files, that all interact together to provide rich functionality via a Flash panel:

• An assets folder, that contains over 2000 png icons
• An icons.xml file that contains an index of all the icons
• The main Snippets.jsfl file that extends the xJSFL Module Object (which contains common module code, such as preferences functionality), to which Snippets adds about 15 methods that will be accessed from the Flash Panel via the Snippets namespace @ xjsfl.modules.snippets
• The main Snippets SWF panel that is copied to the Flash WindowSWF folder on boot. This panel provides the front-end interface to all the functionality in the core JSFL module. The panel itself is compiled from a small set of standard AS3 classes to provide standardised (x)JSFL access.

The key breakthrough with modules, is that JSFL code now stays where it should - namely, in JSFL files on the hard disk, not in some bastardised MMExecute() multi-escaped quotes clusterfuck. Instead, what you do when using Flash panels is to mirror the JSFL API of your module in ActionScript, extending the xJSFL AS3 Module class.

In the case of Snippets, both the AS3 class and the JSFL library have exactly the same methods, so you know when you call browseFolder(path) in AS3, the appropriate browseFolder(path) method in your library will be called.

This approach basically standardises both the AS3 (Flash panel) and JavaScript (JSFL) sides of the MMExecute connection. It's exactly the same principle as you'd use when communicating with a server in Flash Remoting. You set up your API on both the server and the client, then use API calls to get tasks done at either end.

You probably read a minute ago about preferences, and this is one of the aspects I'm most pleased about.

Preferences are built into xJSFL as a class type. You simply declare a Config object, then read or write to its XML component using standard E4X just as you would in AS3. Yes - the SpiderMonkey engine allows you to write XML natively!

The Config class then wraps this functionality and takes care of where to save and load the XML from within the xJSFL framework filestructure.At the moment, there are two Config types, Settings and Data. They perform and are interacted with the same way - but Settings are easier to set up and have a few defaults that Data do not.

Honestly - it could not be easier (note that this code is JSFL, NOT ActionScript):

var settings = new Config('user');
settings.xml.@name = 'Dave';
settings.save();

Of course, this being E4X, you can do anything you can do in AS3, such a expressions, queries, you name it.

Komodo Edit macros

Quite a few people at the LFPUG were surprised with the choice of Komodo Edit as my editor of choice for JSFL, namely, as they had never heard of it, and a lot of people are using Eclipse with FDT.

Now, I've nothing against Eclipse, but it's a fairly lumbering leviathon, whereas Komodo is both much lighter-weight and just so much easier to build new functionality into.

In fact, a large part of my talk was dedicated to showing the fantastic features of Komodo, such as:

• Language completion
• Plugins, such as New Source Tree
• Live feedback on errors
• Intelligent typing
• Snippets
• JavaScript macro functionality

Just to finish off, I thought I would share with you the three publishing macros I've developed for Komodo that will really make your JSFL testing fly:

1. Run File (CTRL + Enter) - saves and runs the current JSFL tab in the editor
2. Run Project (CTRL + SHIFT + Enter) - saves all open files, then runs the left-most JSFL tab in the editor. This allows you to work on a library, for example, but run the main file in the project by placing on the very left
3. Run File on Selected Library Items (CTRL + SHIFT + Alt + Enter) - we've all been there. You have 250 illustrator graphics brought in, and you need to make identical updates on all of them. Well, now you can perfect the JSFL on the open library item, then  when ready, have the script run on any selected items, all without writing any extra code, such as mucking about with i-loops, copy/paste or runScript().

So that's it!

I hope it's not too annoying for you to have me dangle this stuff on a string in front of your faces, and after all this time I hope you are still somewhat interested in JSFL. It's going to be an exciting time for JSFL again soon! I hope you'll be there when xJSFL is finally released, in I hope the next 6 weeks or so.

Cheers,
Dave