Transcript
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc Developing Solutions for InDesign Server CS2
Adobe Developer Technologies October 2004 Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
1
Welcome to the “Developing Solutions for InDesign Server CS2” session. --Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved. The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. The software described in this document is furnished under license and may only be used or copied in accordance with the terms of such license. Adobe, Adobe InCopy, and Adobe InDesign are trademarks of Adobe Systems Incorporated that may be registered in certain jurisdictions. Macintosh and Apple are registered trademarks, and Mac OS is a trademark of Apple Computer, Inc. Microsoft, Windows, Windows 95, Windows 98, Windows NT and Windows XP are registered trademarks of Microsoft Corporation. All other products or name brands are trademarks of their respective holders.
Introduction to InDesign/InCopy CS2 Plug-in Development
1
Session 3: Developing Solutions for InDesign Server CS2
Goals of the training session
October 2004
bc
To introduce InDesign Server CS2 To understand how to develop solutions for InDesign Server CS2
Satisfying the minimal requirements Adapting your existing “desktop” InDesign plug-ins for InDesign Server Developing clients Testing techniques
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
2
The goals of this training session are: •To introduce InDesign Server CS2, a new server-based version of InDesign. •To provide a high-level understanding of the ways you as a developer can develop solutions for InDesign Server CS2. This includes plug-ins, scripts, and the use of SOAP commands. •To provide some insights for adapting your existing InDesign CS2 (“desktop” InDesign) for InDesign Server CS2.
Introduction to InDesign/InCopy CS2 Plug-in Development
2
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc Introduction to InDesign Server CS2
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
Introduction to InDesign/InCopy CS2 Plug-in Development
3
3
Session 3: Developing Solutions for InDesign Server CS2
Overview of InDesign Server CS2
October 2004
bc
More than just a “faceless” InDesign
Based on desktop InDesign engine, optimized for server usage Technology platform for building design-driven server-based publishing solutions
Driven by scripts, SOAP commands, plug-ins Targeted for SIs and ISVs
Feature matrix is mostly identical except in a few areas
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
4
In fundamental terms, InDesign Server CS2 is the desktop version of InDesign (“desktop InDesign”, herein) without a user interface. Instead of a window-based application with a menu that has items like File >> New, and panels/dock bars to change properties such as character/paragraph attributes, the application is a command-line applications that has been fine-tuned for performance. In some ways, InDesign Server is more than just a “faceless” InDesign, as it has these features not present in desktop InDesign: •The ability to drive the application by SOAP commands •Support for running multiple application instances •Various performance tuned settings (e.g. undo turned off by default) •Various scripting library additions (output to consoleout/err, debug-only script objects) And in other ways, due to its faceless nature, some desktop InDesign features are not available in InDesign Server: •Clipboard operations: The copy/cut/paste operations depends on layout views, however, you can use the data exchange handler APIs (import/export providers, drag and drop, etc.) as a workaround. •Library assets: The new snippet based library is supported, but the old style libraries are not supported. The old style used the scrap which requires a view. •Spelling: The Spelling feature is currently tied to the Spell panel. •Checking in/out InCopy stories: The bridge plug-in has not been ported for use in InDesign Server. •Version Cue As InDesign Server does not have a UI, you drive the application in a different way than the way most endusers drive desktop InDesign. •By scripts: AppleScript, JavaScript, VBScript and COM clients •By SOAP commands: New in InDesign Server •By plug-ins: Plug-in developer are most familiar with this. Primarily due to these requirements, InDesign Server CS2 will be positioned as a technology platform for building design-driven server based publishing solutions. The primary users will be SIs and ISVs, which no doubt include the many plug-in developers who are watching/reading this presentation. InDesign Server CS2 officially supports these OS platforms: •Win 2000 Server and Win 2003 Server •Mac OSX Server 10.3.x
Introduction to InDesign/InCopy CS2 Plug-in Development
4
Session 3: Developing Solutions for InDesign Server CS2
October 2004
Driving InDesign Server by scripts Traditional methods Local or remote AppleScripts and COM clients Trusted clients Extra: Drop a document into the watch folder for automatic processing Automatically runs a JavaScript
bc
InDesign Server CS2 Script ScriptMgr Mgr AppleEvents, COM
Scripts Scripts (The client)
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
5
As mentioned in the previous slide, one of the ways to drive InDesign Server is by using a script. This is something with which many InDesign users are already familiar. An extra feature (not provided in the default configuration) is the ability to drop a document into a watch folder and have it be processed using a JavaScript.
Introduction to InDesign/InCopy CS2 Plug-in Development
5
Session 3: Developing Solutions for InDesign Server CS2
October 2004
Driving InDesign Server by SOAP commands Send scripts via SOAP to InDesign Server at a specific TCP/IP address and port Allows for a flexible system architecture, but consider security issues
bc
InDesign Server CS2 Script Script Mgr Mgr
SOAP SOAP Server Server
SOAP
TCP/IP SOAP
SOAP SOAPClient Client Scripts Scripts
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
6
Another way to drive InDesign Server is to have a SOAP client application send the server some SOAP commands. SOAP stands for ”Simple Object Access Protocol”, and is an XML-based remote procedure call protocol maintained by W3C. SOAP messages are sent over TCP/IP (more precisely, HTTP), so you will need to configure InDesign Server CS2 to communication on a particular TCP/IP port on the server machine. Opening a TCP/IP port on the server machine requires some thought in how you configure your network settings, including firewall setup. You may also want to consider security issues.
Introduction to InDesign/InCopy CS2 Plug-in Development
6
Session 3: Developing Solutions for InDesign Server CS2
Driving InDesign Server by plug-ins
October 2004
bc
Add plug-ins into InDesign Server just like desktop InDesign You can add your own communication protocol for driving the application
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
7
The third way to drive InDesign Server is by developing a plug-in. As a plug-in developer, you are already familiar with how to do this. There is nothing different about the process of developing a plug-in for InDesign Server, as opposed to desktop InDesign. If you already have a communication protocol to drive the desktop InDesign application via your plug-ins, chances are, you can reuse them in InDesign Server. If you don’t have a communication protocol already in place, then you can either add a scripting provider (which will be discussed later), or add your own.
Introduction to InDesign/InCopy CS2 Plug-in Development
7
Session 3: Developing Solutions for InDesign Server CS2
Running InDesign Server CS2
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
October 2004
bc
8
This slide shows a screen shot of what you see when you run InDesign Server from a console window (Windows: Command Prompt; Macintosh: Terminal window). Notice that the text you normally see flash by on the “splash screen” from desktop InDesign are written out to the console window. The output to the console window is identical between the Macintosh and Windows platforms, however, the debug build may print out extra messages under certain circumstances that the release build will not. For details on now to run InDesign Server CS2, you can refer to the Adobe InDesign Server CS2 Installation and Configuration Guide.
Introduction to InDesign/InCopy CS2 Plug-in Development
8
Session 3: Developing Solutions for InDesign Server CS2
Overview: What you can do with InDesign Server (that you already know)
October 2004
bc
Use the C++ API to develop plug-ins
API is essentially the same as desktop InDesign Runtime object model has a just few differences
Unified C++ API = Binary compatibility between:
Desktop InDesign (all locales) InDesign Server InCopy (all locales)
Implement script providers to add functionality
And write scripts to drive your plug-ins
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
9
As an experienced InDesign and InCopy plug-in developer, you already know many aspects of what you need to know in order to develop solutions for InDesign Server: •You develop plug-ins using the InDesign C++ API. The API is essentially the same as desktop InDesign. There are a few interfaces whose run-time implementations only exist in InDesign Server, thus resulting in a slightly different object model footprint. However, at compile time, there is no difference in the API. •If your plug-in code is factored just right, you can reuse your plug-ins under all three products in the InDesign product family. •The efforts you have invested in developing a script provider for your plug-ins will pay off, since one of the ways to drive InDesign Server (discussed on a previous slide) is by running a script.
Introduction to InDesign/InCopy CS2 Plug-in Development
9
Session 3: Developing Solutions for InDesign Server CS2
Overview: What you can do with InDesign Server (that you didn’t know)
October 2004
bc
Run multiple instances of the application
This presents higher performance possibilities for publishing solutions
Display messages on the server console
CAlert, IErrorList, ASSERT display messages on the console Trace outputs to selected sink You can also output messages directly to standard out and standard error
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
10
…And here are a few things provided uniquely by InDesign Server that you as a plug-in developer would possibly welcome: •InDesign Server supports multiple instances on the same machine. You can enable SOAP command support for each instance by running each instance on different TCP/IP ports. If you have a multiprocessor machine, each instance could potentially run on different processors, providing even higher performance than previously known to InDesign users. •You can display messages on the server console. •Existing APIs like CAlert and ASSERT work without modifications from client code – they display messages on the console window. Also, these APIs are not modal like they are in desktop InDesign. (Modal dialogs are disruptive to the server application, so these APIs have been refactored for InDesign Server.) •Trace/TraceFlow statements output to selected trace sinks, such as MSVC’s output window, Notepad, the console window, or DebugWindow (Mac). •IErrorList, a new API in InDesign Server, allows you to queue up a list of errors which then would be available from a script. IErrorList is commonly used in places where you display a warning dialog in desktop InDesign (e.g. missing font dialog). •You can also use std::cout and std::cerr to display messages directly to the console window.
Introduction to InDesign/InCopy CS2 Plug-in Development
10
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc How to Develop Plug-ins for InDesign Server CS2
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
11
Now that we have established what InDesign Server is about at an overview level, let’s discuss how to develop plug-ins for InDesign Server.
Introduction to InDesign/InCopy CS2 Plug-in Development
11
Session 3: Developing Solutions for InDesign Server CS2
How to get your plug-in to load
October 2004
bc
PluginVersion resource (*.fr) resource PluginVersion (kSDKDefPluginVersionResourceID) { kTargetVersion, k***PluginID, kSDKDefPlugInMajorVersionNumber, kSDKDefPlugInMinorVersionNumber, kSDKDefHostMajorVersionNumber, kSDKDefHostMinorVersionNumber, kSDKDefPersistMajorVersionNumber, kSDKDefPersistMinorVersionNumber, {kInDesignProduct,kInDesignServerProduct,InCopyProduct}, {kWildFS}, k***Version };
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
12
One of the first things you must do to you plug-in is to designate it as a plug-in that can be loaded under InDesign Server. You can specify this in the PluginVersion resource in your .fr file. This ProductIds field is a new addition to the InDesign/InCopy CS2 API. The example on the slide shows that this plug-in is designed to load under desktop InDesign, InDesign Server, and InCopy. These IDs are defined in {SDK}/source/public/interfaces/architecture/ShuksanID.h in a new ID space called kProductIDSpace.
Introduction to InDesign/InCopy CS2 Plug-in Development
12
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc How to get your plug-in to load (contd.)
Must refactor model and UI into separate plug-ins
Only the model plug-ins should be loaded in InDesign Server UI components will not load in InDesign Server
InDesign Server does not load WidgetBin Commonly used UI components are listed in the InDesign Server Plug-in Techniques tech note
See later slides on model/UI separation techniques
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
13
Recall from an earlier slide that InDesign Server does not have a user interface like desktop InDesign. Therefore, if your plug-in has user interface components like menus/actions, panels, dialogs, etc., you must factor them out of the plug-in that you want to load in InDesign Server. If you try to load plug-ins that have UIrelated components, you will get ASSERTs in the debug build. Optionally, you can mark your newly refactored UI-only plug-in for loading only under desktop InDesign (kInDesignProduct) or InCopy (kInCopyProduct). For more details, see the section “Detecting plug-ins that mix model and view components” in the InDesign Server Plug-in Techniques tech note.
Introduction to InDesign/InCopy CS2 Plug-in Development
13
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc How to verify that your plug-in is loaded
In the Debug build
Examine QA/Logs/configuration_NNNNN/ PluginLoadLog.txt
After starting InDesign Server with your plug-in, and shutting down
Use the InDesignServer.Application. QATest script event to get a list of plug-ins loaded at run-time
See later slide on Testing
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
14
Once you do the minimal work of setting up your PluginVersion resource and factoring out the UI components, you can determine if your plug-in is actually loaded in one of two ways in the debug build of InDesign Server: 1. By examining a QA log file (see path on slide). The QA folder is at the same level as your InDesign Server application folder. 2. By writing a script that uses the InDesignServer.Application.QATest script event. See later slide on Testing for details on how to do this. In the release build, there is currently no external way to verify that your plug-in is loaded besides looking at the scripting library (if your plug-in does have one).
Introduction to InDesign/InCopy CS2 Plug-in Development
14
Session 3: Developing Solutions for InDesign Server CS2
How to determine if your plug-in is running in InDesign Server
October 2004
bc
Call LocaleSetting::GetLocale(). GetProductFS()
kInCopyProductFS kInDesignProductFS kInDesignServerProductFS Or call LocaleSetting::GetLocale(). IsProductFS(kInDesignServerProductFS)
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
15
An earlier slide mentioned that plug-ins for InDesign Server are binary-compatible with desktop InDesign and InCopy as well. That may require you to add code to determine under which application your plug-in is running. This slides shows you a few ways to add run-time product checking to your plug-in code. See the following SDK header files for details: •{SDK}/source/public/includes/LocaleSetting.h, {SDK}/source/public/includes/MocaleSetting.h, {SDK}/source/public/includes/WocaleSetting.h •{SDK}/source/public/includes/PMLocaleTypes.h •{SDK}/source/public/includes/FeatureSets.h
Introduction to InDesign/InCopy CS2 Plug-in Development
15
Session 3: Developing Solutions for InDesign Server CS2
How to determine if your plug-in has UI components
October 2004
bc
Using InDesignServer.Application properties (debug build only)
pluginswithui modelpluginswithui uipluginswithmodel
Examining your project to see what it links with
Mac: InDesignModelAndUI.framework Win: WidgetBin.lib
Windows only: DUMPBIN or Dependency Walker Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
16
An earlier slide mentioned that you need to refactor your plug-ins so that UI components are not part of the plug-ins that load in InDesign Server. This slide shows you different ways to detect if your plug-in may have UI components. 1. By writing a script that uses debug-only properties of the InDesignServer.Application object. 2. By examining what your plug-in project links with. If you can modify your project’s linker settings so that they do not link with WidgetBin (on the Mac, that means you change InDesignModelAndUI.framework to InDesignModel.framework) and still build your plug-in without linker errors, you are most likely safe. 3. (Windows only) By using tools such as DUMPBIN or Dependency Walker to see if your plug-in imports any symbols from WidgetBin.dll. Details are mentioned in the section “Detecting plug-ins that mix model and view components” in the InDesign Server Plug-in Techniques tech note.
Introduction to InDesign/InCopy CS2 Plug-in Development
16
Session 3: Developing Solutions for InDesign Server CS2
October 2004
How to refactor model and UI components into separate plug-ins Model components Core model data Selection suites Observers that observe model changes Service providers that participate in model changes Most commands Other code (facades or helper classes) that do not make UI calls Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
bc
UI components View components
Action components, dialogs, dock bar, kits, panels, rulers
Observers that update widgets Service providers that participate in UI changes Commands that present a dialog
17
So what exactly are UI components, and what are non-UI (or model) components? This slide lists components (think interface implementations aggregated in boss classes) that are commonly considered model components and UI components. If you have boss classes that aggregate a mixture of model and UI interface implementations, you must do some work to split them into separate boss classes.
Introduction to InDesign/InCopy CS2 Plug-in Development
17
Session 3: Developing Solutions for InDesign Server CS2
How to refactor model and UI components into separate plug-ins (contd.)
October 2004
bc
Keep model components in the same plug-in
So you don’t have to write tons of data converters
Moving model components from a UI plug-in to a model plug-in will require a data converter ActionIDs will be re-based in this process
Beware if you ship shortcut key setting files
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
18
Once you have identified which of your components are indeed model or UI, it’s time to refactor your plug-in. Model components should stay in the same plug-in (with the same plug-in ID prefix), especially if your model components are persistent interface implementations. That way, you can save yourself the extra work of writing data converters. See the section “Separating your model and view components into separate plug-ins” in the InDesign Server Plug-in Techniques tech note. In some cases, you may have to move model components from UI plug-in to a model plug-in. That will require you to implement a data converter. Such cases are described in detail in the section of the InDesign Server Plug-in Techniques tech note listed above. If you do move ActionIDs from one plug-in to another, and if the ActionIDs are used in shortcut files that you ship, please note that the values will change.
Introduction to InDesign/InCopy CS2 Plug-in Development
18
Session 3: Developing Solutions for InDesign Server CS2
How to refactor model and UI components into separate plug-ins (contd.)
October 2004
bc
Replace view-dependent API calls in model components
Modify calls to APIs that depend on a view component or something being in “front”
E.g. ILayoutUIUtils::GetFrontDocument() won’t work in InDesign Server
Replace warning dialogs (other than CAlert) with IErrorList::AddError
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
19
Even after refactoring the UI implementations into a separate plug-in, your work may not be complete. As was the case with may InDesign C++ APIs, the code that you may consider model code may require view-related APIs (such as ILayoutControlData) for them to work properly. In InDesign Server, you don’t have a layout window, so there is no layout view to speak of. Also, there is no concept of a document window being in “front” of another one, so some commonly use APIs like ILayoutUIUtils::GetFrontDocument will not work under InDesign Server. See the section “Removing calls to APIs that depend on an active context or something that is in ‘front’” in the InDesign Server Plug-in Techniques tech note. You may also have code (other than CAlert methods) that open a dialog to show the user a warning or error message. Such code will have to be replaced by IErrorList::AddError, so that the warning/error message can be made accessible from a script via the IErrorList interface. See the section “Using IErrorList in place of custom error/warning dialogs (other than CAlert)” in the InDesign Server Plugin Techniques tech note.
Introduction to InDesign/InCopy CS2 Plug-in Development
19
Session 3: Developing Solutions for InDesign Server CS2
How to expose your plug-in’s functionality in InDesign Server
October 2004
bc
Implement a script provider
Use VersionedScriptElementInfo in place of ScriptElementInfo
For details, see tech note Making Your InDesign Plugin Scriptable
Side benefit: INX file support You should become comfortable with scripting
Refer to Adobe InDesign CS Scripting Guide
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
20
After refactoring your plug-ins across model-only and UI-only components, you can implement a script provider (if you haven’t done so already) so that your plug-ins features can be accessed from a script. Details on how to add a script provider to your plug-in can be found in the Making Your InDesign Plug-in Scriptable tech note. The ScriptElementInfo resource that was introduced in InDesign CS should be changed to a VersionedScriptElementInfo resource, which supports the notion of a product-based script provider. That is, you can specify different script objects/events/properties/enums/suites for different products. Implementing a scripting provider for your plug-in is strongly recommended, especially if your plug-in adds persistent objects or preference settings to the document structure. . Once of the side benefits of implementing a scripting provider that you get almost-automatic support for the InDesign Interchange (.inx) file format and its derivatives, which use the 4-letter ScriptID as the name of an XML element. What this all means to the plug-in developer: You should become comfortable with writing scripts for InDesign Server, as you will most likely need to do it in many instances. Knowing how to develop script-based solutions for the InDesign family of product also gives you an additional tool in your developer tool box. Refer to the Adobe InDesign CS2 Scripting Guide for details on general InDesign scripting. Introduction to InDesign/InCopy CS2 Plug-in Development
20
Session 3: Developing Solutions for InDesign Server CS2
Other useful plug-in techniques
October 2004
bc
Writing messages to the console window
std::cout/cerr See section “Writing messages to standard output” in tech note InDesign Server Plug-in Techniques
Performance considerations
Tips to make your automated workflow work even faster See section “Performance considerations” in tech note InDesign Server Plug-in Techniques
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
21
There are a few other things you can do to make your plug-in even better. One aspect is the ease in which you can debug your plug-in. Some developers like to see statements written out to some output window to track the progress of code. This can be more efficient than using a symbolic debugger, in certain instances. You can use the std::cout and cerr singleton classes to output messages to the console window. You can also use the ASSERT macros (which also output to the console window) and the Trace macros (which output to the selected trace sink), if your code already uses those APIs. One of the benefits of using InDesign Server is that the application has been enhanced for performance. Your plug-ins should also be enhanced for performance. There are several tips mentioned in the InDesign Server Plug-in Techniques tech note.
Introduction to InDesign/InCopy CS2 Plug-in Development
21
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc How to Develop Clients for InDesign Server CS2
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
22
So far, we have discussed special plug-in development considerations that you must keep in mind when developing a plug-in for InDesign Server. Now, let’s discuss how to develop clients for InDesign Server, provided you do not have one yet.
Introduction to InDesign/InCopy CS2 Plug-in Development
22
Session 3: Developing Solutions for InDesign Server CS2
Using scripts
October 2004
bc
Traditional scripting methods
Run scripts from the same machine Automate InDesign Server remotely
COM, Apple Scripts
To verify resulting document, open with desktop InDesign or export to PDF
Extra feature
Drop a document into the watch folder to auto-run a JavaScript
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
23
One general way for a client to drive InDesign Server is by using scripts. You can run scripts in the same way you run scripts for desktop InDesign. •Run a script (AppleScript or COM clients) from the same machine as InDesign Server. This is exactly the same as scripting with desktop InDesign, with one exception – the InDesign object is called “InDesignServer” (COM) or “InDesign Server CS2” (AppleScript) instead of just “InDesign” (COM) or “InDesign CS2” (AppleScript). •Run a script (AppleScript or COM clients) from a different machine than the one running InDesign Server. (When running a script remotely, there may be some further configuration steps involved.) •In Visual Basic, the CreateObject function has an optional 2nd parameter where you can specify the address of a machine serving a COM object. (see http://msdn.microsoft.com/library/default.asp?url=/library/enus/vblr7/html/vafctCreateObject.asp) •In AppleScript, the line where you way ‘tell application “InDesign Server CS2”’ can take some optional arguments that specify the machine that is running the application. (See http://developer.apple.com/documentation/AppleScript/Conceptual/AppleScriptLangG uide/AppleScript.93.html) As an extra feature (that is not included in the default configuration of InDesign Server CS2), you can also drop a document into a watch folder for InDesign Server to process. This is very similar to the watch folder feature in Acrobat Distiller. When a file (or a folder of files) is dropped into a designated watch folder, InDesign Server automatically runs a JavaScript at a predetermined file path (scripts/InDesign Server scripts/default drop script.js) and processes each file against that JavaScript.
Introduction to InDesign/InCopy CS2 Plug-in Development
23
Session 3: Developing Solutions for InDesign Server CS2
Using SOAP Commands
October 2004
bc
1. Obtain IDSP.wsdl
{SDK}/source/components/soapserver/g soap WSDL = Web Services Definition Language
Generate stub code from IDSP.wsdl
Microsoft Visual Studio .NET: wsdl.exe Mac OS X Developer CD: WSMakeStubs gSOAP: wsdl2h.exe, soap2cpp.exe Others available for Java, Perl, etc.
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
24
Another way to drive InDesign Server is to send it SOAP commands. To help with SOAP client development, the SDK includes the IDSP.wsdl file. This file declares the SOAP commands and types supported by InDesign Server. WSDL stands for “Web Services Definition Language”, an interface definition language (IDL) of sorts for SOAP. Using this WSDL file, you can generate stub code for the SOAP commands in the language of your choice. You can choose from a wide variety of tools and platforms. •Microsoft Visual Studio .NET: wsdl.exe (All VS.NET languages: C++, C#, Visual Basic.NET) •Mac OS X Developer CD: WSMakeStubs (AppleScript, C++, ObjetiveC) •gSOAP: wsdl2h.exe, soap2cpp.exe (C++). The gSOAP generated stubs are shipped with the SDK, so you can simply reuse them if you are going to develop a SOAP client in C++. Refer to the documentation for each tool.
Introduction to InDesign/InCopy CS2 Plug-in Development
24
Session 3: Developing Solutions for InDesign Server CS2
Using SOAP commands (contd.)
October 2004
bc
3. Write a client application using the generated stub
The following 3 SOAP commands are supported:
(Mac) Rendezvous support
IDSP__OpenDocument IDSP__RunScript IDSP__Stop Service domain name: CFSTR("") Service type name: CFSTR("_indesign._tcp") Use with Core Foundation Network Services APIs
For more details
See tech note InDesign Server Test Client, Test Client projects
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
25
Among the 3 SOAP commands that are actually supported with InDesign Server, the most common command is IDSP__RunScript, which allows you to send a script (or specify a script on the server) that the server will process. To see a sample of how this is done, you can refer to the Test Client (SoapClient.mcp/vcproj) projects in the SDK. Both the InDesign Server and the Test Client were both written using stubs generated by gSOAP, an open source SOAP environment for use with C/C++ compilers. The tech note InDesign Server Test Client explains the code in detail. The tech note also contains a SOAP command reference. The Macintosh version of the Test Client project contains code to detect running instances of InDesign Server on the network. Refer to the Apple Developer Connection for more details on Core Foundation Network Services APIs.
Introduction to InDesign/InCopy CS2 Plug-in Development
25
Session 3: Developing Solutions for InDesign Server CS2
Sample: Test Client
October 2004
bc
A sample SOAP client application written with gSOAP to send JavaScripts to InDesign Server Necessary preparation
Install gSOAP runtime source files (gSOAP 2.4.1) Install boost regex libs source (boost 1.30.0) (Win) Build the boost regex libs using vc7.mak
Build SoapServer.mcp/vcproj projects in your IDE See InDesign Server Test Client tech note and {SDK}/ReadMe.txt for preparation and usage details Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
26
If you would like a working example of a SOAP client, look no further than the SDK, which contains the project and the source for the InDesign Server Test Client (Mac: testclient, Win: testclient.exe). The test client is a sample SOAP client application written using the gSOAP framework to send JavaScripts to InDesign Server. There are some steps you must complete before you can build the test client application with your existing IDEs. You need to: •Install gSOAP runtime source files (stdsoap2.cpp and stdsoap2.h) from the gSOAP 2.4.1 distribution. •Install boost regular expression library source files from the boost 1.30.0 distribution. •(Windows only) Build the boost regex libraries using vc7.mak. The preparation steps are listed in the InDesign Server Test Client tech note and the SDK ReadMe.txt file. Once you prepare these extra files, you are ready to build the SoapServer.mcp/vcproj projects in your IDE. The usage instructions are also described in the InDesign Server Test Client tech note.
Introduction to InDesign/InCopy CS2 Plug-in Development
26
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc How to Test Plug-ins for InDesign Server CS2
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
27
Your plug-ins are ready for use with InDesign Server, and you have some client code that you can use to drive InDesign Server. Now, let’s discuss how to test your plug-ins (and clients) for InDesign Server.
Introduction to InDesign/InCopy CS2 Plug-in Development
27
Session 3: Developing Solutions for InDesign Server CS2
Testing your plug-ins
October 2004
bc
Run your plug-ins through the debugger and debug build
NOTE: ASSERT macros behave a little differently
Then test with the release build Exercise your plug-in’s features with a script Client applications and scripts do not need to be a debug build
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
28
In general, you test your plug-in code under InDesign Server in the same way you do it for desktop InDesign – in the debug build, using your IDE’s debugger. This way, you will be able to see when asserts occur (on the console window). And your plug-ins should run free of assertion failures. Note that ASSERT macros still work under InDesign Server in that they display a message on an assertion failure, however, your code will not hit a break point. Also, the ASSERT macros only show the message, but not the file name nor the line on which the assertion failed. If you have added a script provider to your plug-in, you will need to run the script that exercises your plug-ins features. Once nice thing about testing client applications and scripts with InDesign Server is that the client application and scripts do not need to be a debug build to work with the debug build of InDesign Server. If you have your own communication protocol between your client application and your plug-ins, then it is still recommended that you follow the same general steps of running your plug-ins in the debug build.
Introduction to InDesign/InCopy CS2 Plug-in Development
28
Session 3: Developing Solutions for InDesign Server CS2
Testing your plug-ins (contd.)
October 2004
bc
Utilize debug-only script features
InDesignServer.Application.pluginswit hui, modelpluginswithui, and uipluginswithmodel properties InDesignServer.Application. QAScriptingObject property
QATest event TestIsRunning property
InDesignServer.Application.ServerTest event
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
29
In using the debug build of InDesign Server, you will find some additional script objects that will help you with testing your plug-ins. •The pluginswithui, modelpluginswithui, and uipluginswithmodel properties on the InDesignServer.Application object will help you detect if your plug-ins have any mixture of model and UI components. •The QAScriptingObject property on the InDesignServer.Application object gives you access to the QAScriptingObject object, which has the QATest event (with which you can set/get various configuration information, such as a list of loaded plug-ins, as well as the ability to execute QA Tests), and the TestIsRunning property (which tells you if a test is currently running). •The ServerTest event on the InDesignServer.Application object gives you the ability to do some simple memory management by establishing memory purge settings. For more information on the debug-only script features, see section “Scripting objects you can use for testing” in tech note InDesign Server Plug-in Techniques.
Introduction to InDesign/InCopy CS2 Plug-in Development
29
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc References
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
Introduction to InDesign/InCopy CS2 Plug-in Development
30
30
Session 3: Developing Solutions for InDesign Server CS2
References in the SDK
October 2004
bc
Tech notes ({SDK}/docs/guides)
InDesign Server Plug-in Techniques InDesign Server Test client Making Your InDesign Plug-in Scriptable
Sample plug-ins that…
…have a script provider
PrintSelection (not InDesign Server ready)
…are InDesign Server ready
Under consideration for a future SDK release
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
31
Here are a list of references in the SDK to learn out more about developing plugins and solutions for InDesign Server. The Making Your InDesign Plug-in Scriptable tech note is not yet available for the InDesign/InCopy CS2 release, however, it will be available in a future SDK release. In the mean time, you can still refer to the InDesign/InCopy CS SDK version of the tech note, as many of the details still apply.
Introduction to InDesign/InCopy CS2 Plug-in Development
31
Session 3: Developing Solutions for InDesign Server CS2
References on the product distribution
October 2004
bc
Documentation
InDesign Server CS2 Installation and Configuration Guide InDesign CS2 Scripting Guide
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
32
The documents shown on the slide, from the InDesign Server CS2 product distribution (CD-ROM) are good references to use when configuring InDesign Server and developing scripts.
Introduction to InDesign/InCopy CS2 Plug-in Development
32
Session 3: Developing Solutions for InDesign Server CS2
References on the web
October 2004
bc
SOAP and WSDL specifications on w3.org SOAP/WSDL Authoring and Testing Tools
Altova XMLSpy
SOAP APIs and stub code generator tools
Microsoft Developer Network Apple Developer Connection Java
Apache SOAP IBM Web Services (r)evolution Sun WebServices
Perl
Active State Web Services SOAPLite for Perl
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
33
You can find more information on SOAP and WSDL on the internet. W3C Specifications •http://www.w3.org/TR/soap •http://www.w3.org/TR/wsdl Tutorials on WSDL •http://www.w3schools.com/wsdl/wsdl_intro.asp •http://searchwebservices.techtarget.com/originalContent/0%2C289142%2Csid26_gci915766%2 C00.html SOAP/WSDL Authoring and Testing Tools •XML Spy: http://www.altova.com/dev_portal_web_services.html (includes SOAP debugger, client, and WSDL editor) SOAP APIs and stub code generator tools •Microsoft Visual Studio .NET 2003: wsdl.exe (C++, C#, Visual Basic) •http://msdn.microsoft.com/library/default.asp?url=/library/enus/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp •Mac OS X Developer CD: WSMakeStubs •Tutorial: http://www.macdevcenter.com/pub/a/mac/2003/02/04/omnigene.html?page=2 •Java •Apache SOAP: http://ws.apache.org/soap/index.html •IBM Web Services (r)evolution: http://www106.ibm.com/developerworks/webservices/library/ws-peer4/ (generates stubs for use with Apache SOAP) •Sun WebServices: http://java.sun.com/webservices/index.jsp •Perl •Active State Web Services: http://aspn.activestate.com/ASPN/WebServices/SWSAPI •SOAPLite for Perl: http://www.soaplite.com/
Introduction to InDesign/InCopy CS2 Plug-in Development
33
Session 3: Developing Solutions for InDesign Server CS2
Summary
October 2004
bc
Overview of InDesign Server CS2 Developing solutions for InDesign Server CS2
Plug-ins Clients: Scripts and SOAP commands Testing
Plenty of references available
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
Introduction to InDesign/InCopy CS2 Plug-in Development
34
34
Session 3: Developing Solutions for InDesign Server CS2
October 2004
bc
bc Tools for the New Work™
Copyright 2004-2005 Adobe Systems Incorporated. All rights reserved.
35
Thanks for attending this session. At Adobe, we are striving to provide new and innovative tools to enable the creative professional to get their work done, whatever the work may be. We are glad you are joining us in this endeavor. We will see you in the next session!
Introduction to InDesign/InCopy CS2 Plug-in Development
35
