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:
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:
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:
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 firstname.lastname@example.org for clarifications, further explanations or new queries.