Forms 6i Object-Based Features
Peter Koletzke, Quovera
Objects in Mirror are Closer Than They Appear
This warning—printed on automobile mirrors—is particularly appropriate to the development world. If you are not thinking about objects today, you surely see them looming in your rear-view mirror. Your use of object technology is closer than you think. You will use it soon as the industry trend towards object-oriented analysis, design, and programming continues.
The popularity of object orientation (OO) is due to its potential benefits. If object orientation is correctly implemented in any aspect of system development, there is a measurable gain in the areas of standards creation, use, and enforcement. Analysis and design is easier because business objects are more closely related to programming objects in the OO world. The distinction between physical and logical modeling is no longer as strong with object orientation because the universe is filled with things that are more closely related to objects than to relational tables and entities. Complex, easily maintainable, and quickly upgradeable designs are all possible because of the extensibility that OO provides.
On the development side, the long-touted but never fully realized benefits of reuse become a reality when the development team employs object-oriented environments and techniques. Common libraries of generic code and master objects that have true inheritance afford central maintenance for business-related programming components. This yields greater consistency among applications in the enterprise. With proper knowledge of the contents of the libraries, developers can be much more productive and create applications faster than without inheritance and generic code.
The biggest downside to the use of OO is the learning curve that comes with the shift in environments. Developers need to think in an object oriented way—that is, "Everything is an object." The ramifications of that simple statement are widespread and not fully realized until you actually dive into coding. This way of thinking is very different from the thinking in "traditional" language. You need to consider that all new code you write has the potential to be shared. While this is no different from writing shared code in other environments, such as those that use the PL/SQL language, when object-orientation is a goal, the code must be more rigorously tested for all possible uses if it is to be a true master object. The same consideration applies to non-code objects such as visual classes. In addition, developers must be fully aware of the master objects classes that the environment offers so they do not reinvent an existing object. Developers must also know the features, the interfaces, and how to best use the objects in the development libraries. There is no easy answer to this other than training and close contact with someone on the team who has the required knowledge.
Object-Orientation in Forms?
As technologists who use Forms (currently called “Oracle Forms Developer”), we would like to be able to take advantage of object orientation. However, Forms Developer was not architected as a true object-oriented environment. It does, however, contain certain aspects of an object-oriented language such as Smalltalk or Java. You can base your use of Forms on aspects of the tool that support the benefits of objects. Therefore, the term "object-based" accurately describes a style of development that you can follow to exploit object concepts in Forms. The main aspects of Forms that support object concepts are the following:
· Code Libraries
· Subclasses
· Object Groups
· Object Libraries
· Templates
Each of these features will be discussed in this paper. In addition to these features, the architecture of Forms is built upon the following aspects that have a counterpart in the object-oriented world in languages such as Java:
· Properties of Forms objects These correspond to object and method attributes. Setting the value of a property in Forms modifies an aspect of how the object works.
· A rich event model Forms has always provided event-driven execution. Everything that happens in a Forms runtime session is as a result of code attached to an event trigger.
· Object hierarchies Forms objects are organized in a hierarchical way that suggests inheritance. For example, although there is little actual inheritance between blocks and items, those objects are arranged as parent and child both in concept and in the development environment.
· Object interfaces Forms objects can be modified programmatically through an interface to their functionality. Forms built-ins such as SET_ITEM_PROPERTY and SET_WINDOW_PROPERTY allow the code to manipulate the object at runtime.
· Private implementations Since not all properties are exposed to the programmatic interface, this model corresponds somewhat to the idea of private or protected implementations in Java. In addition, PL/SQL's facility to hide the package body from users suggests this object-oriented feature.
· Overriding inherited properties A key feature of object-oriented languages is that a child object can set properties locally and override the settings and behavior of the parent object. Forms subclassing allows local overrides although it does not have the capability for the developer to prevent inherited properties from being overridden.
In a way, there is a lower learning curve with object-based features of Forms Developer than with other true object-oriented environments. Since the product is not fully object-oriented, the developer who wants to use object features as much as possible can do so, but can also leverage common knowledge of standard Forms concepts. In addition, Forms is a 4GL development tool and is, for the most part, quicker and easier to use than a 3GL programming language.
Instead of explaining what OO concepts Forms supports, this paper takes the pragmatic approach of explaining the tool's features that support object-based development as listed above. It also discusses how you can apply these features to a template that enables standards enforcement, code reuse, and object sharing. The template is at the heart of object-based programming in Forms and its use will provide many of the same benefits of a true object-oriented development language. While the discussion focuses on Forms Release 6 (6.0 and 6i), all concepts apply equally to release 2 (Forms 5.0). The sample code used in this paper is downloadable from the author's web sites mentioned at the end of this paper.
Code Libraries
The way that code libraries work in Forms is not much different from the way that they work in most other tools that provide code sharing. A Forms .PLL library is attached to a form in the Object Navigator and all code in that library is then available to the form. Other forms can attach the same library and this is how the code reuse manifests. To put this in OO terms, the code is "inherited" into the library. If the code in the library changes, the behavior of the form that has attached the library will also change. While you can override inherited behavior in an object-oriented language, overrides in PL/SQL are not as straightforward.
Since the code in a library can be shared, it should not be written for just one form or application. You have to think in terms of making the code generic. There are two main categories of generic code: utilities and object support and reusable component methods. A reusable component is a set of objects that you have packaged together using an object group (also discussed later in this paper).
Utilities and Object Support
Utilities can provide a common interface to the user for common Forms functions such as committing a change. You can organize the packages in your library by feature or reusable component. For example, you can create a library package called F_ALERT package (the F_ prefix denoting a form-specific package) to support an alert system, and F_HELP to support a help system. You can also create generic code to support and facilitate using Forms objects. Therefore, you can code an F_ITEM package to support the item object in Forms and an F_BLOCK package to support the manipulation of blocks. A package like F_ITEM would contain procedures to accomplish tasks such as disabling items, enabling items, hiding or displaying items, and loading poplist items from a query. These procedures make the tasks easier to code as they require a single line of code instead of a number of lines of code. For example, the procedure to load a poplist from a query is about 60 lines of code if it is written correctly with sufficient exception handling. The call to a generic procedure is only one line. This saves the developer time because there is no need to code and debug this common operation.
The following is an excerpt from the F_ITEM package specification in the sample code library that contains the procedure just mentioned.
