1.2 The Concept of Programming in Oracle Applications

The whole idea of "programming" in Oracle-based applications has a somewhat different meaning from what you might be used to in a third-generation, or even a wholly procedural fourth-generation, language.

Programming in Oracle generally entails a blending of technologies and programming styles. Suppose, for example, that you are building an application to maintain invoice information. You will first design and create a database, relying mostly on the declarative SQL language. However, you might also create database triggers, coded in PL/SQL, to implement complex business rules at the database level. From there you build the screens, charts, and reports that make up the user interface. You could use third-party tools, or you could rely on Oracle Developer/2000 (formerly the Cooperative Development Environment, or CDE), with such products as Oracle Forms, Oracle Graphics, and Oracle Reports.

Each of the Oracle Developer/2000 tools employs a nondeclarative or "fill-in-the-blanks" approach to development. Without writing any code in the traditional sense, you create a full-functioned screen with buttons, radio groups, menus, and pictures. These objects are, more or less, the graphical pieces of the program that the user views, touches, and acts upon. They are somewhat different in each tool. In Oracle Forms, these objects include items on the screen (buttons, radio groups, text fields), blocks (which correspond to tables in the database), and visual attributes (which control the way items appear to the user). In Oracle Reports, these objects include fields in the report, repeating frames of data, and parameters that are entered by the user to initiate the report. While there isn't any code per se for this part of your system, you have created objects that will be manipulated by the code you do write in PL/SQL.

Once you have built the graphical objects in your tools, you then associate PL/SQL procedural code with those objects. How? You use various kinds of triggers associated with those objects. Oracle Forms, for example, employs a sophisticated event-driven model, which is very conducive to programming in the GUI environment. You attach event triggers, such as When-Button-Pressed, to an object. Then, no matter how the user triggers an event (with the movement of a mouse, with the press of a key, or as an indirect result of another event), that trigger fires and executes the PL/SQL code you have written. The only way to apply a PL/SQL procedure or function to an object in Oracle Forms is through a trigger. All triggers are implemented in PL/SQL.

Conceptually, there are at least five layers of "code" in an Oracle Forms application, as Table 1.1 shows. Each of these different kinds of code requires a different approach to programming.

You may find the blend of technologies and programming environments that make up Oracle-based applications to be a challenge. If you are an experienced programmer, you might have worked for years in a 100% procedural language environment like COBOL. There, you've learned methodologies for designing and building your code. If you are asked to review a program, you can display those lines of text on a screen and do your analysis. In Oracle, you cannot.

If you are new to computer programming, the situation can be even worse. Introduced to powerful new technologies without any formal grounding in development, you may find yourself churning out screen after screen, report upon report, with little regard for code reusability, quality assurance, and development methodologies. And why should you? No one ever told you these issues were important. Instead, you received a week of training and were expected to move immediately to "rapid application development."

How can you apply your knowledge and experience to the world of Oracle? No matter where you came from, you will need to reconcile the different kinds of code and programming techniques. In this book we will try to help you do that.