When I create scripted extensions, I always break things up into files that make things manageable. A large project for me might contain 200 script files. Rather than try to stuff it all into a single script for delivery, I came up with a template that I use for just about all my InDesign scripting projects that makes this about as easy as it can be. This concept really only applies when a script will reside in a persistent (named) scripting engine and adds menus to the InDesign menu bar and/or context menu.

I have made the template available in the Free Stuff page of this site, so go ahead and download it.

When you unzip it, it creates a folder. Inside that folder is “startup scripts” that contains one jsx, “loader.jsx”. That file loads the entire extension. It recursively looks through all the folders and loads the entire project into the named scripting engine for you.

There’s a “resources” folder. It contains things, like images, that are not jsx files. The loader script does not load anything in the resources folder. As another freebie, I put some ESTK extensions in this folder. There’s a PDF that describes how to install and use them. One of those extensions does a batch conversion to jsxbin. It places all of the scripts into a “bin” folder except those in the “startup scripts” and “jsx” folder. The loader script that creates the names engine can not be a jsxbin. Files in the jsx folder are those script files which should not be converted to jsxbin (basically any class definition that might be serialized and deserialized using toSource()).

When you convert a project to binary for delivery, the loader script contains a flag, “loadBinary”. If you set that flag to “true”, it will load the binary files. You then remove the jsx’s to hide your source code, and yer’ done.

Just to be clear – use the tempate (it has examples of menu creation, context menu creation, and some handy libraries), complete and test the project, convert it to binary (one step), remove the jsx files (other than those in the jsx folder), set the loader’s loadBinary to “true”, and you are ready to ship projects that are arbitrarily huge.

Enjoy!

I’ve uploaded a Flex project that received APID (http://www.rorohiko.com) events in PatchPanel.

If you’re interested, take a look at the free stuff page.

I’ve added a Flex project to the free stuff page. This was in response to a posting on the Patchpanel forums (Adobe Labs). The poster wanted to react to InDesign events in ActionScript. This Flex project shows you how to do it (and yes, it’s in a persistent scripting engine that is launched by InDesign at startup.

When I started writing the Workflow Automation Scripts for CS2, I was pretty much just stuffing whatever I needed into a single script file. While it worked, I was constantly scrolling up and down through very large files.

My next approach was to separate the script into smaller files, using include directives to load the files. While this works, debugger support suffers. With includes, the debugger doesn’t have a link to the file, so the debugging information is incomplete for included files.

Being an old Java coder (and C++, and C, and Pascal, and assembly, and machine….), I kinda like projects organized. Most of my code is object oriented, so there are a lot of classes that are better off in their own files.

Then in CS3, Adobe gave us jsxbin files, which finally allowed us to protect our intellectual property by encoding the script files. That added further complexity for InDesign coders as the #target and #targetengine directives do not work inside jsxbin files.

I finally hit on this approach.

For InDesign, I create a project folder inside the InDesign scripts folder ( Adobe InDesign CS3/Scripts – or CS4). Inside that folder I create another folder called “Startup Scripts”. On start-up InDesign loads all scripts inside any folder under its Scripts folder named “Startup Scripts”.

In my project startup scripts folder, I place a single script called “loader.jsx”. Loader.jsx is a standard script, it requires code changes.

In the root project folder, I place a script called “main.jsx” which contains constants, project build information, namespace objects and the like.

This is the minimal project template:

My Project
   main.jsx
    Startup Scripts
      loader.jsx

The way the loader script works is to start at the root project folder and do a hierarchical search for all jsx files (ignoring the Startup Scripts folder). It then loads each of those files using the $.evalFile() statement. That means no matter what I write and where I put them, project jsx files will all be loaded by a single standard loader script without my having to think about it. The loader script contains a flag variable, loadBinary. If set to true, it will load jsxbins, not jsx’s.

So as you work, you just add folders and script files as you go.

My Project
   main.jsx
   menus
      menuMaker.jsx
   Startup Scripts
      loader.jsx
   util
      util.jsx
   ui
      uiclass1.jsx
      uiclass2.jsx

Then I wrote an extension to the ESTK that batch encodes the entire project into jsxbin files for me. Select the menu, select the folder, and go. It places all of the jsxbin files in a “bin” folder as a child of the root project folder.

The folder structure after conversion to jsxbin:

My Project
   bin
   main.jsxbin
   menus
      menuMaker.jsxbin
   util
      util.jsxbin
   ui
      uiclass1.jsxbin
      uiclass2.jsxbin
   main.jsx
   menus
      menuMaker.jsx
   Startup Scripts
      loader.jsx
   util
      util.jsx
   ui
      uiclass1.jsx
      uiclass2.jsx

One issue with jsxbin files that affects object oriented coders is that classes that are defined in jsxbin files can not be serialized and recreated using toSource()/eval(). This means that in any project, there could be files that must stay as jsx files. The jsxbin conversion extension ignores any script file contained in a folder named “jsx”, and the script loader will always load scripts in any “jsx” folder as jsx even with the loadBinary variable set to true.

To develop code, I get all of flexibility I want and need, full debugger information, and the ability to reload a project with one click (run the loader under the estk). To ship, all I have to do is run my batch binary converter, set the loader’s loadBinary = true, move the jsx files out of the project folder, archive the folder. When I move the jsx files back, I’m ready to start work on the next build.

I’ll be posting the ESTK extensions and some samples over the next couple of weeks.