0873-0875

Previous Table of Contents Next

Page 873

menus , object groups, parameters, program units, property classes, and visual attributes. A menu is defined as a list of options that can reference other submenus or perform tasks such as executing commands or processing Forms functions.

You start the initial menu module by creating a menu called MAIN_MENU. To edit the main menu, double-click the menu icon and the menu editor appears, as shown in Figure 35.23. The initial menu contains one item called <New Item>, which you can customize by double-clicking the item and defining its properties in the property sheet. Important properties to note for the item are Item Type, Command Type, and Command Text.

Figure 35.23.
Menu editor.

Item types are Plain, Check, Radio, Separator, and Magic. Most items that you define for navigation are the Plain type. You use a Check item to set a user option from the menu, and you use a Radio type item to select an option from a list of valid options. A Separator item is used to draw a horizontal line in a drop-down menu. Finally, a Magic item performs a default Forms function defined by the Magic item property.

The command types are Null, Menu, PL/SQL, Plus, Form, and Macro. The Null command performs no function when the menu item is selected and a menu item presents a new submenu. You use a PL/SQL command type to execute a PL/SQL program block. Plus and Form are used to invoke SQL*Plus and Oracle Forms.

When you define a set of menus, you can create applications that can be navigated through the use of the various menu items. Figure 35.24 shows a File menu as it is constructed with
separators between the logical menu areas giving a similar appearance to many Windows 3.1 applications.

Figure 35.24.
Sample File menu.

Page 874

Libraries, Object Classes, and Visual Attributes

One of the major features of object-oriented programming environments is the concept of reusability. By creating reusable objects, you can enforce standards globally and develop applications at an unprecedented pace. Users are more comfortable with an application that appears and operates uniformly. Several objects were included in Oracle Forms to provide this reusability.

As discussed, libraries are repositories of reusable PL/SQL program units. To work with a library, create the library in the Object Navigator as you do a form. A library can attach other libraries and can contain PL/SQL program units. To use these program units in other forms, attach the library to the form and reference the procedures and functions as if they were part of the form itself. If you make changes to the library, you must regenerate each form that uses the library to reflect the change.

Visual attributes, on the other hand, are defined as part of the form itself. A visual attribute defines the font characteristics and the colors for the object. A special visual attribute called Default exists for every form based on the value of the FORMS45_DEFAULTFONT parameter in the oracle.ini file in your system. You can design visual attributes to define meaning for the item. For example, a financial application can show negative values in red or you might use special characteristics to indicate errors or statistical extremes. Another valuable use of a visual attribute is to indicate the current record selected. The current-record attribute is available at either the block or form level and is often used in multi-row applications. Finally, you can change the visual attribute for an instance of an item dynamically at runtime using the DISPLAY_ITEM built-in procedure.

The last feature that provides reusability within a form is a property class. A property class takes the functionality presented by the visual attribute and expands it further by defining all the properties for a class of objects. This allows you to define a set of valid property classes and to use these properties throughout the application without defining each individual property for every object.

Quality Considerations for Oracle Forms

Oracle Forms can handle a vast array of database processing functions. As with any powerful tool, you have many ways to accomplish the same task. It is the job of the developer to create applications that deliver the highest quality return for the lowest overall cost. Quality in an Oracle system can be classified according to several key attributes:

• Reliability: The system must deliver accurate and dependable results.
• Performance: The system must deliver the results quickly.
• Features: The system must deliver the functionality needed.
• Durability: The system must sustain growth.

  Page 875

  • Serviceability: The system must be easily modified.
  • Conformance: The system must adhere to standards.
  • Aesthetics: The system must look good doing all the preceding tasks.

  Oracle Forms provides many tools to ensure the quality of an Oracle application. Triggers provide the constructs necessary to ensure the reliability of a form in adhering to business rules as they are established. By coupling these concepts with database triggers and procedures, the system development process can enforce conformance to all the business rules. In addition, program unit libraries and reference forms with defined object classes and visual attributes can assist you in delivering a reliable system that conforms to the standard presentation format that is established for the organization. These components also make a system easier to modify to reflect changes in rules or newly desired interfaces.

  Such modifications are inevitable in practically every Oracle database application, and if you use object-oriented principles from the beginning, changes are easier to make in the future.

  The final concept that is absolutely key in the development of Oracle applications is performance. Unfortunately, in many cases, performance is an afterthought in application development. Many systems actually end up in production without any performance tuning. At best, most applications receive only minimal tuning effort. This is not completely the fault of the developer, although the developer should be most concerned with the performance of the system. After all, whenever a system performs poorly, the finger of blame usually points to the developer.

  What can you do to ensure optimum performance? The answer, in a word, is testing. You should check each SQL statement executed in the form for optimized code. To see what SQL statements are run for a form, run the form with the STATISTICS mode on. This creates a trace file in the Oracle home directory. (Your DBA should be able to help you find this directory.) You should then translate the trace file using the TKPROF utility (Oracle's performance tuning utility) as follows :

   TKPROF tracefile listfile EXPLAIN=username/password 

  This utility describes the access path for every SQL statement executed in the form. Look at the execution plans to make sure that every table access uses an index where desired and that full table scans are minimized. Generally, when using multiple table views in a query, the result should be minimized as quickly as possible. Therefore, make sure that the indexes that return the fewest result rows are used earliest. Second, a full table scan is not always a bad thing in a query, especially when most of the blocks in a table must be accessed anyway. Tuning individual statements will come with practice, and many times, even a seasoned veteran can find the optimum query through trial and error.

  Besides making sure that each SQL statement is efficient, there are several other "rules" that you can follow when building a form, especially in a client/server environment. Some of these include the following:

  Previous Table of Contents Next