Work flow processing in AOA is primarily directed at the problem of controlling and documenting the flow of windows and pages as the user interacts with the application. A central component of that flow is an action, which is triggered by an activity performed by the user, such as clicking an item in a list box or striking a button. What happens in response to that action is defined by the action definition, for which we will mention three of the options here:

A simple and common option is to specify transfer to a sub-window, which is denoted by dialog and window name, as shown in the example to the right.

 

Sometimes, the next window or page to be displayed is dependent on data or prior activity and must be inserted in an operation specified as a part of the action. This is shown in the sample to the right which is part of the web login process. If there is no current Person entity in the database, then it is assumed the user is a prospect continuing with a partial application. Note the user is taken to a variety of different pages depending on the state of the user.

Another common option is to simply return back to whichever window or page preceded this one.

Thus flow is mostly controlled by nonprocedural statements defined with the actions defined for a window or page.

Transferring from one interface component to another isn’t the only requirement of work flow, however. Accessing and updating data and managing the content of work-in-progress objects are also important. For this purpose, a VML operation can be executed as a part of the action. Three samples of an interface and two operations are shown on the right to demonstrate this process:

The first displays a button on the interface that is used to trigger selection of a scholarship to be tied to a Financial Aid Award.

The second shows the operation code that is triggered ay the action. Because the next window is reusable and can include a Scholarship entity into several different objects, temporary data is stored in the wXferO work-in-progress object to identify the target names for the include.

The third shows part of the operation code in the Scholarship Select window that uses the temporary data set up in the prior window to perform the proper include. The operation, IncludeSubobjectFromSubobject, uses a combination of variable names and literals to identify the views (i.e., objects) and entities that are involved in the include. At the end of the operation, control is returned to the previous window, where the selected scholarship information that was just included is displayed.