My Way

February 16th, 2009

When I start an InDesign or Bridge Scripting project, I always use an “application template” that I have created. The templates are slightly different for Bridge and InDesign because of the way the host application loads scripts. There are a zillion ways to skin a cat (non acceptable to the cat); however, over time, I have found “my way” to be the easiest to manage.

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.

Entry Filed under: Scripting Tips

Leave a Comment

You must be logged in to post a comment.

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendar

February 2009
S M T W T F S
« Jan   Mar »
1234567
891011121314
15161718192021
22232425262728