EDT:The Differences between EDT 0.7.0 and RBD

If you have worked with Rational Business Developer (RBD) before, you will notice that there are some differences between EGL Development Tools (EDT) and RBD in both the EGL language specification and the IDE. The following is a list of some of these differences, and links to additional information on these changes.

EGL Language

Various changes have been made to the EGL language in EDT. Some of these changes include:

• Nullability and Instantiation
• Relational Database Access (See below for more information)
• Service Oriented Architecture (SOA) (See below for more information)

A longer list of changes can be found on the How to move an RBD app to EDT page and additional examples of how the language has changed can be found on the Code Snippets page.

Relational Database Access

In RBD, data is obtained from a Relational Database using an SQLRecord, with the specific information about the database table being stored directly in the Record definition as properties of the SQLRecord Stereotype. Having all of this information specified as part of the SQLRecord Stereotype limits the usage of the record definition to a single data source, since it is not possible to add multiple Stereotypes to a single part.

In EDT, the Entity Stereotype has been introduced to indicate that a basic Record or a basic Handler will be used with a Data Source to access information at runtime. The column specific information from the SQLRecord Stereotype is now specified directly on the fields of the Entity, and the connection information is linked to the Entity at runtime using a Resource Binding or an SQLDataSource Binding. In the future, existing Entities can easily be used with additional Data Sources by adding additional properties to the fields of the Entity for the new Data Source, and by defining a new Resource Binding to indicate how the Entity should connect to the Data Source at runtime.

More information about Relational Database Access can be found in the EDT Help system under Getting Started -> EGL Support for Relational Databases.  The complete specification for Entities can be found in attachment to the EGL SQL Data Access enhancement.

Service Oriented Architecture

While there have not been many changes in the area of Service Oriented Architecture (SOA) for EDT, the following changes are worth mentioning:

• ServiceLib.bindService has been replaced with SysLib.getResource, and the BindService annotation has been replaced with the Resource annotation.  These elements were changed to use a Resource so that multiple versions of the same resource can be provided for Development, Test, and Production environments.
• The RestBinding annotation has been replaced with the following code snippet
• Changes have been made to the way that Request Headers are specified, as displayed in the following code snippet
• ServiceLib.getCurrentCallbackResponse() has been replaced with a new service callback function parameter, as displayed in the following code snippet

In addition to the changes listed above, it is worth noting the following SOA limitations in EDT version 0.7:

• Only Services of type EGL REST RCP can be developed in EGL
• Only Services of type EGL REST RCP or REST can be invoked from an EGL application
• Only JavaScript based applications (e.g. Rich UI applications) can invoke Services

More information about Relational Database Access can be found in the EDT Help system under Getting Started ->EGL Support for SOA.

Generation - Configuration and Invocation

In RBD, all generation configuration and runtime information is stored in a Build Descriptor file (.eglbld), which can either be specified as part of the generation process using the Generation Wizard, or can be configured on a resource for automatic generation using the Default Build Descriptor. In EDT, Build Descriptor files are no longer used, and the information that they contained is now specified in two separate locations. The generation configuration, which indicates things like Target Language, Generation Directories, etc, is now specified as part of the Generation properties for a resource (i.e. Project, Package, File), while the runtime information, which indicates things like Database information, Target Server, etc, is stored in the Deployment Descriptor file (.egldd). The generation configuration was moved to the Generation properties page because this information is now specific to the type of generator that is configured for a particular resource. The runtime information was moved to the Deployment Descriptor because this information is specifically related to the deployment and configuration of the application. 

While an application will be configured during deployment to use the information found in the Deployment Descriptor, this information is also required when an application is being debugged or previewed. To allow this information to be located by the application when it is being debugged or previewed, a new Default Deployment Descriptor property has been added to all EGL Projects. This property is configured to use the Deployment Descriptor file that is added to a new project, and can be changed as necessary by right clicking on the Project and selecting Properties.

The Generation properties for a resource, and the Default Deployment Descriptor property for a project, can be accessed by right clicking on the resource and selecting Properties.

