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.