https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&d...

Oracle Forms & Object Libraries - An overview [ID 66373.1]

Modified 09-JUN-2009 Type WHITE PAPER Status PUBLISHED

Checked for relevance on 09-Jun-2009

OBJECT LIBRARIES AND EFFECTIVE DEVELOPMENT IN FORMS

Grant Ronald, Oracle Support Services.

INTRODUCTION

What are Object Libraries?

Since Forms 5.0 introduced the new concept of object libraries. This paper discusses
the merits of object libraries and how to create some simple examples. Object
libraries are a way of encapsulating project standard, reusable and easily
maintainable Forms objects. The careful use of object libraries can go a long
way to embracing many of the concepts behind good object oriented software
techniques.

Some of the principal concepts behind Object Oriented Programming are:

Inheritance
Object Reuse
Encapsulation
Modularity
Polymorphism

These can be best summarized as follows:

BASIC OBJECT PROGRAMMING

Inheritance

"The Application I'm Responsible For Looks Like It Was Developed By Ten
Different People !"

In particular with designing a GUI application, the look and feel of the product
can, in some cases, be more important than the functionality itself. User
acceptance can be based on the immediate usability and aesthetic appeal. With
most applications being written by a number of different teams of programmers it
is essential that a mechanism is put in place which will ensure a common look
and feel across the application. This can best be achieved by the use of object
libraries in Forms. A common set of standard objects can be created and stored
in an object library. Once defined, this object library would be released to
developers who would create their area of the application using the objects
defined in the object library as the basic building blocks.

For example, the object library would define that all text items would have a
height of 20 and a background color of blue and would be called BASIC_TEXT_FIELD.
Any item then created using this base 'class' would automatically have its
background color set to blue and the height to 20. If however, changes in
design standards or a new platform meant that the basic text item should now be
height 18, then changing the base class BASIC_TEXT_FIELD in the object library
would be the only change required. All other instances subclassed from this
type would automatically inherit the new value. We have thus taken steps to
ensure a common look and feel across our application.

Object Reuse

"We Keep Duplicating and Re-Inventing Functionality Within Our Project"

When developing large software applications, any method which reduces the amount
of physical code written can make significant savings in the software life cycle.
What if you had a particular field which had a complex piece of functionality
behind it which was used throughout the application. Of course you could
duplicate the items across the application but because this is a separate
instance in each case it would, in theory, require its own testing and
maintenance. If the functionality of that item was to change, all instances
would have to be updated.

Object reuse coupled with Inheritance means that the objects can be defined once
in the object library and instances throughout the application would be 'clones',
requiring a single point of update and testing.

Object libraries provide a repository for reusable objects within an application.

Encapsulation

"Adding a new feature to one screen somehow caused ten others to break !"

The reality of software engineering is that with the best intentions in the
world, bugs will be introduced into the application as it is developed.
By coding up 'shrink wrapped' packages of code and objects and placing them in
the object library, we are providing developers with a set of pre-tested tools
and removing the concern of implementation behind these objects. These objects
will be designed and coded such that no parts of the object depend on the
internal details of another.

Again, the object library acts as a repository for those objects.

Modularity

"Our Applications Are All Jumbled With No Clear Dividing Line !"

As the development of an application grows, badly partitioned design can mean a

high interdependency between modules, making testing and integration a more
complex task.

By starting with a well defined set of object libraries you are encouraging a
modular approach to the software life cycle. Within the object library itself
objects can be partitioned into folders. The creation of different object
libraries for different application areas means that the application developers
need only concern themselves with the objects required for their part of the
application. Also, since there is only one defining point for objects, the
object library, we have immediately reduced the risk of duplication.

Polymorphism

"How Can We Make Our Code More Reusable ?"

1 of 4 10/14/2010 11:11 AM
 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&d...

One of the mandates of object programming is the sub classing of information or

properties from a parent. However, this has the potential to be limiting if the
children require subtle differences in behavior.

Many development teams like to use generic objects which can be used in
different situations and perform the appropriate action depending on the area
to which it is applied. This is also supported within object libraries.

Returning to our example of BASIC_TEXT_FIELD, we may have a single instance

where the background for this field must be red. Instead of defining a new
object in the object library which would only be used once, or creating a new
item in the form (which we would have to update if the height of
BASIC_TEXT_FIELD changed) we can create an item and inherit the attributes of
BASIC_TEXT_FIELD but then we can override any of the attributes. In this case
the background color.

Thus, the object library allows us to use the full features of inheritance with
the flexibility of tailoring where required.