In addition to the Build Descriptor file being removed in EDT, the ability to manually generate a part has also been removed. In EDT, a part is generated whenever the part is compiled, using the generators that are specified in the properties for that part. While it should not be necessary to regenerate a part if the source has not been modified, a part can be regenerated by invoking a Clean build on the project containing the part (Project -> Clean).

IDE

The EDT IDE has been updated to provide new features and improvements. The following is a list of some of these features, although it does not include all of them:

• Quick Fix/Quick Assist - Quick Fix and Quick Assist have been added to the EGL Source Editor, and can be invoked by pressing Ctrl+1. If the cursor is located over an error, and a fix can be provided, it will be listed in the popup window that appears. If the cursor is not located over an error, and there is a code snippet available for the current location, it will be listed in the popup window that appears. For example, the New Function Quick Fix can be used to create a new function for an unresolved function reference, which often occurs when writing a Call statement for a Service invocation, or when defining an Event Handler for a widget. 
  
• Project Templates - The EGL Project Wizard has been rewritten as an extensible template framework, which allows for the contribution of new project templates that create EGL projects with different configurations and content. The Hello World project template has been provided in EDT version 0.7.0, which creates an EGL project with source demonstrating an EGL Rich UI web application calling an EGL service.
• Record Templates - In addition to the Record templates that are shipped with RBD, EDT version 0.7.0 also adds a new template that provides support for creating an EGL Entity Record from an SQL Database.

In addition to the changes mentioned above, a few features that can be found in RBD do not exist in EDT 0.7.0. Two of these features are the EGL Data Access Application Wizard, which has been partially replaced by the new Record Wizard template, and the Data Perspective, which is not freely available and cannot be included in EDT.

Debugging

The EGL Debugger provided with RBD is an interpretive debugger, meaning that each line of EGL source is being interpreted by the debugger framework to mimic the results of the application running in the target environment. [Note: In RBD, only parts that can be generated to Java and COBOL are interpreted, while parts that are generated to JavaScript are not interpreted]. In EDT, the EGL Debugger is not an interpreter, and is always running the generated version of the application. As each line of source is executed in the target environment, the EDT Debugger framework maps the information back to the appropriate line of EGL Source that resulted in the generated code currently being executed.  While the EDT debugging framework should appear to work the same as it does in RBD to someone that is debugging EGL source code, the change from an interpretive debugger to one that runs generated code in the target environment was necessary for supporting an extensible generator framework.  

As a result of the change from an interpretive debugger to one that runs generated code, it was necessary to add a new Test Server to the IDE, which is capable of running EGL Services that have not yet been deployed.  Having an IDE Test Server provides two additional benefits; 1) response time for services that have not yet been deployed should be greatly improved, since a service does not have to be terminated once it has been started, unless a change is made that cannot be managed by the VM's hot swapping framework, and 2) EGL Libraries that require a J2EE context will now work as expected when being debugged.

In addition to the changes listed above, it is worth noting the following debugger limitations in EDT version 0.7:

• Hovering over a field in the EGL Source editor will not display the value of the field in a popup window
• It is not possible to change values in the variables view
• Conditional and Global breakpoints are not supported
  
• Watch expressions are not supported

Widgets

In RBD, the EGL Dojo Widget set consists of a Runtime project and a Widget project. To use this widget set in a Rich UI application, the project containing the application must depend on the Dojo Runtime project, and not the widget project. To avoid the confusion that having two projects introduced, the Runtime project and the Widget project have been merged into a single Dojo Widget project. To use the Local version of the Dojo Widget project, a Rich UI application now only needs to have a dependency on the org.eclipse.edt.rui.dojo_0.7.0 project. To use the remote version of the Dojo Widget project, a Rich UI application only needs a dependency on the org.eclipse.edt.rui.dojo.remote_0.7.0 project.

Moving applications from RBD to EDT

In addition to all of the information listed above, visit the How to move an RBD app to EDT page.