The OpenEdge Hive

Generally, using unqualified field names is not viewed as "best practice" for 4gl developers. There are a number of pitfalls in using unqualified field names, one of the most significant is that when moving code around you can accidentally change which buffers are being implicitly used for the unqualified fields. This can lead to bugs that are rather difficult to track down.

ProRefactor has the semantic and contextual knowledge necessary to determine which buffer name is being implicitly used for unqualified field names. This refactoring finds unqualified field names in the current file (must be a compilable file) and adds the appropriate table or buffer names.

This refactoring is intended to be used as part of a legacy code modernization project. It is unlikely to be used on a day-to-day basis.

This feature assists in the transformation from string concatenation to the use of a single string with SUBSTITUTE. This is done because the full sentence in a single string is easier to translate (for internationalization) than the sentence fragmented into two strings.

Usage

1. In the Navigator view, select the files, directories, and/or projects to be refactored.
2. From the Navigator view's context menu, choose ProRefactor > SUBSTITUTE Refactoring.
3. ProRefactor will parse the selected resources, and find any string concatenations which might require refactoring. It will present the suspect code in the Review Changes dialog.
4. Review, and then accept or reject the code change. You may make manual changes to the source code before accepting the changes.

In some cases, ProRefactor may be unable to automatically suggest changes to the source code. You will be informed of this by a message, and you will be able to make the code change by hand if desired.

This refactoring finds and changes all hard-coded references to database table and fields that you want to rename. You select the projects or directories that you want to change, input a list of old and new names, and the refactoring writes the modified files to an output directory which you can review before merging the changes into your source.

Usage

1. In the Navigator view, select the files, directories, and/or projects to be refactored.
2. From the Navigator view's context menu, choose ProRefactor > Rename Schema.
3. The Rename Schema Refactoring wizard is presented. Input a list of old and new name pairs into the editor, or else enter the name of a file which contains old and new name pairs.
4. This refactoring writes the modified files out to a temporary directory of your choice.

Features

• Is not fooled by buffer names or by abbreviated table or field names.
• Name qualifiers (db.table, table.field, db.table.field) are retained during the change.
• A table can be renamed at the same time that fields in that table are renamed.

Caveats

• Database name changes are not supported (logical, alias, or otherwise).
• Buffer names are not changed.
• Once this refactor is complete, and you have merged the results into your code, you should use a grep tool to find any remaining old name references in comments, strings, and preprocessor directives. Also consider any dynamic queries where you may be deriving the strings from external sources.

Example

Here is an example renaming list:

This refactoring is intended to be used as part of a legacy code modernization project. It is unlikely to be used on a day-to-day basis.

Although most Progress programmers recognize that NO-UNDO is important for application performance, it is not unusual to find legacy applications where NO-UNDO was not consistently added to DEFINE statements. This refactoring is intended to be run as a single pass through old code, in order to correct those statements.

Usage

1. In the Navigator view, select the files, directories, and/or projects to be refactored.
2. From the Navigator view's context menu, choose ProRefactor > NO-UNDO Refactoring.
3. The NO-UNDO Refactoring wizard will be presented, where you are required to choose an empty output directory for the source code that gets changed.

Features

This NO-UNDO refactoring has a few features which are worthy of note.

This refactoring is intended to be used as part of a legacy code clean-up project. It is unlikely to be used on a day-to-day basis.

This refactoring allows you to automatically:

• set the case on table and field names to uppercase or lowercase
• add the table name qualifier to unqualified field names
• expand abbreviated table and field names

Usage

1. In the Navigator view, select the files, directories, and/or projects to be refactored.
2. From the Navigator view's context menu, choose ProRefactor > Names (table and field) Refactoring.
3. The Names Refactoring wizard will be presented, where you are required to choose an empty output directory for the source code that gets changed.

This refactoring checks if an include file is changed multiple times for multiple compile units. If the changes are different for different compile units, then the include file is not written to the output directory, and warning messages are issued.

This section describes each of the refactorings available from ProRefactor's user interface.

This section describes how to load ProRefactor source into an Eclipse workspace, so that you can use it and reference it from your own projects.

Experience programming in Java with Eclipse's IDE is not necessary, but since these instructions gloss over a few details, it would be helpful if you were familiar with Eclipse basics such as creating a Java project.

