You use application actions to define operations that a user or API can execute in a running MDriven application, such as opening a browser, saving changes, or performing an operation on a selected object.
An action defines what can be run and the context in which it can run. The action can execute OCL through EAL (Execute Action Language), or invoke a standard framework operation such as Save, Cancel, Undo, or Redo. Actions can be presented by the framework in menus, added to a button in a view, or invoked by other supported triggers.
For example, an application can provide a main-menu action that opens a Customer browser, a class action that performs an operation on one Customer, and a ViewModel action that acts on the current selection in a Customer view.
Choose the action scope
Choose the scope from the information the operation needs. The three action types you define in the model are global actions, class actions, and ViewModel actions.
| Action type | Context | Use it when | Example |
|---|---|---|---|
| Global action | The always-available application context; it is not rooted in a particular object. | A user needs to start a task from the main menu or open a view for finding objects. | Open a Customer seeker so the user can search for a Customer before working with it. |
| Class action | An instance of the class on which the action is defined. | The operation belongs to one model object and should be available wherever that class is shown. | Perform an operation on the Customer represented by a row in a browser. |
| ViewModel action | A particular ViewModel and its variables, including v_current and v_selected.
|
The operation depends on what the user currently sees, selects, or enters in that view. | Act on the objects currently selected in a Customer list. |
Global actions
Global actions are main-menu actions. They commonly open an un-rooted view: a seeker helps the user search or filter a large set of database objects, while a browser shows available instances of a class.
Use a global action when the user does not yet have a specific object context. For example, add a main-menu action that opens a seeker, let the user find a Customer, and then continue work in a view rooted in that Customer.
MDriven Designer provides standard global actions for common application operations. See Documentation:Standard actions for Save, Cancel, Refresh, Undo, Redo, and Exit, including how to restore them with Ensure Std Actions. For the global-action editor and menu arrangement, see Training:Global actions.
Class actions
A class action is rooted in an object of its class. Its expression has that object as context; use self to refer to it. A class action cannot use the ViewModel variables vCurrent or vSelected.
Prefer a class action when its behavior depends only on the object itself. Because the action is associated with the class type, it can be available in every view that shows that class. For example, define an action on Customer when it should be usable from each view that presents a Customer, rather than recreating the action in every ViewModel.
A class action may be opted out in a specific view or nesting when it is not relevant there. Read Documentation:Class actions for creation and expression-context details, and Opting out actions for controlling which actions users see.
ViewModel actions
A ViewModel action requires its ViewModel context. Use it when the operation needs view-specific state, such as the current object, selected objects, or values entered in the view.
For example, a ViewModel action in a list view can use the selected objects to perform an operation on the user's current selection. This differs from a class action: the ViewModel action is tied to that ViewModel, while the class action is tied to the model class.
You can also place EAL directly on a button without creating a full action definition. This is a ViewModel-level action expression, so use it for behavior that belongs only to that button or view. See Documentation:ViewModel actions for the ViewModel-specific configuration.
Present and execute actions
Actions can be executed in several ways:
- A user selects an opted-in action that the framework presents in the user interface.
- A user clicks a button that refers to an action, selected from the button's action list.
- A button contains EAL directly when the behavior is local to that ViewModel.
- EAL executes an action or tests whether an action can execute.
- A configured interaction triggers an action, including dragging, drag-and-drop, or a swipe on a mobile device.
When you decide where an action should appear, keep the user context clear. For example, expose a global action in the main menu to open a browser; expose a Customer class action where a Customer is displayed; and keep a selection-dependent action in the ViewModel that owns the list.
Use the Actions Editor to work with action definitions and their presentation.
Scheduled actions
Some action execution is time-based rather than initiated by a click.
- A periodic action is defined in a ViewModel and runs at an interval set by the view. For example, a ViewModel can automatically execute an action in response to data changes.
- A server-side action runs on a schedule on MDrivenServer. Its ViewModel defines both the information scope and the EAL code that acts on that information. For example, it can check a condition every minute and execute the relevant action.
These scheduled mechanisms complement the three action scopes; they do not replace the decision about whether an operation belongs globally, to a class, or to a ViewModel.
Table behavior in web clients
Do not assume every action type behaves identically when placed in a table. Class actions and EAL actions in a ViewModel work in tables and are enabled or disabled as elsewhere. Since 2020-09-27, ViewModel/context actions display as disabled in tables. See Documentation:Web client actions in tables before placing a ViewModel action in a table.
Design checklist
- Start with the smallest appropriate scope: class for object-only behavior, ViewModel for view state, and global for main-menu entry points.
- Use a class action when you want the same object operation to be available wherever that class appears.
- Use a ViewModel action when the operation requires
v_current,v_selected, or other view state. - Opt out actions where they do not help the user, rather than presenting every available action in every view.
- Use a standard action when the required behavior is Save, Cancel, Refresh, Undo, Redo, or Exit.
- Verify table placement separately for ViewModel/context actions in web clients.