Author: JianJun Jiao
Editor: Suhas Kakkadasam Sridhara Yogin
This article explains how some commonly made errors can be avoided when developing LiveCycle ES2 applications using Workbench.
Here are some commonly made errors:
- Use a new application version for every “active development stream”
- Create separate project sandboxes for each developer
- Apply patch to a running application version in an iterative development pattern
- Put all project assets in one application
- Seldom use cross application references
- Select a deployed service as a subprocess
Here are solutions:
- It is inadvisable to create a new application version for every “active dev stream”. Application versioning is not designed for that. In such a case, it would plunge the project in chaos when you merge all streams. The difficulty would be that you have to change all references. In such parallel development, structurized applications and folders in applications could be used for this purpose. (For more information on application structure, please refer to Best Practice for Developing with LiveCycle Workbench ES2 – Application Structure, Iteration and Transition)
- By means of a good application structure design, parallel development can be achieved more easily. Some suggestions are:
• Avoid multiple copies of the same project for parallel developments. When you merge these copies, you will face difficulties in disordered references and versions. With a good project/applications structure design, most of the development should be done in the project applications instead of their copies.
• Resources files, say data models, xml schemas and form fragments should not be changed too often. For example, every time when you update a xml schema, the form that is using the xml schema should also be updated.
• Resources files say data models, xml schemas and form fragments should not be put in the sandbox. Otherwise, when we integrate them into the project applications, you have to manually update the references in those assets which are using these data models, xml schemas or form fragments.
• Different developers could create their own applications or folders in the applications as their sandbox. Thus, they can be easily integrated to the project applications. But it’s better to use this way for prototype development. When it’s good for use, integrate it with the project.
(For more best practice on parallel development, please refer to Best Practice for Developing with LiveCycle Workbench ES2 – Better Parallel Development: Operations)
- You can “apply patch” to the running application and maintain development iteration in a new version. However, there is no direct way to “apply patch”. You have to undeploy the running version, make changes and then deploy it again. Alternatively, you can use major version for iterations and minor version for patches.
- Your data and application assets are actually not well structured if most of them are in one application. Application is to manage assets logically. Even if all those assets have the same type, they still can be distributed to several applications per some logical or functional criteria. Besides, if you put many assets in one application, it would increase the application size and asset count. Subsequently, you’re likely to meet performance issues when developing on this application.
- Some users are obliged to put all reference assets in the same application to avoid cross application references. The reason is partly because they believe the reference is somehow confusing when they create new application versions: some refer to old versions of assets and others refer to new versions. The references in the same application and across application are also known as near and far references. a. The near reference is relative and can thus be carried over multiple versions.
For example, /app/1.0/process2 is a subprocess of /app/1.0/process1. If you create a new version of this application, /app/1.1/process2 is a sub process of /app/1.1/process1 in the new application version.b. The far reference is absolute and can thus be partially carried over versions.
For example, /app1/1.0/process1 is a sub process of /app2/1.0/process1. If you create a new version of application app2, /app1/1.0/process1 is still a sub process of /app2/1.1/process1. But if you create a new version of application app1, /app1/1.1/process1 is not a sub process of /app2/1.0/process1 or /app2/1.1/process1. You need manually create a new sub process based on this new version sub process in the main process.
Once you have understood the difference of near and far references, you can make use better of them.
- When a process need use another process as a subprocess, I found some uses ever used the “Activity Picker” to use the subprocess or use the deployed service when define the subprocess. It still works but it’s actually calling a service instead of using a subprocess. We can use the “Subprocess” activity to define a subprocess. The difference is as following:
• The “Activity Picker” can only use a deployed service. You can’t pick a process that hasn’t been deployed. When an application is deployed, the process in it becomes a service.
• The reference path of the process and its “subprocess” by “Activity Picker” can’t be changed. For example, if /app1/1.0/process1 calls /app1/1.0/process2 in the same application by “Activity Picker”, when you create a new version of /app1/1.1. The /app1/1.1/process1 still calls /app1/1.0/process2. But if /app1/1.0/process1 uses /app1/1.0/process2 in the same application by “Subprocess” activity, when you create a new version of /app1/1.1. The /app1/1.1/process1 uses /app1/1.1/process2 now.