Creating maintainable code with ExtendScript

As I couldn't find a good, modern unit tester I ported the latest version of jasmine across to ExtendScript:

https://github.com/tmaslen/jasminejsx

Thanks for your feedback guys.

/t

Hi Tom,

This is something I did struggle with for many years (especially the compatibility control from going from one DOM version to another when my software updates).

My solution after a lot of trial and error was to use a custom library and try to keep each function as single responsibility (this also helps me make sweeping changes to all my code without breaking anything). By doing this I can wrap my function into a particular DOM version if the function is no longer supported after an InDesign update.

For example:

function BE_pageItemDelete(pageItemLabel) {
    // Initiate version control
    var currentDomVersion = app.scriptPreferences.version;
    var neededDomVersion = "6.0"; // This is the version number that is needed to run the encapsulated code
    if (neededDomVersion !== app.scriptPreferences.version) {
        currentDomVersion = app.scriptPreferences.version;
        BE_domVersion(neededDomVersion);
        }
  
    // Function script
    app.activeDocument.pageItems.item(pageItemLabel).remove();
  
    // Reverse version control
    if (currentDomVersion !== neededDomVersion) {
        BE_domVersion(currentDomVersion);
        }
    }
function BE_domVersion(version) {
    app.scriptPreferences.version = version;
    }

Because DOM version > 6.0 doesn't support script labeling I need to force the DOM to 6.0 and reset it back to the original DOM version after the function runs. I don't know if this is a good or elegant method in the real world but it works for my workflow processes.

Brett

Hi Tom.

Welcome to the "wonderful" world of ExtendScript.

First thing you should be aware is that ExtendScript is based on ECMAScript version 3... that is the same one used by Internet Explorer 5 ?!?!
It is ancient. That should answer your second set of questions:

* new features and when they will be released: Most likely NEVER

* how compatibility is maintained: by not releasing new features

Most scripting projects are relatively small, developed with a single task in mind, and by just one developer. So unit testing is not really needed for that. If you do think you need it, you can try hacking around jsUnit. I recommend it instead of Jasmine because it is much older thus more easily ported to extendScript.

Structure/order code... use your best judgement. Most scripters come from a DTP/design background, not programming. So there isn't any real standard or best practices. Also, remember that ExtendScript is not very CommonJS friendly so you will have to adapt quite a bit.