A Dialog is the definition of a group of interactive windows or web pages. The grouping is somewhat subjective, as windows and pages from one Dialog can flow to and from windows and pages in other Dialogs without restriction. However, a Dialog usually is composed of windows and pages that are related and would be maintained together as a logical unit.

The AOA Dialog interface involves placing Controls visually on a window or page, in a manner often referred to as painting. Controls include the typical interface components, such as text boxes, edit boxes, combo boxes, tables and graphics. Those Controls that represent data from on object define “mapping” information to an “active” object instance to tie that data to the window or page. As noted above under LOD, that mapping always is defined using the three components of an object element, View Name, Entity Name and Attribute Name. (An example of mapping for a combo box control is shown to the right.) The Windows interface is fairly WYSIWYG (what you see is what you get). However, the execution-time look from a Web Page can differ more from the definition of a page due to the relative positioning of Controls on a Web Page. 

From a definition standpoint, a Dialog composed of windows is very similar to a Dialog composed of web pages. In both cases, we have a frame, representing a window or page, on which various controls, such as edit boxes, drop down boxes, list boxes, tabs and tables, are organized. There is almost no difference in the specification of these controls on the frame. However, they generate into very different execution-time solutions. Windows Dialogs generate a run-time object that is processed by a Driver, which calls MS Windows control operations to format and process the input from a user screen. Web Page Dialogs generate a JSP file, comprised of standard JSP and AOA Object Engine calls which generate run-time HTML for processing the interactive functionality of the page. (A sample of a painted window is shown above right, followed by a sample of a painted web page.)

Though the content of a window and a web page are very much the same, the organization of that content tends to be quite different. Though not a requirement, the AOA web pages tend to be driven from top and left-side navigation bars, with some buttons and hot text. The AOA windows solutions have a number of multi-frame windows with top navigation bars, but mostly they are composed of modal sub-windows with navigation driven by buttons and pop-ups. However, in both cases, a non-procedural component called an Action is used to specify workflow and procedural logic. Actions are triggered by their tie to buttons, menu options, hot-keys and control events.

A key concept that runs throughout the concept of a Dialog (or throughout all of AOA for that matter) is that the application development process is the same regardless of the physical characteristics of the run-time environment. In the case of Dialogs, the basic development components and techniques are the same whether the run-time is MS Windows or JSP on the Web. Such run-time environments could easily be extended to support other interactive systems, such as Microsoft ASP.

In a manner similar to a LOD, a Dialog can have operations (ie., methods) to read and write to databases and manage complex workflow. Simple workflow is handled via the nonprocedural specifications that are part of a window/page definition in a Dialog. However, more complex workflow requires procedural logic. As with LOD operations, Dialog operations are specified in VML, described later in this presentation.