You define Operations in a Persistate definition file. They are grouped into OperationGroups which are Members of ObjectClasses. The OperationGroups are used to represent groupings of operations in a user interface, such as menus and toolbars. The OperationVisibility property of an Operation defines where in the user interface an Operation will appear.

Note that the way that Operations and OperationGroups function as described here is provisional. They will be redesigned at the same time that the Persistate security subsystem is finalised.

Operations are declarative - they represent a static description of a function. The execution of an Operation at a particular point in time is represented by an Execution object. Operation executions are part of the Persistate scheme to decouple controller code from user interface code, as part of the implementation of the MVC architecture. Controller to user interface communication is performed through the UserInterface class, and user interface to controller communication uses Operation executions.

Operation executions are also the most often used quantum of database transactions. In general, a user will request an Operation execution by selecting a menu option, clicking a toolbar button, or making some other user interface gesture. This request is ferried to the Controller, which then executes the Operation, and at the end of the execution, saves any modifications to persistent storage under control of a transaction.

For every Operation that you define in your Persistate definition file, Persistate will create two method stubs for you. One, called Execute[operation name], will be to execute the Operation, and the other, called [operation name]Presence will be to determine if the Operation should be enabled and/or visible, given the current state of the user interface. These operation stubs are created in classes with the name [operation group name]Operations, and you write the code to set the presence and execute the Operations in these methods.

The Presence method is created in the user interface module. The Execute method is created in the controller module, except for operations you define as user interface Operations. These are Operations which work solely within the user interface, modifying no data, and their Execute methods are created in the user interface module. For these Operations, the ExecutesInUi property returns true.

As well as requesting operation executions by user interaction, you can also execute them programmatically from either the user interface or controller modules. Executing them is exactly the same from both modules - Persistate handles the ferrying of calls to the controller if required. There are two Execute methods to do this, as well as an ExecuteConcurrent method which performs the execution on a threadpool thread.

When you call these methods you supply a target Persistent and a targetCollection IPersistateList parameter, as well as any other parameters that the Operation requires. When Operations are requested from a user interaction, these are the object currently selected on screen, and any collection in which it appears. Either of these can be null, and often your Presence method for the Operation will return Enabled only if there is a target and/or collection of the appropriate type available.

Persistate defines a number of Standard Operations, which are in fact defined in OperationGroups belonging to the Persistent class. For example, the Collection OperationGroup contains the Operations Delete, Remove, New, Add, MoveUp and MoveDown. Executing these operations are the only way you can modify collections in the user interface module. You can, however, modify persistent object properties in code. This starts a Modify operation which is sent to the controller either when you execute Save, or just before you execute any other Operation. Persistate creates Execute and Presence methods for the standard operations too, giving you the chance to alter their behaviour, or stick with the standard operation behaviour.