Tag Archives: Forms conversion

QAFE 3.3.0 & Forms Conversion 1.12.0 Released

QAFE 3.3

We’ve just released version 3.3 of the QAFE Engine.

One of the most important features in this release is the introduction of Client Side Events. Without changing any QAML code, you can make sure that the body of an event gets executed on the client-side, as in the browser (change the file and add the value “clientside.event.enabled=true”). The biggest benefit is increased performance because a server round-trip is not needed, resulting in a more responsive application. For example, Chrome Developer Tools shows that it’s far more efficient.


Because the execution happens client-side, you can see that QAFE doesn’t use any network resources anymore.

Note: by default the value for clientside.event.enabled is false.

Another big feature is the usage of REST interface to invoke business-actions. The benefit is that other front-end technologies (such as AngularJS, Web Components, any AJAX supported UI library)  can use the same logic through REST-JSON.

  • The QAFE Engine is now less dependent on third-party software
  • We’ve done cleanup of dependencies, e.g. XML libraries
  • New and improved Forms Conversion wizards for the QAML Builder
  • Updated documentation on GitHub
  • Several bugfixes


Forms Conversion 1.12.0

QAFE Oracle Forms Conversion to HTML5 and QAFE Oracle Forms Conversion to ADF are also updated and now available for anyone who wants to modernize the Oracle Forms stack to JEE standard applications.

Highlights of this release:

  • Major improvements on script generation, where all the logic is collected from the Oracle Form
  • In ADF conversion, the summary page in the wizard also shows the explicit TODOs for ADF developers
  • Specific combinations of items are rendered correctly
  • Layout improvements by improving the algorithm
  • Several bugfixes

To get started with our latest release, download the software here.

Character encoding after conversion

In this blog post, I will discuss the results of an Oracle Form converted to both ADF and QAFE that include unicode characters, and how to properly display them.

In case of non-ASCII characters support, make sure that the file itself is properly encoded. We can rectify the encoding by e.g. opening a file, that has non-ASCII characters, in a text editor like notepad (for Windows).

With the file opened:

  1. Go to “File -> Save As” in the menu.
  2. Select the proper encoding in the dialog at the bottom of the window. UTF-8 in our case.
  3. Save the file with the new encoding and overwrite the old file.

Figure 1: Windows notepad save file dialog

Character encoding in ADF

If you don’t take sufficient action, converting an application that contains non-ASCII characters (such as Chinese or Russian) from Oracle Forms to Oracle ADF would be displayed as question marks. Our objective is to make these characters display properly when running the ADF application.

For the example I use in this blog, I have modified 3 buttons out of a simple Oracle Form  so that they contain non-ASCII characters, I then converted the application to ADF. Below is the result of running the form; note the 3 buttons with question marks in the top left.


Figure 2: The running application with non-ASCII characters in the buttons

Set-up JDeveloper to use correct encoding

Now that we verified the file encoding to be in UTF-8, we can proceed with setting up JDeveloper to use the proper encoding.

There are three ways to set-up character encoding in JDeveloper

  1. Preferences
  2. Default project settings
  3. Per-project settings


In JDeveloper, in the menu, go to “Tools” and select “Preferences”. The preferences dialog shows up, with “Environment” being the default selection.


Figure 3: Environment settings in JDeveloper

In case of the demo application, the encoding is set to “Cp1252”. The application in question contains characters that are not available in that encoding, so we switch this value to something that does support it. In this case UTF-8.

With that done, all projects in the workspace now show “UTF-8” as the value for the Encoding field when you select Preferences from the Tools menu.

Default project settings

In JDeveloper, in the menu, go to “Application” and select “Default Project Properties…”. The default project properties dialog shows up.


Figure 4: Default Project Properties encoding

Select “Compiler” and change the “Character Encoding” dropdown value to UTF-8. All projects in the workspace show UTF-8 as the value for the “Character Encoding” field when you select “Default Project Properties” from the “Tools” menu.

Per-project settings

The encoding can also be set on project-level, when the encoding is specific to a certain project.

To do this, in the menu, go to “Application” and this time select “Project Settings…”. The project settings dialog shows up.

Select “Compiler” as shown in figure 3 and set the character encoding value to UTF-8. This encoding will now be taken into account for the current active project.

Last step

With all the IDE configuration properly set-up to use UTF-8, there is one final step to take. In XML based files such as JSF Fragments, jsf, etc. we need to modify the XML prolog (<?xml version=”1.0″?> by default) to use the correct encoding in XML. Change the prolog to <?xml version=”1.0″ encoding=”UTF-8″?> (added the encoding attribute). Change the question marks.

The result


Figure 5: The application running with unicode support

Character encoding in QAFE

When converting your Oracle Form to QAFE, the output is a QAFE project in Eclipse. Because Eclipse handles encoding settings differently, the steps are also different.

Character encoding in Eclipse

Setting up proper encoding support in Eclipse is, just like JDeveloper, mostly configuration.

In Eclipse, this is usually configured per workspace. But if wanted, there is also a finer control of what should be UTF-8 encoded.

Content type specific encoding

In Eclipse it is possible to assign an encoding to individual content-types. It can be CSS, Java source files, property files or any other type that Eclipse supports. To do this, go to: “Windows > Preferences > General > Content Types > Text > {Choose file type} {Selected file type} > Default encoding > UTF-8”.


Figure 6: Content type encoding

Character encoding per workspace

To enable a specific encoding per workspace (meaning all projects inside that, both existing and to be created), go to: “Window > Preferences > General > Workspace”. Select the “Other” radio button in the “Text file encoding” block, and choose the correct encoding.


Figure 7: Workspace wide encoding

The result

A few notes about the end result; In this case I changed the labels to use UTF-8, but it would work for any kind of display text, be it on buttons or text fields.


Figure 8: End result