Tag Archives: Oracle Forms

FAQ’s about design choices for output generation

By: Raviksishnan Nair

This article is intended to provide an explanation regarding some of the design choices that were made as part of the conversion of Oracle Forms to an ADF application, using QAFE. Some of the FAQ’s related to the design choices that have been made for output generation have been listed. The information provided is of technical nature. 

There are other libray projects along with the output, why is this?
The output generated as a result of converting Oracle Forms to an ADF application contain other library projects. These advanced ADF libraries are there for the following reasons:

  • Implements reuse
    – Base classes for model
    – Taskflow templates / Page templates
    – Utility classes
    – Advanced declarative components
  • Implements best practises in a ‘forms friendly way’

Why does the output contain SQL for database view?
During the development of conversion code, scenarios were found, where data from different tables are being edited using a single UI. In terms of Oracle Forms, multiple block items were combined in a canvas and updating the data would have had effect on respective tables.

In order to maintain this behavior, database views were opted to support the operations being done on data from different tables. With this the generated ADF code stays less complex and clean. It also allows the database to manage the logic of updating the data to appropriate tables.

Another advantage is that the database views can be seen as API’s to the database itself and hence it will be easy for an application to work with a single source of data without bothering with the details of the exact source(s).

Why does the output contain SQL for instead of triggers?
The ‘instead of’ triggers are used to replace form specific triggers such as PRE and POST insert and update triggers simply because the PRE and POST triggers are forms specific and they don’t exist in an Oracle database.

What happens to the PRE and POST queries set up in forms associated with select statement?
The PRE and POST query set up in forms associated with a select statement are converted as comments and made available as part of the database view script. They are put as comments because the logic in such scenarios are found to be complex. Parsing the same can’t guarantee a solution which would be useful due to missing information at the point of conversion.

What do I have to do in order to make the application work completely?
The generated output provides hooks to couple the logic extracted from the converted form(s). The logic is provided as part of the call stack script available in the resource folder as part of the output.

The generated task flow bean classes are the ones which are referred to as hooks. In the generated output, the API’s in these classes are left empty. This is for the flexibility of the developer to choose what logic should go in there. It can be associating the trigger script or implementing the logic in the script in another efficient way.

The following example will give a clearer picture:

Figuur 1

Figure 1 shows that there is an action listener associated with a task flow bean API called: executeDetailsClick. This API is the place holder or the hook where the logic needs to be implemented by the developer to replicate the button click action in forms.

Figure 2 shows the API in a generated task flow bean class:

Figuur 2

From the forms application it would be known which trigger needs to be fired when a particular button is clicked. In this case: WHEN_BUTTON_PRESSED, SQL code is available as reference in the generated script output file as shown in Figure 3:

Figuur 3

In general, the generated output has the logic extracted and made available. It provides the flexibility, for the developer, to choose if the same needs to be applied or a more efficient way needs to be approached for achieving the result.

How do I know which form elements get converted to what?
This link provides the information about which form element gets converted to an ADF element as per the current generation process.

Please feel free to contact us at for clarifications, further explanations or new queries.

QAFE Installer 3.4.0 Release

This week QAFE Installer 3.4.0 has been released for everyone to use. Downloads for Windows, Mac OS X and Linux can be found on our download-page. The latest release contains some new features and improvements to the current functionality.


First up, integration with JavaScript has been implemented. This makes it much easier to integrate your QAFE application with other Javascript libraries. The call-script built-in has been introduced to call any JavaScript method with parameters included in the web page. It is also possible for a JavaScript method to call a QAFE event. Using this new built-in it is now possible to for example integrate an Oracle Forms application into the QAFE application. Both situations are described in our previous blogs listed below.

 QAFE Installer 3.4.0 ReleaseNOTE: This will only work when client-side handling is enabled!

See also:

Datagrid import

The import functionality of a datagrid has been extended. Previously, the import functionality would always overwrite the currently displayed data in a datagrid. An extra attribute, import-action, has been introduced with two possible values: add and set. The default option is set, which will overwrite all currently displayed data in a datagrid. The other option, add, will cause the application to append the data to the end of the currently displayed data within a datagrid. The default option is set, which corresponds to the import functionality of the datagrid as it was before. For more information, please check the HOWTO listed below.

See also:


Another addition is the ability to select and thus visually expand a specific stack within a stackpanel, when opening a window. The selected attribute has been added for the stackpanel, where the id of the selected stack has to be filled in.

