This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Oracle Forms Builder is part of the Oracle 10g Developer Suite which also includes Oracle Reports Developer, Oracle JDeveloper, Business Component for Java, SQL*Plus, Oracle Designer, Oracle Discoverer and Oracle Software Configuration Manager. All these components allow to build portable applications for various operating system, applications for multilingual support as well as applications that can be monitored remotely. In addition, Oracle Forms applications manage complex data structures and DML functionality automatically without the need for additional SQL for each transaction.
Oracle Forms Builder is an Integrated Development Environment (IDE) intended for Rapid Application Development (RAD) using PL/SQL as well as Java. Applications created in the Forms Builder are deployed as a Java Applet integrated into an Internet browser.
For testing the applications (local use), a light-weight HTTP listener called Oracle Containers For Java (OC4J) and Java engine included with the Forms Builder. For deployment environment however, Oracle Application Server is required providing access via remote clients.
Microsoft Access â€¦
All Oracle Forms 10g applications are run on the Web via a browser and no longer support a client-server implementation, which in the past require a run-time engine to be available from each client machine. When the a form is run for the first time, a thin Java applet that handles the display of the Oracle form in the browser is downloaded and cached on the client machine.
Oracle Forms Builder contains a variety of tools useful for application development including Object Navigator, Layout, Menu and PL/SQL Editors, Property and Syntax Palettes as well as Layout, Data Block and LOV Wizards.
The Layout Editor, Property Palette, and Object Navigator are linked together and changes made in one of them are automatically displayed in the other two tools.
An application built in Forms Builder consists of individual application components called modules. There are four types of modules in Form Builder:
This type of module contains definition for form objects such as windows, text items, check boxes, buttons, alerts, triggers and list of values objects and their code routines. This is the only module type I have used in this project.
This module can be used to define menu and submenu objects together with the menu item commands.
PL/SQL Library module
Module to define user named procedures, functions and packages that can be called from other modules in the application as well as
Object Library module
Module for storing objects that can be used to develop the application.
Object Navigator displays objects in a hierarchical way and groups them into nodes based on type as follows:
In addition to the four mentioned modules, Object Navigator also displays:
This is a collection of Oracle supplied procedures and functions.
When the connection to the database is made, this section displays various database objects.
Object Navigator allows viewing items in the following three convenient ways:
Ownership View: Objects are grouped by type
Visual View: Objects are shown organized by containers so that canvases are contained in windows, and items are shown in canvases, etc.
PL/SQL Only: Only objects with associated PL/SQL code are displayed in either view.
Every form contains at least one window, one canvas, one data block and one item. Canvases and windows are the layer components of Forms that the user sees when the form is run whilst blocks connect the displayed items on the screen to the database.
Every Forms application is displayed within a master window called Multiple Document Interface (MDI). All other windows display inside this container.
There are two types of windows within Oracle Forms: document window in which the forms are displayed and a pop-up dialog window, which is independent of the MDI window. Dialog windows in addition have additional modal property, A non-modal window allows the user to switch between two open windows, whilst modal window must be explicitly closed before the user can carry on work on another window.
A window is a "frame" through which a canvas is seen.
The canvas is used to display items on the screen. Items can be presented logically by arranging them on one or more canvases. There are several types of canvases:
Content Canvas: completely fill the window it's in
Stacked Canvas: can be layered on top of the content canvas, it is used to hide part of the content canvas or display alternate data therefore it is usually smaller then the window. Stacked canvas can be displayed programmatically.
Tabbed Canvas: type of stacked canvas that has multiple pages identified by tabs. The data is grouped logically into different pages.
Toolbar Canvas: canvas for custom button bars used as a replacement for the default "smartbar" toolbar.
As mentioned, blocks connect the form items to the database. A data block is not actually seen, only the items that it contains are displayed on the canvas.
The data source for the block can vary from single database table, multiple tables as well as values returned from a PL/SQL Package. When a block is associated win a table in the database, Oracle Forms handles the standard DML functions (select, insert, update and delete) automatically without having to write additional code. The standard DML can be overridden when a block is based on PL/SQL code.
A type of block not connected to a database called Control Block can also be created, which can be used to hold reference and working variable values.
A form can have unlimited number of blocks, however it should be split up into smaller forms it contains more than 10 blocks. Blocks can be displayed on the screen either in form layout (as a single-record) or in tabular layout (multiple records per screen).
The Object Navigator can be used to arrange the data blocks and items for run-time navigation. By default the cursor goes to the first item in the first data block on the form and then moves through each item and block on that form. The navigation can also be coded programmatically.
In addition, when the last item in a record is reached, the cursor can return to the first item in the same record, move to the next record or the next block in the form.
In addition, Oracle Forms also manages the concept of parent-child relationship. A master block can be created using a wizard that will allow to set up a relationship with the detail block automatically. This can be achieved without the foreign-key relationship between tables present in the database.
Data items can only be created within a block. They can represent a column in the table or view or display a calculated value, reference value from a Control Block or a value returned by a PL/SQL package.
Text Item: allow the user to interact with the data in the form filed.
Display Item: similar to text item but the user cannot update the data displayed.
Check Box: used when there are 2 choices for a field e.g. Yes/No, On/Off.
Radio Group: used when there are 2 to 6 values to choose from and the user must select one value. Radio Group is the container, which is bound to the database item and contains radio buttons. The buttons have associated values that are inserted into the database.
List Box: also called drop-down box displays a list of valid values to the user. Only one value can be selected. Each list box must have a list of values associated with it either hard-coded or attached from a Record Group. There are 3 types of list boxes: Pop-List, which displays a single value that can be expanded to show the rest of the list, T-List , which displays all the values and Combo-Box, which behave like a Pop-List but allow the user to add a value that is not in the database and save it.
Buttons: designed to perform an action when pressed. They are not bound to the database.
Record Groups: internal data structures that behave like tables in memory. Used to drive other interface items such as List Boxes and List Of Values (LOV). Can be based on a list of static values or on queries.
List Of Values: based on a Record Group, displays a pop-up listing of available values for a given field. It can be used to populate as many fields on screen as needed based on the columns selected in the Record Group.
A basic form allows working visually with the data in the database. The Layout Editor is a graphical tool for working with the visual elements of a form. Each item on the form has a number of properties including information about its location on the form, size, colour and font. These properties can be adjusted using Property Palette or Layout Editor.
The Layout Editor has the following two toolbars:
The toolbar on the left contains buttons for creating interface items such as buttons, check boxes, text items, graphic objects and frames that can be used for auto-layout. It also has buttons for creating tab and stacked canvas on top of current canvas as well as adjusting the background/fill, text and line colours. There are also buttons that allow rotating, zooming or reshaping items.
The toolbar across the top of the Layout Editor contains buttons for setting font attributes, object alignment, zooming in and out and to change the layout order.
By moving the mouse over each button, a tooltip is displayed describing the function of each button.
When an item is created either manually or using a wizard, its properties are set to default values. These values can then be changed if required. The Property Palette is used to display and adjust the appearance and behaviour properties of the items and the form. As mentioned, these properties can also be adjusted programmatically as well as using the Layout Editor.
When creating a form, wizards can speed up the development by providing default behaviour and layouts. Oracle Forms provides the following wizards
Data Block Wizard
A data block can be based on a table, view or a stored procedure. The wizard also allows to select objects owned by the current database user or other users. It then displays the available tables, views or synonyms. When the selection is made, the available columns, which can be added to the data block, are also displayed. The block can then be saved.
This wizard is used to arrange the items in the block on a canvas. It automatically creates a default content canvas and a window for displaying the items. The items from the previous data block wizard are displayed allowing to change the title and size of available columns. It also allows to select the frame properties including the type of layout, how many records are displayed at a time and if a scrollbar should be displayed.
List of Values wizard allows to select and modify an existing Record Group or create a new one. Available columns are added to the new LOV and the column name, size and width can be adjusted. The LOV can then be attached to the required item on the form.
As mentioned, the DML functions are automatically handled by Oracle Forms. In addition, PL/SQL code is added to respond to user actions or events generated by the form.
There are 4 types of events on a form:
Interface events generated by the user's interaction with the form
Keyboard events generated by the user pressing a function key
Internal processing events
User defined events
Every predefined event in the form has a specific trigger associated with it. Triggers allow to add functionality or replace default behaviour.
Triggers replace the default behaviour and replace or add custom logic to the form. They are executed in response to the events in the form.
The level at which a trigger is defined determines its scope e.g. item level, block level etc. Some triggers can only be defined at one level, some at multiple levels. By default, Forms executes the trigger at the lowest level first. If there is no trigger at the item level, Forms will look at the block level, then the form level. Onlly one trigger of each type can fire by default, this can be changed by setting the Execution Hierarchy property for the trigger, which can have the following values:
Override: default, fires the lowest level trigger fires, this is the expected behaviour of Forms, rarely change
Before: the current trigger will fire before firing the same trigger at the next higher scope
After: fires the current trigger after it fires the trigger at the next higher scope
Triggers are written using standard PL/SQL syntax. They can reference forms objects, built-ins and all PL/SQL syntax and DML statements are always allowed in triggers. Trigger can refer to Forms objects by name or ID, system variables, database packages, procedures and functions.
Triggers can be divided into the following categories:
Block processing triggers: in response to events related to record management in a block such as creating a new record (When-Create-Record), deleting a record (When-Remove-Record) or clearing a block (When-Clear-Block).
Interface event triggers: in response to events that occur in the form interface as a result of user interaction for example When-Button-Pressed, When-Checkbox-Changed, When-List-Changed, When-Radio-Changed, When-Window-Activated, When-Window-Closed etc.
Navigational triggers: fire as Forms navigates internally through different levels of the object hierarchy in response to user interaction or to internal navigation such as Pre-Form, Pre-Block, Pre-Record, Pre-Text-item, Post-Text-Item, Post-Record, Post-Block, Post-Form.
Transactional triggers: fire in response to events that occur as a form interacts with the database to replace the default processing such as On-Delete, On-Insert, On-Update, On-Select, Pre-Commit, Pre-Delete, Pre-Update, Pre-Insert, Pre-Select and Pre-Logon.
Validation triggers: fire when Forms validates data in an item (When-Validate-Item) or a record (When-Validate-Record) in response to user input, programmatic control or by default processing such as commit
Query-time triggers : Pre-Query trigger fire just before the execution of a query and validates the current query criteria or provides additional query criteria programmatically. Post-Query trigger fires after the execution of a query, used to enhance the values returned from a query or to populate control items or items in other blocks.
Message-handling triggers: fire when errors or messages are presented by the form.
Master-detail triggers: fire when navigating between the parent and child data blocks to keep all related information coordinated.
Key triggers: fire in response to pressing a function key or a combination of function keys that result in specific logical function e.g. to execute a query. Key triggers change the default behaviour of a function key.
Built-ins are functions or procedures that allow PL/SQL code to interact with Forms objects in PL/SQL. They extend PL/SQL with form-specific functionality. Each Key Trigger has an associated built-in function, e.g.:
Function Key Trigger Built-In
Clearing the block: Key-clrblk CLEAR_BLOCK
Navigate to the next item: Key-next-item NEXT_ITEM
Creating a new record: Key-crerec CREATE_RECORD
Committing a record Key-commit COMMIT_FORM
Execute query: Key-exeqry EXECUTE_QUERY
Built-ins that could result in an application error should be explicitly tested using forms_failure, form_fatal or form_success. It is not necessary to test all built-ins for success but any built-in that performs navigation should be tested if there is a chance that the failure would disrupt the form.
The PL/SQL Editor allows to enter code for adding above functionality as well as to compile code objects such as event triggers, subprograms (functions and procedures), menu item commands, menu startup code, and packages.
Enter Query mode
These variables keep track of run-time information and allow access to information about the application and the status of the forms such as mode, current form, date and time, form, block and record status, cursor block, record, item and value, mouse position, mouse button pressed, last record and query, trigger information, message level and many more.
Development standards for layouts, use and behaviour of GUI elements for common look and feel, avoids duplication of work - reusable components, easy maintenance, avoids errors, easier to implement design changes
Visual Attribute Groups (VAG)
VAGs are user defined sets of properties that control the appearance of an object by defining properties for fonts, colours and patters. They are a "shortcut" to apply properties to an item without updating each property individually. Changing a property in the VAG automatically propagates the change to each item that references that VAG.
VAGs are created in the Object Navigator under Visual Attributes node. They do not have physical representation but are used by other objects.
An example of using a VAG is in a multiple record block, which has the current row highlighted so tha the user can easily identify what data item they are working with. This is accomplished by creating a VAG with the font and colour properties for the highlighted row and assigning the VAG tot eh Current Record Visual Attribute Group property for the block or assigned to each individual item.
VAGs allow to set properties for colours, fonts and patterns. In addition, to define templates for non-visual attributes, Property Classes are used.
Property Classes control size, location and behaviour of objects, these multiple properties and their values are assembled into groups and groups assigned to various form objects.
Properties can be added and removed from the Property Class property sheet and have a value assigned to them. Objects that have properties assigned to them in this way are called subclassed items.
As with VAGs, if the properties of the Property Class are changed, the new values are propagated to all the subclassed items.
Having VAGs and Property Classes set up in each form still means that you would have to change each form to implement a system-wide change. Putting these items in an Object Group means that they can be shared.
Object group is a container for a group of objects. It's a simple way of bundling together related objects so they can be used by another module. Adding or removing any object from the object group automatically updates any form that includes the object group.
For example window, canvas, blocks, items and triggers containing the required logic for scheduling appointments in a calendar can be packaged in an object group and then easily copied to other forms in one simple operation.
Items are added to Object Groups in the Object Navigator by dragging and dropping the object you want to include. The Object Group is then referenced in each form.
Set of standards that you create and make available to the entire development team. They are not part of the application itself but provide a common library of reusable items. Use of sub-classing - changes made to the objects in the object library are propagated throughout all applications that use them. Preferred mechanism for standardising the applications.
Object Libraries can be updated and the changes immediately are available to the development team. You can associate multiple Object Libraries with an application. For example, you may have a generic library that contains corporate-wide standards, and a smaller library for project-specific items.
Object Library is used to create, maintain and distribute standard reusable objects and allows to create applications using predefined objects that can be dropped into a form and enforce standards for the look and feel and behaviour in an application.
Any Forms object can be stored in an Object Library, except for a form itself. When a library is created in the Object Navigator and items are dragged and dropped into it, they become available to Forms Builder. The objects can be then dragged from the Library onto the destination form. This object can then be independent of the library or linked to the master in the Object Group.
A Smart Class is a type of object, which acts as a template to create objects with the same properties, or to apply the properties to an existing object. An object based on a Smart Class inherits its functionality and appearance from it. Nearly every type of object in a form can have a Smart Class.
Smart Classes can be used to easily distribute design standards by creating SmartClass objects for each type of item in your application and distributing these SmartClasses within an object library to the development team.
Shared PL/SQL Code
One of the most important ways to speed development and reuse Oracle Forms 10g components is to share the code that is written in triggers. You can do this by using Program Units, PL/SQL Libraries, and by referencing PL/SQL code in the database.
Program Units provide means of writing PL/SQL code that can be called from multiple triggers. They contain code that is local to the form and may contain packages, procedures and functions and can reference forms, system and global objects. By putting Program Units into PL/SQL Libraries they can be shared across multiple forms.
PL/SQL Libraries are collections of packages, procedures, and functions that are deployed as separate modules in the application. They can reference forms, system and global objects. Because they are outside of the form scope, they must use special built-ins to reference the objects within a form indirectly. A PL/SQL Library is deployed as an executable file.
Finally, Forms can reference any code in the database. However, PL/SQL code in the database cannot reference forms items because the PL/SQL engine in the database does not understand the Forms built-ins.
Templates provide default starting point for new forms including generic objects such as corporate graphics, toolbars, program units, standard window layouts, toolbars, menus. Any form can be used as a template form.
Forms collaborative development
The aim is to develop a user interface in each database type and to critically compare the two different development environments you have used.
Excellent critique on the two environments covering all aspects of development
Oracle Forms 10g is a powerful development environment that integrates with Oracle database seamlessly.