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.
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.
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.
Why AngularJS is best choice for your CEP Extension?
- 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
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.