转载 2008年05月01日 02:26:00
<script type="text/javascript"><!-- google_ad_client = "pub-2947489232296736"; /* 728x15, 创建于 08-4-23MSDN */ google_ad_slot = "3624277373"; google_ad_width = 728; google_ad_height = 15; //--> </script> <script type="text/javascript" src=""> </script>
<script type="text/javascript"><!-- google_ad_client = "pub-2947489232296736"; /* 160x600, 创建于 08-4-23MSDN */ google_ad_slot = "4367022601"; google_ad_width = 160; google_ad_height = 600; //--> </script><script type="text/javascript" src=""> </script>



OBJECTs in Mirror are Closer Than They Appear<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />


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.

<script type="text/javascript"><!-- google_ad_client = "pub-2947489232296736"; /* 728x15, 创建于 08-4-23MSDN */ google_ad_slot = "3624277373"; google_ad_width = 728; google_ad_height = 15; //--> </script> <script type="text/javascript" src=""> </script>
<script type="text/javascript"><!-- google_ad_client = "pub-2947489232296736"; /* 160x600, 创建于 08-4-23MSDN */ google_ad_slot = "4367022601"; google_ad_width = 160; google_ad_height = 600; //--> </script><script type="text/javascript" src=""> </script>

oracle forms builder 安装配置

1.点击setup.exe进行安装,其中有一步是选择“j2ee..”或者是“结束。。”,选“结束.."那个选项, 可以细看关联文件里面的,因为要进行forms开发,肯定是要关联forms文件...
  • qiufeng1989916
  • qiufeng1989916
  • 2014年07月09日 16:32
  • 2964

前端学习(八)javascript is object based

procedural(面向过程的)、generic(泛型的)、object-based(基于对象的)、objectoriented(面向对象的)javascript is object basedIn...
  • y1yo2
  • y1yo2
  • 2017年08月14日 11:22
  • 101

Form Builder开发中TEMPLATE Form

Form Builder开发中TEMPLATE Form原文见于Applications Developer Guide(版权声明,本人原创或者翻译的文章如需转载,请于本人联系,违者必究)这一章主要用...
  • tavor
  • tavor
  • 2014年01月01日 22:47
  • 3768

Oracle Form開發(1)--FormBuilder前期準備

       安裝acle Form 6i及補丁以後,你自己開發的Form與Oracle EBIS其它的Form不一樣,如:       1.沒有工具欄;       2.不能用通用的快捷鍵F11、C...
  • chenxianping
  • chenxianping
  • 2009年08月31日 10:18
  • 3467

FRM-92101:forms Server在启动过程中失败

在rhel5 x64上完成ebs R12.1.1的基础安装,本地浏览器访问测试的时候,出现如下问题: 根据错误提示,找到日志产看原因,日志目录:$LOG_HOME/ora/10.1.3/opmn/f...
  • changyanmanman
  • changyanmanman
  • 2013年09月26日 11:23
  • 2915

OCP 1Z0 052 8

8. Observe the information in the columns:  1: The SGAa. Text and parsed forms of all SQL statement...
  • jgmydsai
  • jgmydsai
  • 2014年06月08日 10:51
  • 856


axis=0 表示纵向(上下),即列方向 axis=1 表示横向(左右),即行方向下面来看一个pandas中DataFrame的sum方法的例子:In [9]: import numpy as np...
  • u013819513
  • u013819513
  • 2017年03月22日 12:16
  • 192

Object-Based Security

Object-Based SecurityObject-based security applies to individual instances of entities and is provid...
  • zengjibing
  • zengjibing
  • 2009年01月18日 11:06
  • 415


封装ob 多态继承oo 基于对象是一种Abstract DataType,它封装了一些复杂的操作,使之易于使用。 比如说string,在C++中,通过类来实现。(封装一些数据及一些操作) ...
  • jingsihu
  • jingsihu
  • 2017年03月29日 11:22
  • 561

tensorflow TFRecord及样例

____tz_zs学习笔记 来自实际问题中的数据往往有很多格式和属性,TFRecord 格式可以统一不同的原始数据格式,并更加有效地管理不同属性。 TFRecord 文件中的数据都是通过 ...
  • tz_zs
  • tz_zs
  • 2017年09月13日 13:20
  • 257