Skip navigation
Brian.T.Tanner
Currently Being Moderated

[JS CS5.5] Complex Application, want context that current script was called from

Apr 19, 2012 8:32 AM

I'm trying to create a slightly sophisticated application that is spread across several script files.  Some functions in these files call either other.  Here is what I want to emulate:

 

A.jsx

--------

if(mainScript=="A.jsx"){

doA();

}

 

function A(){}

 

B.jsx

---------

#include A.jsx

 

if(mainScript=="B.jsx"){

doB();

}

 

function B(){

// some stuff

A();

//some more stuff

}

 

C.jsx

#include A.jsx

#include B.jsx

#include D.jsx

main(){

D();

A();

etc...

}

 

 

Basically, I want a script to act differently depending on if it is the one being called or if it is being called from elsewhere. I thought I could do this pretty easily by using global variables and something like:

if(mainScript==undefined){

var mainScript=$.fileName;

}

 

But global variables persist between script calls so this doesn't work. I'm a bit stuck.  Anyone know how to do this?  app.activeScript doesn't work because I am executing through the extendScript toolkit. 

 

I'm vexed.

 
Replies
  • Currently Being Moderated
    Apr 19, 2012 8:41 AM   in reply to Brian.T.Tanner

    There's method outlined in the Scripting Guide to get the current script while running in the ESTK, using error handling:

     

    function myGetScriptPath() {
      try {
        return app.activeScript;
      }
      catch(myError) {
        return File(myError.fileName);
      }
    }
    

     

    Jeff

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 19, 2012 10:39 AM   in reply to Brian.T.Tanner

    I'm sorry—I shouldn't have chimed in without really trying to understand what you're doing. (I still haven't, honestly—sorry, no time.) I think includes are treated as if you copy/pasted them at the #include line in the including file. I don't think you'll have any information about context other than the script file name. Maybe  pass the first script name as an argument and then pass it along to every subsequently called function, comparing it to the active script name in each one?

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 19, 2012 11:06 AM   in reply to Brian.T.Tanner

    Brian, this is just not a good pattern to use.

     

    The answer is easy: don't do it this way. Design .jsxinc files to be included by .jsx files, don't include .jsx files inside other .jsx files. Make each file either a file that is included, or one that performs inclusion, but not both.

     

    This makes the code easy to read and meets most requirements. What are you trying to accomplish that does not fit that paradigm?

     

    Even if you could find a way to make what you wanted work, it would be hard and confusing to read, and tough for others to maintain.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 19, 2012 11:24 AM   in reply to Brian.T.Tanner

    Yeah, I think it just not a pattern that works well in Javascript. (I appreciate what you mean about Java).

    I suppose I would try a testA() function the A.jsx file, etc., and adjust the main program to call testA() instead of doA().

    Or if you have A.jsx, B.jsx, C.jsx, and main.jsx, instead of modifying main.jsx (undesirable) or creating seperate testA.jsx, testB.jsx, and testC.jsx, just add a test.jsx that includes A, B, and C and then calls testA(), etc. That way you don't double the number of files, you just add one (scales better).

     

    Is there any different between a jsx and jsxinc file or is that just a common naming convention that you or a community of people use to differentiate files?

    It is Adobe's naming convention for ExtendScript, and of course its optional. But naming a file .jsxinc does help to encourage the belief that you ought not try to execute it directly...

     

     

    At the risk of actually being helpful, I'm puzzled why your global variables are persisting, unless you are running in a persistent scripting engine...

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 19, 2012 12:01 PM   in reply to Brian.T.Tanner

    #targetengine "session"

    #strict on

    Yes, these cause your script to run in a persistent engine called "session" which means global variables will persist (so you need to be a *lot* more careful with them), and also windows and hooks and eventListeners can persist after the script execution appears to complete.

     

    If you do not require these things, then removing the targetengine line may be a good idea.

    But on the other hand, the discipline you get from persistent global vars should be good for you. But probably not good enough to outweigh the problems you're going to have...

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points