LiveCycle ES2′s application model best practice – Modularity
In LiveCycle ES2 the development model has changed from the repository centric approach that was used in previous versions. The new development model is application centric rather than relying on loose assets in the repository. When developing applications it is critical that proper modular design patterns are used. There are 3 primary factors that should be considered:
- Number of processes in the application
- Physical size of the application (the number of bytes)
- Actions executed by the application’s process during deployment
There is no set limit for the number of assets within an application; however larger applications could lead to issues during deployment due to transactional constraints. LiveCycle was tested with significantly sized applications, however, a point will be reached where deployments will suffer from performance issues if applications become too large or complex. In addition, it should be noted that manageability and maintenance of an application will become more difficult as the number of assets in an application grow. Also note that the use of slow performing systems and network latency will exacerbate deployment problems with large applications.
Modularity should be a primary development objective when designing applications. Putting all assets into a single monolithic application does not take advantage of the application model and the modularity that it allows. Modular development will allow for greater control over versioning, better performance, and much more flexibility in application design. Modularity does mean breaking up application assets simply to reduce the number of items in an application. Assets should be grouped so they target a specific use case, area of functionality, or so they are grouped because they are maintained in a similar way or by a similar group of developers.
Consider the case of Java and creating applications; it is possible to put all of your Java classes into one jar file. You could even take third party libraries, unjar them, and then rejar them into your applications jar file. If you took this approach you would quickly reach a point where your application is unmaintainable. Application development in LiveCycle should be thought of in a similar fashion, taking advantage of the capabilities that are present to provide modularity.
How to separate existing applications will depend on the interrelationship of assets held inside the application. In most cases, when an asset is moved to another application the other assets that depend on it will need to be modified to reflect the new location of the asset. For example, a process that uses a form would need to be modified to use the new form asset in its new location.
Ultimately, as there are no set guidelines for actual modularity of any given application, the developer will need to exercise reasonable common sense when developing in the ES2 application model. Having said that, if one begins to see dozens of process or assets accumulating in an application, this should be a signal to review the application’s modularity. Another warning sign is if an application deployment begins to take prolonged times (over a few minutes) or actually timeout.
For more information on the LiveCycle ES2 application model, please see:
Craig Randall’s blog post on the subject:
Original article at http://blogs.adobe.com/livecycle/2011/03/livecycle-es2s-application-model-best-practice-modularity.html.
Comments are closed.