Building Forms

This chapter is designed to give a short introduction to the Oracle Forms 10 g toolset and the basic components of a forms application. Chapter 11 will discuss incorporating Oracle Forms into Oracle Application Server Portal. This chapter will cover the following topics:

• Basic Forms concepts

• Form elements

• The Object Navigator

• Wizards

• Built-ins

• Triggers

• Object Groups and Libraries

Basic Forms Concepts

A form simply allows you to work visually with the data in the database. It is a representation of the data in the database tables, a collection of objects that yields a graphic interface to the data.

Every form, no matter how simple, contains the following pieces:

• At least one block

• At least one item

• At least one canvas

• At least one window

Most Oracle Forms 10 g have multiples of each of these objects, but the basics are the same, no matter how simple or complex the form.

In addition to the basic objects in a form, the toolkit supports a wide variety of widgets and interface items to build the user experience: buttons , toolbars , check boxes, radio buttons, even Java-bean controls. PL/SQL code behind these objects (and in the database) controls validation and behavior in the form.

All of these items are created using the Form Builder.

Data Blocks

Blocks are the form elements that connect the displayed items on the screen to the database. The block itself is never seen when a form is running; only the items that it contains are displayed on the canvas (Figure 3-1).

Figure 3-1: A graphical description of database tables and Oracle Forms 10g canvases

Blocks can be based on single database tables, multiple tables (via a view), and even the returned values from a PL/SQL package. Blocks can also be created that are not connected to (not bound) to the database at all. These are commonly called Control Blocks or non-base table blocks (NBTs). Control Blocks can be used to hold working variables , reference values, or any other data that is used or displayed within the Form.

When a block is associated with tables in the database, Oracle Forms 10 g handles the standard DML functions automatically. Select, Insert, Update, and Delete are supported for these blocks without having to write additional code. When the block is based on a view, limited ability to perform DML is supported (based on the rules for updatable views).

When the block is based on PL/SQL code, or when you want to perform nonstandard functions when the user attempts to update or delete items in the form, then PL/SQL code can be written to perform the desired action and override the standard DML functions. For example, if a user deletes a record on screen, but the system requires that items never be deleted (they must be marked inactive instead), then the delete function can be replaced by PL/SQL code to set the appropriate flags invisibly to the user. For the standard behavior, however, no code is required. Oracle Forms 10 g handles the interaction automatically.

Tip  

A form can have an unlimited number of blocks, but a logical limit is ten. If you have more than ten blocks, you should consider breaking the form up into smaller modules.

Items and Data Items

Items are the form elements that connect the form to a column in the database table (or, as noted in the preceding section, Data Blocks, a returned value from PL/SQL). Items can only be created within blocks. They are the pieces of a block that are seen when the form is running. The items may be bound to the database, in which case they represent a column in the table or view being bound, or a value returned by a PL/SQL package. Or, the item may be a calculated value or reference value from a Control Block.

Cursor Navigation

Cursor navigation at run time is controlled by the orientation of the data blocks and items set at design time in the Object Navigator. By default, the cursor goes to the first item on the first block of the form, and then moves through each block and item in the form. By rearranging the data blocks and items, the navigation sequence at run time can be controlled.

There are other ways to control navigation: programmatically or by hard-coding the sequence of items. It is always preferable to use the physical ordering of item and blocks to control navigation.

Finally, you can specify what behavior should occur when you reach the last item in a record. The cursor can return to the first item in the same record, can move to the next record, or can move to the next block in the form.

Single-Record and MultiRecord Blocks

Blocks can be displayed on the canvas either as a single-record-per-screen (form layout), or with multiple records displayed (tabular format). Which layout you use depends on the kind of data displayed and the functionality of the forms. For example, maintaining a list of codes is more easily done when the data is displayed in multiple rows, spreadsheet-fashion. Working with customer data, on the other hand, may require showing more details, and a forms-type layout is more readable.

Master-Detail Relationships

Oracle Forms 10 g easily manages the concept of parent-child relationships between blocks. A parent-child (or Master-Detail) relationship between tables in the database, such as a customer having many locations, or an order having many lines, is usually represented by foreign-key relationships between the tables. However, a master detail relationship does not require that this database relationship exist.

Within Oracle Forms 10 g , the relationship between the master and detail blocks ensures that the detail block displays only those records that are associated with the current master record, and coordinates querying, data entry, and deletion between the blocks. The detail block must be created after the master block is created (the easiest way to do this is to use the wizard, which will allow you to set up the relationship automatically). An important component of the relationship is how the blocks remain coordinated. Forms can either automatically query the detail information every time the master record is viewed , or querying the detail blocks can be deferred until they are needed and then they re either automatically queried on first use, or manually queried via code.

By far the most common master-detail relationship is one parent and one child. For example, an order header and order lines. One parent and many children is common for informational forms, such as customer information which has various subtables of information such as addresses, shipping and billing information, and contacts.

It is uncommon to have one child record belong to more than one parent record. This situation requires that you manipulate the auto-generated triggers for master-detail relationships.

Canvases, Windows , and Views

Canvases, windows, and views are the components of Forms that the user sees when the form is run; each is a different layer in the display of the form on screen (Figure 3-2). The canvas is the object on which the GUI is drawn, the background of the form. All the other visible objects in the form are drawn on the canvas. The window is the frame through which the canvas is seen. The View is the object that controls how much of the canvas can be seen at any given time.

