Tag Archives: ADF

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.

ADF Checkboxes with custom checked and unchecked values

In this blog post, I’ll talk about how to create custom checked and unchecked values for a checkbox in an Oracle ADF application. My goal is to do this in a purely declarative way for both single and multi record views.

Single record view
For the single record view, I’m using a sample application where you can retrieve store and update student data. See the example in figure 1.


Figure 1: The student application


My goal is to enhance the application by adding a checkbox with a custom checked and unchecked value. The purpose of the checkbox is to define whether a student should be enrolled right away or not.

In JDeveloper, I defined a JSF Page that looks like figure 2.


Figure 2: The student application main screen JSF Page.


Adding and binding a checkbox
Next, we’ll add a checkbox to the Form. With the JSF Page opened in design view, we add a new row, and drag a checkbox to that row. When selecting the newly added checkbox, an arrow appears next to the checkbox selection as seen in Figure 3. Click on it and select the option “Bind to ADF Control”. A window pops up, and we select the ADF Control we want to bind to, “ENROLLNOW” in this case.


Figure 3: Binding the checkbox to a view object.


After clicking on “OK”, the following window pops up:


Figure 4: The binding dialog


Here, we select the values to use in the binding. For “Selected State Value” I enter “Yes” and for unchecked state I enter “No”. This corresponds to the checked and unchecked values in the database. Click on “OK” and the binding should be generated.


Figure 5: The JSF Page after adding the component and binding it.


When you go to code view, the following is generated:


So opening the pagedef, and locating the binding defined with id “STUDENT_ENROLLNOW” we find the following code:Now that the checkbox with binding is properly generated, we can see that the checkbox itself knows nothing of its checked or unchecked value. This is handled in the page definition.


This is all that we need to do to create a checkbox with custom checked and unchecked value in a single record view.The most important part is the ValueList. The first item is the checked state value and the second is the unchecked state value.

Multi record view
The sample application used for multi record view is a simple data grid that shows students. The goal of this part of the blog/tutorial is to add a new column (ENROLLNOW) containing a checkbox for its value. Figure 6 shows the running sample.


Figure 6: Table of students


Adding and binding a column
In the JSF Page, right click the datagrid, in the context menu select “Table” > “Insert Column”. An empty unbound column will be added. Select that column, and click the arrow icon, and in the context menu, select “Bind to ADF Control”. Next, select the column you want to bind to and select “OK”.


Figure 7: Binding the column.


When looking at the source code, the column is displayed using an input text. We now want to change this to be a checkbox. Running the application, we verify that this is indeed a text field.


Figure 8: Running the application with a new column “ENROLLNOW”.


Changing the column to a checkbox
In the JSF Page, we select the column we want to change to a checkbox (it is important to make sure you check the record and not the column header). Select the arrow icon, and in the context menu choose “Convert To” and in the new dialog, select the checkbox, click on “OK”. The “Edit Tree Binding” dialog will show up. Make sure the column in which we want to have checkboxes is available in the “Display Attributes” section and click “OK”.


Figure 9: Edit Tree Binding dialog.


Now the selected column should have a checkbox, but might not have a correct binding. To fix this, select the record below the column we want to bind (again, it is important that you don’t select the entire column or the column header). Click on the arrow icon and select “Bind to ADF Control”. Select the correct data to bind to, and click “OK”. The “Edit Boolean Binding” dialog should show up. Here, just like single record view, we can enter the value for a selected and unselected state value.


Figure 10: Edit binding screen after selecting a value in the “Bind to ADF Control” dialog.


With all the changes in place, the JSF Page should like it does in figure 11.


Figure 11: The datagrid with a checkbox column.


And when running the application:


Figure 12: The application running with the changes.

Page templates in ADF

When building JSF pages for your application, some pages can contain a group of components arranged in a very specific layout, while other pages may use a specific group of components in multiple parts of the page. At times, you may want to share some parts of, or entire pages with other developers. Whatever the case, when something changes in the UI, you have to replicate your changes in many places and pages. Building and maintaining all those pages and making sure that everything is consistent can become increasingly inefficient.

Instead of using individual UI components to build pages, you can use page building blocks to build parts of it, or even entire pages. The building blocks contain commonly used UI components that create the reusable content for use in pages of an application. You can share some building blocks across applications. When modifying the building blocks, the JSF pages using the reusable content are automatically updated as well. Thus, by creating and using reusable content in your application, you can build web user interfaces that are consistent in structure and layout, and an application that is scalable and extensible.

