Consultor Eletrônico

Persistent Procedures and SmartObjects

DRAFT COPY - Currently under review and edit.

INTRODUCTION:
=============
The following is a discussion of persistent procedures and how they
relate to SmartObjects.


WHY YOU NEED TO KNOW THIS:
===========================


PROCEDURAL APPROACH:
====================


Persistent procedures stay in memory until they are
explicitly deleted. While the persistent procedure remains
in memory, you can access the internal procedures at any
time. Because they remain in memory and their internal
procedures are available for other procedures to use,
persistent procedures are the basis for Smart Objects.

The ADM (Application Development Module) uses persistent
procedures,internal procedures, Preprocessor names,
temporary tables and include files to encourage code reuse
and maintainability. SmartObjects use persistent procedures
to perform standard actions within the particular object and
to cause other SmartObjects to perform certain tasks.

SmartObjects are encapsulated in that each SmartObject
contains all of the information relevant to itself and
the actions it can perform. They are smart because they
contain standard persistent procedures that provide each
component's behavior and the messaging or "linking"
mechanism through which the SmartObject requests services
and shares data. The SmartObjects communicate solely by
running internal procedures in each other. This is how
the ADM achieves encapsulation - there are no outside
dependencies and they do not use shared variables.

Other objects or the users interact with the SmartObject
by telling it to perform some action. SmartLinks are the
pathways by which two SmartObject communicate. It is a
bi-directional association of two SmartObjects that
establishes how they relate to each other. SmartLinks are
created and maintained in a link table.

Each SmartObject must know how to interact with other
SmartObjects. For instance, SmartQuery and Smart Viewer
work together in predefined ways. The SmartQuery tells
the SmartViewer what records to display on the screen. A
database application, for example, needs to view data so
it will have a SmartViewer to display objects and a
SmartQuery to fetch records from the database and make
them available to other objects.

When creating an application, a main window (SmartContainer)
runs each object persistently and once they are running, they
communicate by running internal procedures within other
objects. The SmartContainer institutes the other SmartObjects
at run time and sets instance attributes as well as the
SmartObject's position relative to the SmartContainer and the
other objects. When the user pushes the done button, all of
the objects are deleted and then the SmartContainer itself is
deleted. The .w file generated by the UIB for the SmartObject
has all the sections of a regular .w file including definitions,
main block and internal procedures, and in addition includes
the internal procedures that provide the standard behavior
expected of that type of SmartObject.

SmartObjects not only run persistently in the application but
also in the design window. SmartObjects are data-aware and
SmartContainers are object-aware. When you create a
SmartBrowser, it displays data even in the design window because
it is running and accessing the data. The SmartContainer, such
as a SmartWindow, at design time is aware of SmartObjects as
they are placed into it and this is what activates the
Link Advisor and prompts you to define a link from one
SmartObject to another.

Common ADM internal procedures are stored in method libraries
which are collections of internal procedures that can be run
by SmartObjects. Some internal procedures such as enable-UI
are part of the SmartObjects template but most internal
procedures are provided by including standard methods in
include files. Each include file is a collection of internal
procedures called method procedures.

The standard internal procedures are put in include files so
there is only one physical copy of the procedure. Once the
internal procedure is in an include file, it can't be changed
without changing it everywhere it's included; therefore, a
developer working on a smart object would
be unable to customize how a standard internal procedure
would work for his smart object and no other. The ADM needs
a way to customize an internal procedure for a particular
SmartObject yet still be able to put it in an include file
for maintainability. For this they use the dispatch method
procedure.

All SmartObjects include the dispatch method procedure.
This looks for two versions of a procedure - a version
with a local-prefix and a version with an adm-prefix. If a
local version of an internal procedure is found first
(local- prefix), that version is run. If not, the standard
ADM version (adm- prefix) is run. For maintainability, the
adm-version can be placed in an include file and the local
version (which is located in the SmartObject procedure file),
can be customized by the developer.

There are other internal procedures that all SmartObjects use,
including the notify Method procedure and the request Method
procedure.

The notify Method procedure is a way for a developer to run a
procedure in all SmartObjects of a specific link type. A
Record-Source object may have many Record-Target objects and
want to notify all of them that a new record is available.
The notify method procedure allows the Record-Source to
notify all of them that a new record is available.

The request Method procedure is a way to make a single Target
object request something from its source. It is used when a
developer wants the source object to perform an action only
in response to one of its targets.

SmartObjects and persistent procedures are discussed more
fully in the documents listed below:

Progress User Interface Builder
Progress Language Reference
Using Progress V8 (Wood,Jannery,Feinstein,Seidl)


ONLINE PROCEDURES OR UTILITIES:
===============================


REFERENCES TO WRITTEN DOCUMENTATION:
====================================

Progress Software Technical Support Note # 15461