Figure 3-2: A graphical representation of windows, views, canvases, and items

The canvas can be any size (within reason), while the window controls the ultimate size of the interface. It controls how much of the canvas can be seen at any one time. If the canvas is larger than the window, then only what can fit into the window will be visible.

In Figure 3-2, the canvas is twice as wide as the window, so only about half of the canvas can be seen at one time. The window itself is fairly large, but the view port in it is just large enough to view the items on the canvas and cover the remaining items. The canvas could be scrolled to display the remaining half and the items on it within the confines of the view port.

In many cases, the window, canvas, and view are the same size.

Windows

When a Forms application is displayed, it is enclosed in a master window, called the Multiple Document Interface (MDI) window. This is the outer container window for the application; other windows will open within the MDI.

There are two types of windows within Forms: a document window and a dialog window. The document window is the standard window of an application, while a dialog window is a pop-up window that is independent of the application and can be moved outside of the MDI window.

Dialog windows have an additional property that controls their behavior. The modal property determines if the dialog window has a synchronous or an asynchronous display. A modal window must be explicitly dismissed before the user can return to another window. A nonmodal window allows the user to switch back and forth between open windows. Error messaging and confirmation dialog windows are usually modal windows: processing stops until the user acknowledges the message.

An application may have a single window into which all canvases are displayed, or it may have multiple windows. Some forms display each canvas in the same window, while others display each canvas in its own window and have multiple popup displays of different sizes. There is no practical limit to the number of windows in a form. In practice, however, there are rarely more than five to ten.

Canvases

Canvases are the Form components that are used to display items on the screen. By arranging items on one or more canvases, they can be presented logically to the user. There are several types of canvases that can be displayed within the windows of the Form. These include Content, Stacked , Tabbed, and Toolbar canvases.

Content Canvas

A Content canvas is the background of the window. It is a type of canvas that completely fills the window that it is in. If the canvas is larger than the window, it is cropped; if the canvas is smaller than the window, Forms will fill in the extra space with the specified background color . Since a content canvas completely fills the window, only one content canvas can be seen at any time. If the form navigates to an item on a different canvas, then that new content canvas replaces the currently displayed canvas.

If the canvas is larger than the window/view in which it is displayed, scrollbars can be added to the window to display all the items. Good design principles, however, suggest that you do not scroll more than two window-widths in any direction, and do not allow scrolling both horizontally and vertically in one form.

Stacked Canvas

A stacked canvas can be layered on top of a content canvas, and is used to hide part of the content canvas or display alternate data. For example, a form designed to display customer information may display the common customer information at the top of the canvas and allow either financial data, order data, or contact information to be displayed on the bottom half of the window. Each set of data is arranged on a stacked canvas that is displayed in the same position. When the user wants to see order data, the stacked canvas with order data is brought to the top.

In most cases, the size of a stacked canvas is smaller than the window it is displayed in, because the stacked canvases are used to cover up only part of the content canvas in the window. If it is not smaller than the existing canvas, then the stacked canvas will completely obscure the content canvas, which defeats the purpose of having an alternate view.

Stacked canvases can be displayed and hidden programmatically. They are also displayed automatically when the user navigates to an item on the canvas. A stacked canvas will remain in view until it is explicitly dismissed or replaced by another canvas.

A common error that can occur is that stacked canvases can disappear at inopportune times. This is usually related to the automatic re-ordering that Forms uses to display the active item. In this case, something that has to be displayed in order to show the active item has overlapped the stacked canvas and caused it to be pushed farther down in the stack of displayed canvases.

Tabbed Canvas

Tabbed canvases are a specialized type of stacked canvas that has multiple pages of information identified by folder-like tabs across the top or side of the display. Each tab page can contain different data, which is easily accessed by clicking the identifying tab.

Tabbed canvases are two-part objects: the Tab Canvas itself is the container, which contains multiple Tab Pages. Remember that Forms insists that the active item is displayed at all times. This can cause confusion when working with Tabbed canvasses. Because Forms considers the Tab Canvas itself as the display canvas, not the individual pages, it is possible to have a Tab Page displayed that does not contain the current item. As long as the Tab Canvas is displayed, Forms is satisfied.

Toolbar Canvas

Finally, Forms has a special type of canvas for custom button bars. Forms has a default smartbar toolbar that is included in each Form to provide the standard functionality for cut and paste, save, etc., and can be seen in Figure 3-3. If you need a custom toolbar, this type of canvas can be used as a replacement.

Figure 3-3: Displaying a simple form in a web browser

Like windows, there is no practical limit to the number of canvases in a form. However, a logical limit is 10-15 canvases. If the form is complex enough to require more canvases to display data, the Form should probably be broken up into multiple smaller forms.

Behavior

When a form is displayed in the browser window, the active item ”that is, the item with focus ”must be displayed. Using the order of blocks and items, Forms determines which item should be the starting place in the form. Forms will do whatever is necessary to display that item within the open view port on screen. If the item is not in the current view, then the Form will manipulate the layers of display to ensure that the item can be seen. When the user (or internal code) navigates to another item, that item will then be brought into the view port if it is not already visible.