Page Templates
Page Templates are one of the reusable building blocks provided by ADF Faces. By creating page templates, you can create entire page layouts using individual components and page fragments. For example, if you are repeatedly laying out some components in a specific way in multiple JSF pages, consider creating a page template for those pages. When you use the page template to build your pages, you can be sure that the pages are always consistent in structure and layout across the application. You can either create the layout of your template yourself, or you can use one of the many quick layout designs. These predefined layouts automatically insert and configure the correct components required to implement the layout look and behavior you want.

Page Template in QAFE

Figure 1: Page Template in QAFE


QAFE Conversion software: Converting your Forms application to ADF
QAFE offers the possibility to convert your Oracle Forms to a standalone ADF project. During the conversion a sample template file with header (QAFE logo), content and footer (Powered by QAFE) sections is generated. JSF files are inherited from this template, which makes the layout look the same across the application. You are free to change the logo to your company logo or change the footer, in the generated template definition jsf file. See figure 3 for reference.

Page Template as shown in JDeveloper

Figure 2: Page Template as shown in JDeveloper


Figure 3: You can define your own company logo in the templateDef.jsf file


In conclusion
Using Page Templates makes the application layout consistent across the application and makes it much faster and easier to maintain, which in turn saves you a huge amount of time.




QAFE Testimonial – Big Financial Inc.

Big Financial Inc.* was failing to keep up with the market, and specifically some key competitors. Their Oracle Forms application was blocking integration with Oracle middleware products such as SOA suite, BPM and WLS. But while the only option seemed to be a complete rewrite, the company looked for other options as the thought of a redeveloping 400 Oracle Forms would be extremely time consuming and expensive.

Download the client case to see how QAFE helped Big Financial convert up to 70% of its Oracle Forms code to ADF automatically.


*Company name changed due to confidentiality reasons

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

Converting your Oracle Forms application the ADF Alta UI way

There is a good chance your Oracle Forms application is in need of modernization. With modernization comes more than just migrating to new middleware.

Is your 20 year old (or even older) application still suited to the high expectations of the digital age? The likely answer is no. What can you do about it?

The challenge

Your application is well established within the workflow of your business practices, but users/employees are complaining about lack of feature x and y. They want to be able to work with the application on the go, or at least be able to have the application work on newer soft- and hardware.

The Alta UI way

ADF offers the tools to transform your Forms application into a cross-device friendly environment, in which the user experience can be the main focus. More importantly, ADF comes with a set of declarative tools to achieve just that. This is where Alta UI comes in.

The basic principles of Alta UI are to offer declarative, redesigned and modern components to utilize in your application [1]. Alta UI offers the ability to help you with layout and User Interface (UI) components.

However, when modernizing your Forms application you have to take into account how the end user will be interacting with your restyled application. After deciding why, what and how your application will be used you can start deciding what your application will look like.

UI design vs. UX design

When modernizing your application, there is an important difference you have to know about. Namely, the difference between UI design and User Experience (UX) design.

  • UI design makes up the look and feel of your application consisting of things like layout elements, color palette and font. The UI is the style of your application and provides the end user with the first impression.
  • UX design [2] is often confused with UI design, but is much more than just deciding on visual styling. Simply put, UX design decides how the end user interacts with your application.

UX/UI Comparison


When modernizing your Forms application, you want the end user to have a positive experience when using the application. Users should be able to be productive and want to use the application. That captures the essence of UX design.

The questions asked with UX design are often disregarded as time consuming, not important and costly. But ask yourself this; is it worth your time (and thus money) to avoid having the users of your application struggle when using it? Thus causing them to be more productive?

QAFE Conversion software: Converting your Forms application to ADF

Starting from scratch is an option, but these are often drastic and costly measures.

Another option is to migrate your existing application to the Oracle’s Application Development Framework (ADF). QAFE offers the possibility to convert your Oracle Forms to a standalone ADF project. A conversion offers the ability to preserve all functionality of your original application and in addition the flexibility to extend it using ADF.

Currently, the conversion to ADF using the Alta UI design system it is still in an early stage, as we are not yet applying all of the design patterns Alta UI has to offer [3]. We are putting effort into supporting more Alta UI features out-of-the-box so you have a solid base to start building your modernized application upon.


A converted Forms application to ADF utilizing the Alta UI skin.



