Even though Flash MX 2004 has been out for nearly a year, I never took the time to really look at JSFL until a couple of days ago. Two things convinced me to play with it, the introduction of the JSFL File API in 7.2, and a huge project that had a lot of opportunities for JSFL streamlining.
Now that I’m into it, I’m a junky – JSFL kicks serious butt! After only a couple hours, I had already knocked out a bunch of scripts that help me streamline development, and I have a bunch of ideas for new ones in the very near future. Among the finished scripts are:
1) A script that automates the task of setting up an FLA for internal pre-loading – it walks through the library, turns off “export on frame 1”, and places an instance of exported clips onto a specified frame. I will be releasing this one with instructions for use later today or tomorrow.
2) A script that batch compiles, renames and moves FLAs. I’ll be making this script a little more generic and safe, then releasing it with instructions later this week.
3) JSFL that organizes the library according to linkage ids – we use very strict rules for assigning linkages at gskinner.com, so this script will clean up the library based on those ids. If you’re interested in this one, let me know in the comments and I’ll write up a blog entry on our linkage rules, and the JSFL itself.
NOTE: I would definitely urge a dose of caution when it comes to JSFL. The File API is extremely useful, but it also has the potential to be used maliciously. It is extremely simple to write a JSFL script that deletes critical files (intentionally or unintentionally). Pair this with the fact that JSFL files execute when double clicked, instead of opening to be edited, and you have a potentially dangerous situation. I would definitely urge MM to swap this behaviour in the next release of Flash – when I double click a JSFL, it should open to edit, so that I can review it’s functionality prior to running it (it’s way too easy to dbl-click by accident when you want to edit it).