Tag Archives: CEP –InDesign Plugin

Using AngularJS Integration for Adobe’s Common Extensibility Platform (CEP) Extensions

CEP Extensions are the preferred way for developers to extend Adobe CC applications. In an earlier article, we presented an overview and some tips on migrating plug-ins to CEP extensions This article presents the case study from integrating Angular JS in CEP extensions.

Design Principle

In an era of mobile applications, the user now expects everything available in single page, and wants to accomplish everything without making much effort. All the server interaction should be invisible to user. Like conventional websites, there’s no room for page reloads, page transitions etc.

Therefore, as far as possible, we recommend that all CEP Extensions should be Single Page Application. We can achieve this by using Angular JS framework as described below.

Angular JS

AngularJS, commonly referred to as Angular, is an open-source web application framework maintained by Google and a community of individual developers and corporations to address many of the challenges encountered in developing single-page applications. Its goal is to simplify both development and testing of such applications by providing a framework for client-side model–view–controller (MVC) architecture, along with components commonly used in rich internet applications.
Read More…

Why AngularJS is best choice for your CEP Extension?

Angular provides:

  • 1. MVC Framework : With Angular, you can architect your extension in MVC pattern. Views present the data in various DOM elements and Controllers are the behavior behind the DOM elements. You don’t have to worry about registering callbacks or watching model changes.
  • 2. Two-way data binding : Suppose, your extension needs to update the user with some information. Angular makes it very easy to update the view when the model changes and update the model when the view changes. So, you won’t have to worry about DOM manipulations from now!
  • 3. Routing : Your extension is getting more complex. Is it involving multiple pages? No Problem.
    With Angular, you can provide different routes to your extension (via a service called `$routeProvider`). This routing service makes it very easy to wire together controller, views and templates. For e.g., you want to move from A.html (having A_controller as it’s controller file) to B.html (B’s controller is B_controller). As soon as you route to B, its controller will take over the execution from A_controller.
  • 4. Services : Okay, MVC and routing are fine. But you want to share some functionality across multiple views. Can Angular help you?

Yes. Angular Services are the singleton objects that you can use to organize and share code across your extension. To use an Angular service, you add this service as a dependency for the components that need the service (This is called dependency Injection).

Here is the architecture of an extension that we have developed using AngularJS


Business Case

We were required to develop an extension wherein :

  • 1. A user can login into the extension.
  • 2. His project list stored at the cloud will be fetched.
  • 3. He can tag these projects to the documents.
  • 4. As he works on the document, his activities will be recorded and stored to the cloud against the selected project.
  • 5. When he changes the document, the associated project will automatically be changed.
  • 6. Next time when he opens the document or takes that document to a different location, the project association will remain intact with the document and can log his activity from there.
  • 7. Add or edit the project details like name, colour code etc.
  • 8. Last but not the least, it needs to be supported by Photoshop, InDesign, Illustrator, InCopy and Premiere Pro.
Benefits observed and time saved

In above scenario, the main advantage that Angular has given us is the decoupling of different components of the extension into views (and their controller). For example, we have created separate views-controller pairs for Login, Project List, Create/Edit project. This makes testing, debugging and code-maintenance very easy. Background tasks like tagging a document, observing the user activities were implemented using the services.

So, later on when we need to extend the functionality for other apps, there was no need to touch the views that were independent of the apps like login page, project listing etc. We only added the services of the dependent components. For example, tagging a document is implemented differently in Photoshop than in Illustrator, so we just added the service for it and whoa, our extension was ready for a new app! Furthermore, due to lazy initialization of the services, the appropriate service came into play only when it was required.

InDesign Development & Common Extensibility Platform (CEP) Technology

In September 2013, Adobe announced that they would be discontinuing the CS Extension Builder and would replace it with a new development framework based on HTML5 and JavaScript. CEP technology allows developers to build extensions that can run across all Adobe Creative Cloud (CC) platform. Clearly, this is a significant win for plug-in and extension developers as it cuts down on development time and resources. However, as plug-in developers move legacy plug-ins from CS 5.5/CS6 to CC and CC14, they must keep in mind several issues before the plug-ins can be ported to CEP extensions. Last quarter, we have helped our clients to adapt this change by integrating the latest web frameworks like AngularJS with extensions, thereby following a strict MVC driven approach as used to be the case with C++ plug-ins. We have structured the extension in a way that it can be extended to use with multiple apps. This, we have achieved by architecting app-specific implementations separately and creating a core services layer. As an example, one of our new extensions is running seamlessly in InDesign, PhotoShop, Illustrator and InCopy.

Tips For “Plug-ins to Xtension” Porting Projects
  • CS5 onwards model and ui separation needs to be done so that model plugins may safely work in background threads, and, the user interface for a set of features can be refactored easily at any time
  • CS6 onwards, significant UI changes need to be done using Adobe Express View Engine (EVE) to take advantage of localization friendly services
  • If any third-party libraries such as boost, xerces, curl, GSOAP etc. are used in the legacy plug-in projects, we need to check if the old libraries are compatible with the latest OS SDKs; and if obsolete we need to build those libraries using their source code and then dynamically link them with the plugin.
  • We need to make changes to code caused by the changes in the public API in SDK.
  • Our experience is that most legacy plug-ins neither have good engineering specs or documentation; nor good test suits for benchmarks. Porting projects must build their own benchmark test suites to avoid bug discovery late into the porting projects
  • As legacy plug-ins have evolved, users have extended their template and test documents through multiple versions. There are data model changes across plug-in SDKs that creates bugs with legacy documents. Some documents may need to be re-created when plug-ins are moved across to CC

We have in-depth knowledge and experience in helping customers move their plug-ins to extensions. We are supporting developers in US, Germany, Switzerland, Australia with their InDesign projects. Our customers trust us as we deliver high quality services with transparent business practices at cost-effective rates. If you are looking to port your plugins to CEP and/or looking for a team to support your xtensions, talk to us.