It’s clear that your Forms application can be modernized using ADF and the Alta UI design system it offers. Before switching over to the Alta UI design system, think about the why, what and how your application will be used. When migrating to ADF not just the style, but also the experience of your application will have to be transformed to todays standards.

If you have any feedback on the usage of Alta UI in general, or tips on how we can improve on the conversion process to ADF utilizing the Alta UI design system, let us know in the comments below!


[1] (February 2015)
[2] (February 2015)
[3]  (February 2015)

ADF Entity Object Merging: The Why and How

When converting one or more Oracle Forms, including multiple Data Blocks representing the same database table, the QAFE conversion service accumulates and aggregates them to a single Oracle ADF Entity Object. This blog discusses the rationale behind this and how it is implemented.

Oracle ADF Entity Objects

Oracle ADF has a Model View Controller (MVC) architecture (1,2). In short; an MVC architecture splits up the responsibilities of an application in three parts: the models, views and controllers. Views are representations of data captured in a model e.g., a table, chart, etc. Models represent data e.g., in the form of domain objects, and update the view. The controllers implement the operations on the data and manipulates the models.

In this blog we focus on the models of ADF called Entity Objects. Specifically, cases where they represent tables in a Database (3). In those cases, The Entity Object attributes represent columns from the corresponding table.

Conversion of Oracle Forms Concepts to Entity Objects

Simply put, in Oracle Forms, Data Blocks represent tables in a database and the Items of a Data Block represent the columns of these tables. Which table a Data Block represents is indicated by the “Query Data Source Name” property of the Data Block. Similarly, which column an Item represents is indicated by the “Column Name” property of the Item.

However, in Forms, multiple Data Blocks could represent the same table (i.e. the item-sets of such Data Blocks could be overlapping subsets of all columns of the table in question). In addition, multiple Forms could have Data Blocks representing the same table.

In an MVC framework, one normally prefers a single model to represent some piece of data (e.g. a database table (3) ). The rationale behind this; a single model representing some piece of code means more maintainable, easier to extend and better readable code.

In retrospect, the QAFE conversion service accumulates all Data Blocks representing the same table and converts them to an aggregate Entity Object that covers all needed columns represented by the accumulated Data Block Items. How the aggregated Entity Objects are created during conversion will be discussed in a subsequent section.

Note: Oracle Forms Data Blocks of multiple Forms, representing the same database table, are only accumulated and aggregated to one Entity Object if all the Forms in question are converted as part of the same batch.

QAFE Entity Object Aggregation Rules

The rules by which the QAFE conversion service aggregates Data Blocks to Entity Objects are described by the following pseudocode:



Figure 1 and Figure 2 show two different Forms. Both have a Data Block representing a database table named HSD_EMPLOYEES, but they represent different columns of that table.

Note that the Data Block name does not equal the table name, which is indicated by the “Query Data Source Name” property. Also note that the Data Block Item name does not equal the column name, which is indicated by the “Column Name” property. However, when the “Column Name” property is absent, the QAFE conversion service will take the Item name to represent the column name.

Figure 3 shows the result of the QAFE conversion service in JDeveloper.  Depicting only one Entity Object that represents the HSD_EMPLOYEES table, named EmpEO. The attributes of this Entity Object represent all columns used in the Forms of Figure 1 and Figure 2.

In conclusion; this example shows that the QAFE conversion service has identified that both Forms use a Data Block referencing a specific database table and aggregated their functionality in a single Entity Object.


Figure 1: Oracle Form HSD0004F with block EMP representing a subset of the columns of table HSD_EMPLOYEES.


Figure 2: Oracle Form HSD0016F with block EMP representing a subset of the columns of table HSD_EMPLOYEES.


Figure 3: Conversion result, shown in JDeveloper, with Entity Object EmpEO having attributes representing all columns of table HSD_EMPLOYEES used in both HSD0004F and HSD0016F.



  1. Wikipedia, Oracle Application Development Framework, 2015-02-16,
  2. Wikipedia, Model-view-cotroller, 2015-02-16,
  3. Oracle, About Oracle ADF Entity Objects, 2015-02-16

Post Conversion Steps ADF – Dynamic dropdown using Record Group View Objects

In this post, I’ll explain how dynamic dropdowns using record groups are converted and how to get a dynamic dropdown working in ADF after conversion. The focus of this blog will be to fill a dropdown dynamically using a record group, which contains a query without any input variables.