HOW DO OBJECT LIBRARIES WORK

The basic concept

The concept of an object library in Forms in very similar to a library of

packages and procedures, but for Forms objects. Note that only Forms objects
may be stored in the object library. That means that menu, reports or graphic
items cannot be stored in the object library.

The object library itself can be stored on the file system or on the database
and is referred to during design and module generation Any changes in the
object library will only be reflected in the form module when the module is
opened in the designer or is regenerated. Thus, there is no need to include
the library as part of the delivered system.

When creating objects to be placed in the object library the objects would first
be created in a 'source' form. It is strongly recommended that this source
form be kept and used for updating the object library. (In fact I would go as
far as to say this is mandatory). This will be discussed later in this note, but
basically there is no inheritance within the object library itself. All the
inheritance between classes happens in the source form and the new inherited
instances are copied to the object library for distribution.

How do I create an Object Library

To create an object library simply select Object Libraries in the Object

Navigator and press the green + symbol.
You have now opened up a new object library.

The next step would be to create folders within the object library in which you
will organize your objects. The organization of the object library folder is
purely down to personal preference however, some careful consideration at this
point will reap the benefits during the software life cycle. The folders could
be grouped relating to forms items, for example, Windows, Canvases, Blocks,
Items, Property Classes.

One other method may be to group them within application specific folders:
For example: Passenger Detail Items, Control Items, Video Control Items.
Name the folder appropriately by selecting the name and editing in the Object
Navigator. You should then also change the label. Select the library folder
and then bring up the property sheet. You can then set the label on the tab
and insert some comments. Once you have created the basic framework for the
object library you may start populating it.

Populating the Object Library

To populate an object library you need to start off with a 'master source' form.
This will be a form on which you can create and manipulate objects. Once they
have been designed (and tested), they are dragged into the object library.

One thing to be careful of when designing your basic item in the source form is
that some properties may become set in the object, but those are not properties
you wish the object class to have.

For example, if you have created a standard button you may want to set the
height and width. However, if you create the button on a canvas then the
canvas property will become set. You can tell which properties have been set
by the symbols on the property sheet.
A circle indicates the default value for the property which has not been
overridden.
A square indicates that this property has been explicitly set.
An arrow indicates that the property has been inherited from a base class.
An arrow with a red line indicates that the property inherited from the base
class has been overridden.

If, for any property that has had its value overwritten, you require the
original value (this could either be the default value or the inherited value
for sub classed objects), press the Inherit button at the top of the Property
Palette.

You may create an item LONG_FIELD in the source form and set the height and
width to 20 and 200 respectively. You may then create a second item in the
source form and set its subclass information such that it subclasses the height
and width from LONG_FIELD in the source form. This new item may have specific
properties set (e.g. set background color to yellow) and we will name this item
LONG_YELLOW. Once we are happy with this definition we drag both LONG_FIELD and
LONG_YELLOW into the object library.

Note that the hierarchy defined via subclassing within the source form is not
retained when the items are copied into the object library. Hence, if the
'parent' object is modified and then replaced in the object library, properties
inherited by any 'child' objects will not be updated in the object library -
only in the source form item which should also be copied to the object library. It is for this reason that the source form must be retained as a configurabl

Updating the Object Library

Any updates required to an object within the object library must be done to the
object in the source form and then dragged into the object library to overwrite
the original. You CANNOT update items directly in the object library.

Continuing our example from above, if we now decide that LONG_FIELD should have
a height of 25 instead of 20, we would make the change in LONG_FIELD in the
source form. LONG_YELLOW would automatically inherit this change. Note, at

2 of 4 10/14/2010 11:11 AM
 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&d...

this point, any fields in the application which were subclassed from these items
in the object library will not yet reflect the changes until the new updated
items are dragged into the object library and the forms which reference them are
opened and saved or regenerated.

From the toolbar on the object library you can also remove objects and add
comments.

Try the following steps to create a simple example:

1. In a new form (call it SOURCE) create BASIC_TEXT_ITEM in the layout editor

