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).
Anyway, definitely more info on this coming soon, including some cool stuff related to gModeler. I’ll also be posting on the status of glic before too long.
I am interested in learning about the linkage rules. I work alone and need a pragmatic system for setting linkage id’s.
How’s daedalous coming along. Public preview online soon?
~Joe
Awesome. I just started looking into JSFL the other day also when my copy of Extending FlashMX 2004 arrived. While I haven’t done anything as involved as you, I did write a simple command with UI that automates some basic text and image transitions. Its amazing how much time you take doing basic transition tweens.
– John
Definitely interested in your linkage naming conventions, and more interested in the updated status of glic
JSFL Rocks indeed. Although, I believe that the fact that a jsfl file will execute rather than be edited makes it even cooler. More powerful, but yes, to be used with caution. Perhaps MM could give you an option to “Warn before executing external JSFL scripts.” or the option to edit / run on double clicking.
Would be nice even if it just popped a dialog asking you wanted to edit or execute it, with a checkbox to make my choice the default.
Would be curious to see what your practices/conventions are about Linkages… the JSFL sounds handy, I’d curious to see what you have come up with. The really large, compartmentalized projects basically require conventions that are well formulated from the outset and anyone embarking on such a project would surely benefit from them.
I agree, JSFL rocks!
However, on the subject of security with the FLfile API. I agree that people have to be careful what extensions they download and use from the Macromedia Exchange – I hope they start testing each and every extension that is submitted to them during the approval process.
However, lets not over do it. You should never trust anything that you download from the internet and install on your local machine – you can never be 100% certain.
What about
“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.” ,
has this been released? Sounds like a real helper for everybody’s preloading troubles..?
Sorry, forget it, should’ve read the other posts first 😀
New post on the site then again, hehe.
Have you found that the fl.saveDocument() function ignores any changes to the file?
I was trying to set up a script to rename a textfield instance in a number of clips. While the instance name DOES change, this change is discarded upon saving.
I have some sample jsfl code to reproduce the issue:
var originalInstanceName="originalInstanceName";
var newInstanceName="newInstanceName";
var sampleText="Foo.";
// create the new Document
var doc=fl.createDocument('timeline');
// add a text field
// it's ridiculous that:
// a) you can't name the instance in this function
// ...and/or...
// b) this method doesn't return a reference to the text field, so you can't name the instance that way either!
doc.addNewText({left:0, top:0, right:100, bottom:100} ,sampleText);
// name the instance
// hard to believe that this is the only way to find and name an instance
var tf=doc.getTimeline().layers[0].frames[0].elements[0];
tf.name=originalInstanceName;
// save and close the docmuent
fl.saveDocumentAs(doc);
fl.closeDocument(doc);
// now reopen the document
var fileURI = fl.browseForFileURL('open',"Select the document you just created");
var savedDoc=fl.openDocument(fileURI);
// rename the text field
var instanceObjects=fl.findObjectInDocByName(originalInstanceName, savedDoc);
for(var i=0;i<instanceObjects.length;i++){
var instanceObject=instanceObjects[i];
var instance=instanceObject.obj;
instance.name=newInstanceName;
}
// save and close the document
fl.saveDocument(savedDoc);
fl.closeDocument(savedDoc);
// INSTANCE NAME HAS NOT CHANGED!!!
Is there a workaround? …or have I missed something?