This post requires basic knowledge of record groups and dropdowns within Oracle Forms, and a basic knowledge of ADF including UI objects, binding and view objects.

Situation in Oracle Forms

The Oracle Form used in this example consists of a record group and a list item as a dropdown element. The dropdown is filled by a Form trigger “WHEN-NEW-FORM-INSTANCE” at startup. To populate the dropdown, the code below is used. “DROPDOWN” is the name of the dropdown, while “TESTRG” is the name of the record group.

The record group uses a simple query without input variables to find a list of countries with corresponding IDs in the database.



Artifacts Generated

Record groups are converted by the Oracle Forms to ADF converter to View Objects (VO), while retaining the query with minimal changes. The converter manages input parameters, if available. In the example, the query does not contain any input variables. The query is converted to a SQLQuery-attribute and the output columns are converted to viewAttributes. The record group can be found as an XML formatted file “{RecordGroupName}VO.xml”. In this case the file is called “TestrgVO.xml”, see also the code example below.


Post Generation Steps to use a Record Group VO in a dropdown

Make sure that the dropdown component is visible within a JSF Fragment in JDeveloper’s designer mode. Open the Data control in the Data control menu and select a View Object. Drag and drop the object itself onto the dropdown component.

PRO-60-1Dragging a View Object to a dropdown element


Assign the list binding and the display attribute of the dropdown

In the Edit List Binding pop-up, the display attribute has to be set. When clicking on OK, the binding will be added or updated. Press OK to confirm all new bindings. All underlying code including the binding, VO iterator and control elements are automatically generated. The final step is to start the application. The dropdown is now filled automatically, based on the data in the VO.

PRO-60-3Rebinding of the components


Dropdown has a successful binding to the view object.

See the result below for a dynamically populated dropdown! An example using a record group with input parameters will be the subject of a future blog.



Running application with a filled dropdown.

Declaratively set Custom Properties on View Objects

Casus: A Forms to ADF conversion with post query triggers enabled.

The QAFE Oracle Forms ADF Exporter tool implements custom properties using the declarative XML language. A declarative language, generally, describes what the program should do as opposed to how the program should do it. This property has several advantages like maintainability, reusability, smaller programs and it’s easy to use.

In ADF, you want to have as much code as possible defined in a declarative way. This way, upgrading JDeveloper and ADF happens seamlessly. This would be less straightforward if using native Java. Additionally, when using Oracle JDeveloper Studio (12.1.3), its possible to manipulate the custom properties using its graphical user interface.

For example, if you would like post query triggers from their Oracle Form, see Figure 1 and 3, to be available after conversion, you could check “Enable Post query” at the configuration page when executing the conversion wizard, see Figure 3.

Figure 1: A Forms Builder Object Navigator showing post query triggers.
Figure 2: A Forms Builder PL/SQL Editor showing the post query implementation.
Figure 3: Forms to ADF conversion configuration with post query triggers enabled.

When the conversion is finished, the PL/SQL code pertaining to the post query triggers is available as part of a PL/SQL package that should be made available in the database, i.e., the script must be run on the database, see Figure 4.

Subsequently, when the newly converted ADF project is opened in Oracle JDeveloper Studio you could open a View Object and find their post query triggers under the “Custom Properties” section, see Figure 5.

Figure 4: Generated PL/SQL after conversion, pertaining to the post query trigger.
Figure 5: A JDeveloper Studio view showing custom properties.

This approach makes it easy for developers to use the logic in ADF and start planning how to possibly rewrite this logic in native ADF (like a Groovy mechanism).

QAFE Forms Conversion 1.9.0

We’ve just released QAFE Forms Conversion version 1.9.

This release contains stability improvements and bugfixes. Below is the list with the most important changes.

  • Overall database script improvements to reduce manual work after conversion
  • Proper trigger scripts handling
  • Handling of Forms Built-ins
  • If an FMB uses another FMB as parent, this is now automatically processed
  • Wizard overview to show how conversion credits are spent
  • Downloadable Analytics reports
  • QAFE Forms
  • Generic scalable LOV handling and output (simple and with input parameters)


  • Improvements made on tabpanels rendering
  • LOV handling in ADF out-of-the-box (simple and with input parameters)

Additionally, we’re working on documentation to tackle possible manual work for Forms Conversion.

This release is available now and can be used with the QAML Builder. Download and install the software from here.

For any questions or remarks, don’t hesitate to contact our support team at and stay tuned for our next update!