It is now possible to have a more flexible layout, specifically a fluid layout. This means that the elements within a layout will be positioned based on the size of the screen. This will work for both SDI (single document interface) and MDI (multiple document interface) mode. This is done purely using CSS. The HOWTO listed below will explain the functionality in more detail.

See also:

Client-side handling

Several improvements have been made to the client-side handling introduced in QAFE 3.3.0. Including fixes for multiple data types being sent between the front-end and back-end. For now, client-side handling is still optional, but will be made default in the future.

Thank you for reading this blog and enjoy using the latest version of QAFE! For any further questions or remarks, please mail us.

Blog by: Arvind Mohabir

Embedding Oracle Forms in your QAFE Application (Part 2)

In part 1 we discussed communication from QAFE to Oracle Forms. This blog will explain communication from Oracle Forms to QAFE. To allow for Oracle Forms integration in QAFE a few changes are needed in both the web-application and Oracle Form.

(Note: currently the following only works when client-side processing is enabled)

Prepare Web-Application & QAFE Application

Passing data from Oracle Forms to QAFE is, usually, a two step process. From Oracle Forms you will be calling a JavaScript method with the values you want to pass to QAFE. This JavaScript method in turn calls a QAFE event passing needed values.

Prepare QAFE Application

Add the event which will be invoked from the Oracle Form to the QAFE Application:

Listing 1: QAFE Application

Prepare Web-Application

Add a JavaScript function to the Web Application that contains the Oracle Forms applet. This function will call the QAFE provided JavaScript function invokeQafeEvent, which invokes a QAFE event. This newly added function can also be used to handle the embedded Oracle Forms applet e.g. hide it.

The invokeQafeEvent takes the following parameters:

Parameter    Type    Description
eventId         String   Id of the QAFE event. If null, nothing will happen.
windowId     String   Id of the QAFE window. If null, QAFE will try for a global event with the given id.
appId            String   Id of the QAFE application. If null, nothing will happen.
data              Map      Data needed in the QAFE event. If null, the data in the QAFE event will be null.

Listing 2: JavaScript function to invoke a QAFE event.

Prepare Oracle Forms Application

In the Oracle Form make use of one of the two procedures available within the web Built-in package provided by Oracle to call the previously defined JavaScript function:

  • web.javascript_eval_expr is a procedure which takes two arguments: an expression and a target, both of datatype VARCHAR2. If the target argument is null, then it is executed in the page or frame in which the Forms applet is embedded.
  • web.javascript_eval_function is a function, which takes the same arguments as above, and returns a VARCHAR2 value.

Both web.javascript_eval_expr and web.javascript_eval_function have the same functionality except that web.javascript_eval_expr does not send any return value from the client to the Oracle Form. If your application does not expect a return value, use web.javascript_eval_expr. Then the additional network trip that is required to carry the return value from the client to the Oracle Form is eliminated (see figure 1 below).

Since the return value of the web.javascript_eval_function is a VARCHAR2 some syntax might need to be devised when multiple return values or return values of a different datatype are desired. For example, concatenating multiple values separated by a semicolon.

PL/SQL editor

Figure 1: Oracle Forms statement to execute JavaScript.


A minor disadvantages is that, due to a limitation of Oracle Forms, the return value of web.javascript_eval_function is a VARCHAR2 and some additional parsing is required when passing more complex data back to Oracle Forms.

Being able to integrate Oracle Forms and QAFE provides the option to move gradually from Oracle Forms to QAFE. This has several advantages: start using the resulting web-application as soon as the first Oracle Forms are converted; opt to only convert the most prominent Oracle Forms in your application and remove the bottlenecks in your workflow; convert Oracle Forms to the extend of your budget, with the option to convert the rest later.



Update: Oracle Forms Conversion FAQ

In addition to our extensive general FAQ (containing over fifty answers), we just uploaded an Oracle Forms Conversion FAQ. On this page you find the answers to questions like: How do transactions from Forms work inside QAFE? My Oracle Form has parameterized input, can QAFE do the same? Is there a GUI that can help me migrate my Oracle Forms? And many other FAQs. 
Check it out: Oracle Forms Conversion FAQ.
Don’t hesitate to contact us if you did not find the answer you are looking for. Also, if you DID find the answers needed, and want additional information, simply let us know!