The Diagram View provides a graphical representation of a definition. The layout, organization and appearance of this view is specific to the type of definition being displayed. Many of these are self-explanatory in nature. Not all definitions are displayed in the diagram view, as there is no benefit in doing so. The general rule of thumb is that definitions without child definitions are not displayed in the diagram view. The exception to this is the Rule definition type. Rules do not have child definitions. However they are displayed in the Diagram View, with the structure of the rule logic displayed in a read-only format.
For other definition types, the items in the Diagram View are organized according to the definition type selected. For many definition types this is a graphical representation of the parent-child relationship between the selected definitions and any child definitions. For others, certain organizational information is provided. It is this last group that is explained in more detail here.
Diagram View: Module Transactions
The
Diagram View for a module’s transactions displays all transactions
within a given module. This Diagram View is displayed when the bold
Transactions node in the Project Explorer View is double-clicked,
or when it is right-clicked and the View Transactions Diagram menu
item is selected. The Diagram View displays a module’s transactions
in a manner organized according to their back end processing definitions,
i.e. the step usage definitions within the transaction.
In this simple example there are three transactions displayed. Note that the AddCustomer transaction is listed three times, as it contains server data state steps, server update steps, and error handling steps. EditCustomerContact contains only update steps and is therefore listed only under that node in the diagram. Finally, DeleteCustomer does not have either data state or update steps. Therefore, it is listed under the Client-only node meaning it has no server-side processing.
Diagram View: Actions
The Diagram View for an action definition displays that action in a flow chart view representing the execution flow of the action. This can be a useful view for complex actions, especially those with subaction steps and looping behaviors.
Following is an example of an action
with two subaction steps. The first subaction step is defined to
execute once and the second is defined to execute iteratively, also
known as a looping subaction step:
The first subaction step is AddOrder, which executes a second action for an Add transaction. This step is defined to execute once. It is followed by a message step named AskAddProducts, which prompts the user to add products to the order created by the AddOrder step before it. If the user clicks the No button in the message, the Action ends execution, which is represented by the node “Cancel: ‘No’” in the above example.
If the user clicks the Yes button in the message prompt the subaction step AddProduct is executed. As shown in the Diagram View, this step is defined to loop until stopped, meaning the users indicate they are finished. Once this loop ends, the action completes, as represented by the node End in the Diagram View.
The two nodes for the subaction steps
can each be expanded to display the steps of the actions they execute.
Following is an example of this same action with the subaction steps
expanded:
With these subaction steps expanded, the steps of each subaction are displayed. The AddOrder action contains the AddOrder transaction step that displays the transaction in the AddOrder screen set. This is then followed by the Apply step.
Next the Add Products prompt is displayed, which introduces a conditional execution to the action’s execution flow. A positive response from the user executes the AddProduct subaction step. Since this step is defined to loop, the steps are presented in the diagram view to represent this behavior. The loop condition is displayed in the flow of this action, with the text “until stopped.”
A negative, or “Cancel” response from the user to the Add Products prompt ends the action’s execution.
Diagram View: Complex Tables
When displaying
a complex table in the Diagram View, the indexes and fields are
each displayed as child definitions to the complex table. In addition,
the index nodes have one or more child nodes of their own. These
child nodes are, first, the field for which the index was created
and, second, if it is a child index the field or fields for which
the parent indexes were created.
In this example, the index ProductNameByID is a child index to the ProductIDIdx index. This is represented by the Diagram View.