2 Replies Latest reply on Oct 11, 2006 11:27 PM by (Mark_Ulrik)

    Basic question

      Hi all,

      I'm new to this and would appreciate some input from you guys.

      I'd be very interested in your opinion on (broadly speaking) the most basic way for an application to interact with (UI free) plug-in code. According to the SDK documentation, the way to go about it seems to be:


      ...where "Script manager" is a plug-in with a SOAP interface (named RunScript) dependent on the syntax defined in the WSDL file that comes with the SDK. "SOAP client" corresponds to the "Test client" command line application also supplied with the SDK. Necessary tasks would include:

      1) exposing the "WT" plug-in functionality to the Scripting DOM,
      2) reworking the "Test client" to fit the application,
      3) writing the script(s), and
      4) figuring out how to make them return a meaningful response to the application. The SOAP syntax includes a response field, but the scripts don't know that.

      A simpler (undocumented?) approach would seem to be:


      ...where "WT manager" is a modified "Script manager" (without the scripting support) using a customized SOAP syntax. It would be extremely convenient to be able to access "WT" classes directly. Unfortunately, I haven't been able to find appropriate sample code and/or documentation.

      Any thoughts? Can scripting be avoided, or are my concerns (re: response mechanism) groundless?

      Many thanks in advance!

        • 1. Re: Basic question
          Hi Mark,

          Two things. :)

          First, you can indeed send a response from the script back to the client. A simple case would be a string as the last statement in the script.jsx (If you have the server, then you got a set a sample scripts with it... try opening up 'HelloWorld.jsx' and adding a single line to the end:

          "Hello Client!"

          You'll see it returned from the test client. Of course the return type doesn't have to be a string, it can be a number, or a collection, or any of the types called out in the WSDL file -- the string is just the easiest to try.

          Second, providing your own SOAP server in the application seems like it would work, but I don't think Adobe has any samples around that, so you'd have to figure out how to build the SOAP server inside a plug-in yourself. Alternatively the SOAP server can sit outside the InDesign application. Then you'd have a couple of choices in communicating with InDesign Server... you could build WTManager still and it would talk to the external SOAP server through some other mechanism (shared memory, a socket, whatever) or, the SOAP server could then use OSA/COM to drive the server. The advantages there is that your SOAP server could provide a job queue and could drive multiple instances of InDesign.


          • 2. Re: Basic question
            Level 1
            Hi Paul,

            I'm very grateful for your helpful reply. Particularly for putting to rest my worries about obtaining return values from scripts. I sort of assumed the "result" fields was just for the script interpreter to be able to report syntax and/or execution errors. Guess I need to learn to read code & docs more carefully :)

            I'm sympathetic to the idea of an external SOAP server component, but am not sure how to set up my "WT manager" to be receptive to requests from the outside.

            In any case, time is precious, so the scripting strategy seems much more appealing at this point. Thanks again!