Prepare Your Eclipse Workspace

1. In Window > Preferences > Java > Compiler, set the compliance level to 5.0. While in Java preferences, also go to Installed JREs, and edit your default JRE. Add -ea -Xss2M to the default VM args. This enables assertions, and sets the stack size to be large enough for recursively descending large syntax trees.
   
   

This section reviews the general aspects of the user interface which are not specific to any one refactoring feature. It also reviews user interface features which are unrelated to refactoring.

Eclipse Workbench

It is beyond the scope of this document to describe the Eclipse Workbench in any detail, however, a few quick notes and terms will make the rest of this chapter more understandable if you are new to Eclipse.

Workbench

Eclipse's Workbench is the entire Eclipse window and all of its contents. You may on occasion have more than one workbench active, but normally you would only work in one workbench at a time.

Workspace

A workspace consists of the list of the list of projects and settings that you see in your workbench.

Project

This term has the same meaning as most other IDEs. A project has a single, top-most directory, which in turn contains all of your project's sub-folders and files.

Resource

A resource in Eclipse is a project, a directory, or a file. In simple terms, it is anything that you might see in the Navigator view.

View

Within the workbench window, you can find various frames which are separated by movable splitter bars. In Eclipse, these frames are called views. Access to most views is through a tabbed interface. Examples of views are the Navigator view, the Outline view, the Console view, and the Tasks view.

Editor

Editors in Eclipse treated differently than views. Multiple editors can be open with a tabbed interface, and can be an unlimited number of types of editors within your Eclipse workbench. For example, there is an editor for plain text, there is an editor for Java, and there is an editor for C++.

Perspective

A perspective describes an arrangement and visibility of the various elements on the workbench. That includes the menus, button bars, views, and editors. There are default perspectives for Java, Java Debugging, for ProRefactor, and for many other plug-ins. Although perspectives all come with a default layout, those layouts can be modified. Eclipse remembers your layout changes.

Plug-in

Eclipse uses a plug-in architecture. This means that the Eclipse core is extremely small, and most of the elements that you see on the Eclipse workbench are actually contributed by plug-ins - even those elements of the workbench which are part of the basic workbench. There are also plug-ins which are not part of the basic workbench, and those include Java and C++ plug-ins which are part of the Eclipse.org project, as well as third-party plug-ins such as ProRefactor.

Menus

ProRefactor contributes menus to various parts of the Eclipse workbench. By default, these ProRefactor menus are only available when you are in the ProRefactor perspective. In the main menu bar, across the top of the workbench window, a ProRefactor menu is available.

Working with Projects

Users of most IDEs are familiar with the concept of a project, but there are a few points of interest which are unique to Eclipse projects and ProRefactor.

Project Nature

Eclipse projects may have one or more natures. Because Eclipse is an IDE for many types of development environments, it also recognizes that any individual project could contain source code for two or more different sorts of development environments, for example, both C++ and Java. Each project nature describes various attributes for a project, such as which project builders are available within the project. (i.e. There would be a builder for compiling the C++ code, and a builder for compiling the Java code.)

ProRefactor is an Eclipse plug-in, and Eclipse provides a user interface to make the installation and updates of plug-ins easy. If you have ever used Eclipse's Feature Updates wizard in the past, then you probably do not need to read this section at all.

Java

ProRefactor and Eclipse require a recent version of Java. Java can be freely downloaded and installed from java.sun.com.

Eclipse

ProRefactor requires a recent version of Eclipse. Eclipse can be freely downloaded and installed from www.eclipse.org.

Eclipse shuts down when parsing

Summary

Add -vmargs -Xss2M to your shortcut for running Eclipse.

Details

Proparse requires a large stack in order to store all nodes of a large program in memory. Since it was Java that loaded Proparse, it is the Java Virtual Machine which needs to be configured for running with a large stack.

If the stack size is not large enough, the JVM will shut down with a stack overflow error, but you will not see any error details when launching Eclipse and javaw.exe as Windows processes. It doesn't take a huge program to cause this stack overflow. A program with one or two thousand lines of COMPILE statements is enough to do it. The stack size for javaw.exe by default is 1MB. The argument -vmargs tells eclipse.exe to pass any following arguments on to the JVM. The argument -Xss2M tells the JVM to set the stack size to 2MB.