• 39
• Understanding the Application Model
• Overview of Application Model
• Application Properties and Methods
• Objects Within the Application
• Running a Form or an Application
• Distributing Your Application to Customers
• Summary

39

Understanding the Application Model

The objective of Oracle Power Objects (OPO) is database application development. At the highest level, OPO consists of the following three object types: applications, sessions, and libraries. Since application development is OPO's focus, the application object (application) is the core component of OPO. Sessions act as a database interfaces for applications and libraries. Classes are used for storing reusable application resources. This chapter will provide a better understanding of the components within an application object and how they interact with the OPO environment.

Overview of Application Model

OPO organizes its components within a folder metaphor. Within a session are database objects. Within a library are reusable classes and bitmaps. This same metaphor applies to applications, as they contain other objects. An application consists of properties, methods, and objects that define the interface and actions of that application.

Applications are constructed using forms, reports, classes, bitmaps, and OLE objects. Applications interface with users through forms and reports. Each form and report is built by constructing screens that the user will see by creating and organizing objects, and controls to display information, data, and control options. The user navigates through the forms and reports accomplishing whatever tasks the application provides.

Application Properties and Methods

As with any other object in OPO, the application object has properties and methods. These properties and methods determine how the application, as a whole, interacts with the database and performs certain actions.

The properties specify the name, label, and default session for the application. Additionally, the declarations property is used to declare global variables, constants, and external functions that are used in the application. Table 39.1 is a list of the application properties:

Table 39.1. Applications properties.

Property

Description

The methods of an application provide the ability to initialize components and specify what actions occur when the application starts and ends. An application's methods also allow the developer to customize toolbar and menu bar actions. Table 39.2 is a list of the application methods:

Table 39.2. Application methods.

Method

Description

Objects Within the Application

Forms, reports, classes, bitmaps, and OLE objects are the major components that makeup an application. The specific set of these objects that comprise any given applications are displayed as icons in the applications window. Figure 39.1 illustrates an application named SAMPLAPP that contains one of each of the main application objects:

Figure 39.1. An application's objects.

Each of these components, which are objects themselves, can be comprised of other objects. Within OPO there is a form designer, a report designer, and a class designer. These designers are used to create forms, reports, and classes that incorporate graphical and data controls that convey information to the user.

Forms are the core application object. Each form represents a screen that can be viewed by the user. This screen may display data or other information, it may require input from the user, it may provide navigational control, it may simply draw a picture, or it may do all of the above. In any sense, a form interacts with the user for displaying information and receiving feedback.

Reports display data in a presentation manner. Reports are designed and look similar to forms, so they can contain essentially the same information as a form. However, the user cannot directly interact with reports. Reports simply provide a way to view and print data from an application.

Classes are a very powerful concept within OPO. They are reusable, object-oriented components that can be incorporated into forms, reports, or other classes. A class is basically a self-contained form. Its design, look, and functions are exactly like a form. Classes are generally created to perform task that are used multiple times by different forms. A simple example would be an exit button. If each form of an application required the same code to be activated on the Click method of an exit button, then a class containing an exit button with the appropriate code could be created and instanced on each form. Each instance of the class can be customized, yet tied to the parent class. If the code for this button changes, only the code in the parent class would need to be changed.

Bitmaps are simply graphic bitmaps used to add imagery to application objects. Forms, reports, classes, and buttons can display bitmaps by setting the Bitmap property of the object to the name of the bitmap, or by dropping the bitmap onto the object. Currently, OPO only supports the Windows BMP file type. In future releases, OPO will permit Mac PICT files and other file types to be imported as bitmaps.

OLE objects are instances of another software's objects that can be embedded into a form, report, or class. Object Linking and Embedding (OLE) allows different software, that are OLE enabled, to share components. For example, a Microsoft Word (Word) document and functionality can be used in an OPO form. The instanced document has the same look and feel as it does in Word, and when the instance of the document is selected, the menu bar and toolbar of Word are incorporated into OPO. There are many different products that can be included in an OPO application through OLE, including Excel, PowerPoint, Video for Windows, Sound, Paintbrush, and any other installed product that is an OLE Server.

Running a Form or an Application

Once an application is completed, the application can be run by clicking on the Run App toolbar button, or by selecting the Run | Run Application menu command. This causes OPO to compile the application objects to program code (p-code) and run the application. If any errors exist, the compiler will stop its execution, notify the developer, and highlight the error in the designer. Additionally, each form and report can be run individually for faster testing. With the form or report open, click on the Run Form/Report toolbar button, or select the Run | Run Form menu command. This will quickly compile the code for just this form or report and run it. This prevents from having to compile the entire application when working with a single form or report. Note, you cannot run a form or report by itself if it relies on other forms, nor can you navigate to other forms or reports simply because only that form or report has been compiled.

Distributing Your Application to Customers

After running and testing an application, it's ready to be distributed. The first step in distributing an application is to compile it. Clicking on the Generate Executable toolbar button invokes the Generate Runtime File Dialog Box, which is illustrated in Figure 39.2.

Figure 39.2. Generate Runtime File dialog box.

This dialog allows the application to be compiled to a separate application file, or as a stand-alone executable file. This dialog can be bypassed by selecting either the Run | Compile Application or Run | Generate Executable menu commands.

Creating a separate application file compiles the application and writes just the compiled p-code to a Power Objects (PO) file. This file can be executed using the OPO Runtime (PWRRUN.EXE). Compiling to a stand-alone executable first compiles the application to p-code, then binds it to a minimized copy of the OPO Runtime. This creates a self-sufficient executable (EXE) file. In either sense, the compiled application is executed via the OPO Runtime. Don't worry, the OPO Runtime is freely distributable which is something new for Oracle.

The advantage of compiling separate application files is size. The PO files are small, generally 25-100 Kbytes The EXE files tend to be greater than 2 Mbytes. If several applications are to be compiled and distributed together, it makes sense to compile separate application files and simply distribute them and the OPO Runtime. The user simply needs to start the OPO Runtime and specify which PO file to run. However, it's easier for the user to simply run a single executable, which is why stand-alone executables are often preferred.

If compiling separate applications files, the PO and PWRRUN.EXE files will need to be distributed. Otherwise, if compiling stand-alone executables, only the EXE file needs to be distributed. Other files that need to be distributed are database files and any external function files used by the application. If the application uses a Blaze database, the file that was created for the Blaze database file needs to be distributed. If the application runs against an Oracle, Sybase, or SQLServer database, then the corresponding Power Objects Database (POD) file needs to be distributed with the application. Additionally, if the application references any Dynamic Link Library (DLL) functions, then the associated DLL file needs to be distributed. Other files, such as session and library files, shouldn' t be distributed, since they are compiled into the PO and EXE file.

Summary

Power Objects is designed to facilitate rapid application development and deployment of database applications. The application model uses three conceptual building blocks to accomplish this goal. The session object provides a connectivity layer to database back ends. The library object provides access to application-level objects to enhance standardization and to promote object reuse. Finally, the application object represents the set of related activities that make up the application. With these three conceptual objects, a developer can maintain each conceptual area independently of the others and produce database applications to meet their current and future needs.