and set the height and width to 20 and 100 respectively. Save the form.
2. Create a second item in SOURCE (form) and in the property sheet of the new
item set the subclass information to point to BASIC_TEXT_ITEM in SOURCE.
3. On this new item set the background color to yellow and rename to
YELLOW_TEXT_ITEM.
4. You can see from the Object Navigator that YELLOW_TEXT_ITEM is inheriting
properties. You can tell this by the arrow in the Object Navigator or by
selecting the Subclass Information property on the YELLOW_TEXT_ITEM.
5. Now create a new object library and drag BASIC_TEXT_ITEM and
YELLOW_TEXT_ITEM into it from the object navigator.
6. Select each item in the object library in turn and then from the menu select
OBJECT, SMART CLASS. This will now smart class the items in the object
library. Now save the object library.
7. In a brand new form (call it APPLICATION), create a simple block and canvas
and two text items. Select each of the text items and smart class one (use
right mouse button) each to BASIC_TEXT_ITEM and YELLOW_TEXT_ITEM. You will
now have created two instances of the classes in the object library (thus
ensuring a common look and feel).
8. Now consider the fact that BASIC_TEXT_ITEM needs to change its height to 25
instead of 20. In the source form, change the height attribute of
BASIC_TEXT_ITEM. You will see that YELLOW_TEXT_ITEM will be updated
automatically in the SOURCE form. However, there is no change in the
APPLICATION. This is because you have not yet updated the object library.
9. Drag the new instance of BASIC_TEXT_ITEM and YELLOW_TEXT_ITEM from the
SOURCE form to the object library. You will now see the updates reflected
on the APPLICATION form.

Note that in the above example, although we only physically updated

BASIC_TEXT_ITEM, because YELLOW_TEXT_ITEM was sub classed from it we required
the new YELLOW_TEXT_ITEM to be dragged into the object library. This
demonstrates the point made earlier that there is no inheritance within the
object library itself. If there was, the version of YELLOW_TEXT_ITEM in the
object library (and all of its sub classed instances) would have been updated
when BASIC_TEXT_ITEM was dragged back into the object library.

EXPANDING ON SOME BASIC PRINCIPLES

Visual Attributes

We have shown some of the basics of the object library. As you become more
comfortable with the basics you can investigate some of the more advanced
features.

Forms has the concept of a Visual Attribute. This is a collection of visual

properties which can be applied to a forms object.

At this point it should be acknowledged that there is a slight overlap in the

functionality of visual attributes and object libraries. Why define a visual
attribute to define a red background when I could create an object of the
correct type, set the appropriate properties and reuse that throughout my
application?

One advantage of the visual attribute is that it is another level of

modularization, encompassing all properties which relate to the visual
presentation of an item. Thus, we create a visual attribute to define the
color and font for all text items and apply that visual attribute across
multiple objects that require that 'look'. This, coupled with the fact that
visual attributes can be assigned programmatically to an item justifies their
place within Forms.

One feature of using visual attributes and object libraries which should be
emphasized is that when an item is sub classed into a forms module the visual
attribute must also be sub classed into that module.

Property Classes

Property Classes are a similar tool to object libraries, defining a set of

attributes to be applied to an item rather than an item in its own right. These
can be used as another level of subclassing within the object library.

Triggers work in a very similar way to attributes such as background color.

Creating a trigger on an item and placing that item on the object library will
mean that any instance of that object will also contain the trigger. Updating
the trigger code in the object library (via the source form) will mean all
instances will inherit the changed code.

Object Groups

Object groups can be used to group logical collections of items. If within the
source form you build up a number of logical object groups, for example, a group
of objects which define the visual aspect for say, fonts, and another group of
objects which define a calendar widget, then life is made simpler if each set is
placed within its own object group within the source form. These distinct groups
can then be transferred to the object library. In this way the developer of the
library need not keep a detailed log of the hierarchy within the group. All
that is required is to drag the object group into the object library once all
necessary changes have been made.

Smart Classes

Smart classing an item is simply a way of indicating that the object is a

standard object. In the same way that a Radio Button is a standard item, we
could create My_Radio_Button which could be picked up from the pop up menu when
creating a new item. Smart classing does not alter the way the object in the
object library works, it is simply a way of tagging that item so it can be
easily used by developers.

IN CONCLUSION

As with all tools, incorrect use can be more counter productive than not using
it at all. Forms has introduced the object library to aid better development.
When used with careful consideration of the information in this paper, object

3 of 4 10/14/2010 11:11 AM
 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&d...

libraries can be a powerful tool for application developers. Embracing many of

the concepts of object programming, it will allow the basic building blocks to
be designed, coded and tested in a way that aids future maintenance and
nurtures a framework for effective development.

Related

Products

Middleware > Developer Tools > Database & PLSQL > Oracle Forms

Keywords

CLASS; INHERITANCE

Back to top

Rate this document

4 of 4 10/14/2010 11:11 AM