skip to main content
OpenEdge Development: ADM and SmartObjects
Overview : SmartObjects
The ADM is grounded in the idea that you can create external procedure objects, called SmartObjects, that represent standardized components with useful behavior. A SmartObject is defined by a procedure file called a SmartObject master, which is external to the application that instantiates the SmartObject.
SmartObjects are smart because they provide the essential functionality required for building an application. A SmartObject application component is encapsulated: it contains all the information relevant to itself and all the actions it can perform. It gets its visual features, user input capabilities, and database access abilities by encapsulating the functionality of basic objects and 4GL constructs in its procedure files within the communication framework of the ADM. Note the difference between using a basic object and a SmartObject in an application:
*When an application uses a basic object directly, the 4GL statements that define that object are written into the application’s procedure file.
*When an application uses a SmartObject that encapsulates a basic object, the 4GL statements that define the basic object are written into the SmartObject’s procedure file.
The ADM achieves encapsulation by providing a standard architecture (described in the “ADM classes” section) for building reusable and maintainable objects, and by providing a standard communication interface (see the “SmartLinks” section) that allows these objects to interoperate.
The external procedure file that defines a particular SmartObject—the SmartObject master—begins as a copy of one of several SmartObject templates that the ADM provides. With certain exceptions, each SmartObject type corresponds to a different SmartObject template. Each SmartObject also has one or more standard include files (see the “ADM classes” section) that define its properties and other aspects of its functionality. In addition, each SmartObject has one or more super procedures, which contain the internal procedures and functions that provide the SmartObject with its smart behavior. Any entity that interacts with a SmartObject—another object in the application or a user running the application—does so by telling the SmartObject to perform an action of some type.
SmartObject types
The ADM provides the SmartObjects described in Table 1–3. For detailed descriptions, see Chapter 2, “SmartObjects.”
Table 1–3: SmartObject summary
SmartObject type
ADM class
Holds instances of other SmartObjects, including other SmartContainers.
Browses records and allows updates to records in a browse widget; includes static and dynamic versions.
Displays a single data field in a SmartDataViewer.
Defines a set of records to fetch from a database and the update logic for those records.
Displays data fields in a frame and coordinates their display with other SmartObjects. Can serve as a highly specialized type of SmartContainer.
Displays data fields in a frame, to allow filtering of a data set by user‑specified selection criteria.
Provides an interface (tab folder and paging mechanism) for selecting pages in a SmartContainer.
Groups functionally related buttons (for example, navigation or update buttons) on a frame.
A SmartDataField that performs a “lookup” on a single data field.
Provides a toolbar and/or menu interface to application commands.
Simple SmartObject
Provides a template for creating new visual SmartObjects.
The lifecycle of a SmartObject
The lifecycle of a SmartObject begins with its creation and ends when a user instantiates it in an application screen at run time. Figure 1–2 depicts the lifecycle of a typical SmartObject. This is a general picture; the lifecycle of specific SmartObjects might differ.
Figure 1–2: SmartObject lifecycle
SmartObject templates and masters
You can designate a SmartObject procedure as a persistent procedure; that is, a procedure that is run persistently. You do this from the AppBuilder, in the Procedure Settings dialog box for that procedure. For more information about persistent procedures and the WAIT-FOR statement, see OpenEdge® Getting Started: ABL Essentials and OpenEdge Development: ABL Reference.
Before you can run persistent instances of a SmartObject, however, you must build its external procedure (its SmartObject master). You can build an individual SmartObject master from a template, which the AppBuilder reads into memory as an untitled procedure. (You can either use one of the templates provided with the AppBuilder or build your own templates.) Alternatively, you can create a new master by saving an existing file as another file while in the AppBuilder (choose FileSave As on the AppBuilder menu bar).
Recall that conceptually, a SmartObject template is a procedure file that serves as a general starting point for building one or more specific SmartObjects masters. A template usually has minimal user‑interface features and very little code (other than included code); therefore, it is not meant to be run directly. Adding too much data and too many user‑interface features to a template might hinder its general usefulness and maintainability; however, some templates have associated data and user‑interface elements, as appropriate. For example, the template for a SmartDialog has OK, Cancel, and Help buttons, user‑interface elements that are standard to dialog boxes.
A SmartObject template generally includes a single support include file: the primary include file for the class on which the SmartObject is based. This include file has the same name as the template but the filename suffix .i instead of .w. For instance, the SmartDataViewer template viewer.w includes the primary include file viewer.i. A primary include file such as viewer.i does not directly contain most of the code needed to support the SmartObject. It contains only those program elements required to compile a master built from that template; all other support code for an object type resides in a super procedure (see the “Super procedures” section.)
At run time, the top‑level application procedure (a SmartContainer; typically, a SmartWindow) instantiates the other SmartObjects it contains. Instantiation has several steps, during which the top-level SmartContainer does the following:
1. Runs the master for each SmartObject persistently to create an instance of that SmartObject.
2. Sets instance properties in each SmartObject and sets the position of each SmartObject relative to the SmartContainer.
3. Tells the SmartObject how it relates to the other objects in the SmartContainer.
4. Instructs the SmartObject to initialize and display itself. This is done in the generated procedure adm-create-objects.
The SmartContainer does not directly dictate the contents of SmartObjects when it tells them to initialize themselves. Each SmartObject responds differently to this request according to its type. The SmartContainer does not need to be aware of this; it sends exactly the same request to all SmartObjects and allows them to handle the details themselves.