Code Conversion


The primary input to code conversion is the Progress 4GL source code itself. The code as converted is fully preprocessed, with all include files and other preprocessor references, expansions or other modifications having been honored. The result is expected to be syntactically valid 4GL source code. That code is tokenized by the lexer and then structured into an Abstract Syntax Tree (AST) form without any syntactic sugar (elements of the syntax that are only there to enhance parsing or readability, but which have no semantic value).

The derivation of the P2O documents from the database schema (both temporary tables and permanent tables) is documented in the above section on Schema Conversion. The 4GL source code has direct references to database structure embedded in expressions, language statements and other language facilities. During code conversion the P2O documents are used to provide data on the structure, data types, configuration and naming of the schema elements.

The intermediate result is an AST file for each source procedure, named <source_procedure_file_name>.ast.

Transformation Overview

The following diagram illustrates the high level inputs and outputs of the code conversion process:

On the left side are the possible sources of code conversion input. On the right side of the diagram are the outputs that are generated by the code conversion process.


There are 3 outputs from the code conversion process: the name map, the business logic and frame definitions.

The name map is a bidirectional mapping of legacy (Progress 4GL) names and the Java replacements. In Progress, 4GL code can invoke external procedures, internal procedures and functions using names. These names are converted into Java equivalents. Due to the dynamic invocation mechanisms of the 4GL, it is possible to have expressions that calculate these names at runtime. The logic of those runtime calculations is not modified during conversion. That means that if the Progress 4GL code previously had a calculation which generated a legacy name and used that name to invoke the code, then the FWD runtime must be able to dynamically map the legacy name to the Java name in order to invoke it. Likewise, the 4GL provides some features to identify the name of the code that is currently running. This requires that the Java names be converted back to their legacy form to match how the code would be expecting the result.

External procedures are identified by a filename in Progress 4GL and these are mapped into Java class names. Internal procedures and user-defined functions are each identified by a Progress 4GL name which is mapped into a Java method name. All of these mappings are stored in a file name_map.xml which is located in the root of the package for the generated application code. It is included in the application jar file and at runtime is loaded from that archive by FWD.

The Progress 4GL source code (that is not associated with a temp-table definition) is re-factored into one of two possible forms: business logic or frame definition. Both of these forms are Java source code and these are the other primary outputs of the code conversion.

Each statically defined frame and all of the widgets and configuration that is statically defined for that frame is read from the source code (in AST form) and those definitions are separated as a frame definition. A static frame in Progress 4GL is a frame that is recognized as such by the Progress 4GL compiler. The FWD code conversion identifies each of these frames and for each one, a Java source file is created. Each widget defined for the frame is identified and created in Java. All of the frame configuration (e.g. frame phrase contents such as a TITLE clause) is created a Java code in the frame definition. Each widget's configuration (e.g. format phrase contents such as the FORMAT string or HELP string) is likewise moved into the frame definition as Java code. Some of that configuration originally is read from the database schema and some is just hard coded into the 4GL source code. Either way, all static parts of the frame definition are moved into a single Java source file that is specific to that frame.

Each frame definition can be found in a path off the package root (the common directory which is the top-level of where all generated Java code is created) which will have the following relative name ui/<4gl_path>/<program_name><frame_name>.java. The path of the 4GL procedure source file in which the frame was defined is maintained, as a set of sub-package names for the resulting Java classes. All of those paths are under a ui/ directory to organize all the frames for easy access. The program name and frame name are converted to a Java form and then used to create a unique Java class name for each frame.

The rest of the source code that is not part of a static frame definition and which is not part of a temp-table definition, is considered business logic. This includes all of the block structure, variable definitions, control flow, expressions and other logic that defines the application's behavior and functionality. Though the frame definitions (structure, naming and configuration) are separated from the business logic, the usage of those frames is part of the business logic. That result is required to provide compatibility with the original application, since that usage is part of the control flow of the application and the data used in the widgets and/or obtained from the widgets is tightly coupled with the business logic.

Similarly, though the structure, configuration and naming of the database schema (permanent and temporary tables) is defined elsewhere (in the Data Model Objects or DMOs, the Hibernate mapping documents and the database itself via DDL), the usage of those DMOs is tightly coupled to the business logic. That means that the usage of the database is present directly in the control flow and expression processing of the converted business logic and this is required for compatibility. The data regarding the structure, names, data types and other configuration of the converted DMOs is obtained during conversion from the P2O documents as well as an earlier form of the documents called the schema dictionary files. The schema dictionary files are not depicted in the diagram above, but more details can be found in the chapter on Schema Loading in Part 1 of this book.

There is one Java class generated for each Progress 4GL procedure. Each business logic class can be found in a path off the package root which will have the following relative name <4gl_path>/<program_name>.java. The path of the 4GL procedure source file in which the frame was defined is maintained, as a set of sub-package names for the resulting Java classes. The program name is converted to a Java form and then used to create a unique Java class name for each business logic class.

© 2004-2017 Golden Code Development Corporation. ALL RIGHTS RESERVED.