When
EGL Community Edition (CE) was developed, many changes were made to improve the user experience regarding code generation. In Rational Business Developer (RBD) version 8, the best code generation changes from EGL CE have been merged into RBD, and some new features have been added as well. In this blog entry I will review the generation updates that were made in RBD 8, which can be broken down into project configuration changes, default build descriptor changes, and generate after build preference changes.
Project ConfigurationIn RBD 7, an EGL project could only be configured for one target generation language, and that language could not be easily changed after the project had been created.
In RBD 8, an EGL project can now support multiple target languages, and a project will be configured dynamically to support a new target language as part of code generation. One of the biggest benefits of these changes is that an EGL Rich UI project can now contain parts that are generated to both JavaScript (e.g. Rich UI Handler) and Java (e.g. Services), which allows an entire end-to-end application to be developed in a single project.
Another project configuration change in RBD 8 is the addition of a new folder to hold generated code (e.g. <Project>/EGLGen/<language>). In the past, generated code was placed in the same location as hand written code (e.g. /src for Java), which made it difficult to manage the content of those directories. With the addition of the EGL generation directory, it is safe to assume that all of the content contained within the EGLGen directory has been derived from EGL source files, which will make the content much easier to manage. The addition of multiple generation directories also allowed for the
removal of the Rich UI Generation Mode setting, which was used in RBD 7 to control whether code was generated for Development or Deployment. Instead of needing to change the generation mode between tasks, which was an expensive operation, the IDE now manages both versions of the generated code at the same time, using the /EGLGen/JavaScript/Debug and /EGLGen/JavaScript/Target directories.
[NOTE: EGL Web projects and EGL Portlet projects require that runtime Java code be located in the /src directory, so it is not possible to generate code into the EGLGen folder.]
[NOTE: Only new EGL projects created in RBD 8 are configured to use the EGLGen folder for generated code. Projects that were created in other versions of RBD will continue to generate code into the same location that was used when the project was created.]
Default Build DescriptorsIn RBD 8, all resources can now specify up to five default build descriptors instead of two. The five build descriptor options include; Java Debug, JavaScript Debug, Java Target, JavaScript Target, and Cobol Target. When a part is being generated, all of the default build descriptors for a given resource are used. For example:
(Image 1 - An EGL Rich UI Project in RBD 8, with default build descriptors configured for the project and some packages)
In addition to providing options for additional default build descriptors, the default
build descriptor property page has also been updated to show which default build descriptors will be used for a selected resource, even if a default value has only been specified for a parent resource. With this change, it is much easier to determine which default build descriptor will be used for a resource, instead of needing to open the default build descriptor property page for one or more parent resources in the current hierarchy until a value is found.
( Image 2 - The default build descriptor property page for MyRUIHandler.egl, as shown in Image 1 )
The default build descriptor property page has also been updated to make it much easier to locate a build descriptor when configuring a default. Instead of listing all build descriptors in the workspace, the new selection dialog now contains a tree, similar to the Package Explorer, which represents the build descriptor resources in the workspace. Since default options are now configured by language, the available options are also filtered to show only the build descriptors that are configured for the default language currently selected (e.g. Java, JavaScript, Cobol, etc).
Generate after Build PreferenceAs a result of the changes to the generation directories and default build descriptor options in RBD 8, the ‘Generate on Save’ preference options have also been updated. In RBD 7, the ‘Generate on Save’ preference allowed a user to configure which part types were generated automatically when they were built. While this was useful, it tended to result in compile errors in the generated code, since some parts would be generated automatically and others needed to be generated manually. In RBD 8, the ‘Generate on Save’ preference has been renamed to the more appropriate ‘
Generate after Build’, and the preference is now used to specify what target languages should be generated after a build, instead of what part types should be generated after a build. If a target language is selected for automatic generation, any part that has a default build descriptor option specified for the selected language will be generated after it is built, which will result in all parts being generated for a particular application as it is developed.
[NOTE: By default, the ‘Generate after Build’ preference is configured to generate code for the Java and JavaScript target languages.]
( Image 3 - The EGL Generation preference page found in RBD 8011 )
In RBD 7, the ‘Generate on Save’ option was used to make sure that specific parts were generated before they were debugged, since the debugger executes the generated version of the source for these parts (e.g. Rich UI). In RBD 8, the EGL Advanced Builder will now generate the debug version of any part when it is built, regardless of the ‘Generate after Build’ preference settings, if a generated version of the part is required by the debugger. This change means that any EGL application can be debugged without ever invoking a manual generation, assuming the workspace Auto Build option is enabled.
[Hint: The Debug version of an EGL part can be regenerated by rebuilding the file that contains the part, or by rebuilding the project that contains the part.]
Finally, in RBD 8011, an additional option was added to the ‘Generate after Build’ preferences to control whether or not the EGL Deployment Descriptor (EGLDD file) should be generated for a particular target language (i.e. Java or COBOL). This option is enabled by default for Java, and is disabled by default for COBOL.
Conclusion
In this blog entry I have covered some of the more significant EGL code generation changes in RBD 8. If you have any questions or comments about these changes, or if you would like more information about any of the other code generation changes in RBD 8, you can post them in a comment to this entry.
-Brian