skip to main content
OpenEdge Development: AppBuilder
Introduction : Building an application in AppBuilder
Building an application in AppBuilder
Before learning more about the underlying components of AppBuilder, consider the toy application shown below. This application uses four basic ABL objects and five SmartObjects. Figure 3 shows the application as it appears at design time, and Figure 4 at run time.
Figure 3: Toy phone book application at design time
Figure 4: Toy phone book application at run time
This application illustrates some important features of AppBuilder:
*The SmartWindow is an organizer object and a member of the class SmartContainer. SmartContainers supply an integrating context for other SmartObjects. Higher‑level organizer objects such as windows, dialogs, and frames provide an integrating context for all objects placed in them, but the level of integration depends on the objects involved.
*The SmartDataViewer, like most SmartObjects, is incorporated into the application as an instance of a master object. You create a SmartObject master in a separate operation before assembling the final application window. SmartObject masters are based on one of several SmartObject templates that are provided by AppBuilder.
*The two SmartPanels are supplied by AppBuilder predefined and precompiled. You simply select and place them.
*SmartObjects communicate smoothly with each other behind the scenes. For example, clicking on the navigation buttons in the SmartPanel causes the SmartDataViewer to display a new record. This command and data communication between SmartObjects takes place along SmartLink pathways.
AppBuilder helps create appropriate SmartLinks during the application assembly process. Each SmartLink represents a type of message to be sent when an event occurs. The messages are sent by the SmartObject experiencing the event to all other SmartObjects that are registered as being interested in events of that kind.
*Although it is not visible at run time, the SmartDataObject is a critical component of this application. It is the object that receives the navigation requests from the SmartPanel and supplies the data to the SmartDataViewer for display and, perhaps, modification.
Note that in Figure 3 the SmartDataObject widget is obscuring part of the large static text object, yet the text is completely visible in Figure 4. You can place nonvisible objects such as the SmartDataObject anywhere you like in your workspace. They are totally invisible at run time.
*The two static rectangle widgets serve to visually pull together and regularize the edges of the controls and the viewer object. Enclosing related widgets is one way to make them seem more related and reduce the sense of clutter. Even purely visual elements, used wisely, can greatly enhance the usability of your applications. Here, widening the border and filling the upper rectangle with color (modifying the colors in the Viewer to agree) creates a bit of additional visual interest, though the deep blue color might be less appropriate in a real application than in this toy one.
*The basic, static text object is an example of a special font definition. Used carefully, special fonts can add to the usability and the visual appeal of your applications.
*The Done button is another basic object. At run time, choosing the Done button ends execution and releases resources in an orderly way. AppBuilder supplies a number of predefined buttons as well as a generic one. When you add such a dedicated button to the layout, AppBuilder automatically generates appropriate trigger code. When you create your own applications, you have the option of choosing from the set of predefined buttons, or using the generic button and writing your own trigger code.
The Done button is an example of a custom object definition. It is defined in the progress.cst file. For information about creating and making available your own custom objects, see Appendix C, “Customizing AppBuilder”.”
Figure 5 shows the SmartLinks connecting the SmartObjects in the toy application. Conceptually, SmartLinks are dedicated, directional message pathways between two SmartObjects. The event-Source object experiences an event, and reports that event to the event-Target object using the ABL Publish/Subscribe mechanism.
Figure 5: SmartLinks between SmartObjects
Figure 5 shows four SmartLinks. The first is a Navigation SmartLink between the Navigation SmartPanel and the SmartDataObject. When the user chooses one of the buttons in the SmartPanel array, SmartPanel sends a Navigation message to the SmartDataObject, asking it to change the position of its current‑record pointer.
Whether this will mean a new read from the storage device is a matter for the SmartDataObject to decide, based on factors including the size of the RowObject temp-table you declared when creating it. The SmartPanel knows nothing about such matters; SmartObjects are only loosely coupled to one another.
When the SmartDataObject has changed its pointer in response to the request from the SmartPanel, it sends a Data message to the consumer of the data stream it supplies: the SmartDataViewer. When the user changes the data, and confirms the change using the Update Panel, the Update Panel reports that confirmation to the viewer, and the viewer sends an Update message back to the SmartDataObject.
Not shown in Figure 5 are links between the SmartContainer (the SmartWindow) and the SmartObjects that it contains, because those links are automatically created and removed by AppBuilder as you add and remove SmartObjects from the SmartContainer’s workspace. You never have to deal with them explicitly.
Figure 6 shows how these four links appear in the SmartLinks Editor. For further information about the editor, see the “SmartLinks editor” section.
Figure 6: Toy phone book links in SmartLinks Editor