| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 12)

Activating and Deactivating Workspaces

To activate a workspace means to declare the items upon that workspace as available to participate in KB processing. G2 activates enabled workspaces and subworkspaces automatically when you start or restart the current KB, and when you programmatically activate an activatable subworkspace.

The primary effect of activating a workspace is to cause G2 to invoke all initially rules upon them. The invocation of initially rules is described in the section Activating the Parent Workspace of a Rule.

Activating a workspace also activates all enabled items that reside upon the workspace. The activation status of an item determines whether it is active. In general, the activation status of an item propagates from its top-level workspace. For example, if you create an item on an active and enabled workspace, the item and its subworkspace are also active and enabled.

The activation status of an item is distinct from whether it is enabled or disabled, which depends only on whether you have selected the enable and disable choices for the item. By default, a workspace is enabled until you interactively disable it using the disable menu choice. When you disable an item, the workspaces in the hierarchy below the item are no longer active.

Activating Top-Level Workspaces

Each time you start or restart the current KB, G2 automatically does the following:

  1. Activates each enabled top-level workspace.

  2. Propagates the activation status of each top-level workspace to each item below it in its own workspace hierarchy.

Note: After the current KB has started or restarted, when a top-level workspace becomes enabled, all enabled items below it in its own workspace hierarchy also become activated.

All types of definitions (for example, class definitions and relation definitions) remain in effect regardless of their activation status and regardless of whether they are enabled or disabled. This means that you can instantiate definitions that are inactive or disabled.

Executable items (for example, rules and procedures) must be enabled and activated to be eligible to be invoked.

Activating and Deactivating a Subworkspace

Many system-defined items are capable of having a subworkspace as described in Creating a Subworkspace for an Item. Subworkspaces inherit the activation status from the top-level workspace. If both the workspace and the item for which you create a subworkspace are both enabled and active, the subworkspace of the item is also enabled and active.

An activatable subworkspace is the subworkspace of an item whose parent item has been configured using this configuration statement:

You specify this statement in an Item-configuration or Instance-configuration attribute, as described in Chapter 7, Configurations.

An activatable subworkspace does not inherit its activation status from the top-level workspace. Instead, you must activate an activatable subworkspace programmatically using the activate and deactivate actions.

Note: A deactivated workspace is not excluded from existence checks in a KB such as the count of each kb-workspace.

Activating and deactivating activatable subworkspaces programmatically provides a technique for turning portions of a KB on or off. By activating and deactivating appropriate portions of the workspace hierarchy, you can implement modes in your application, activating those branches which are relevant to the current mode while deactivating branches used to model competing modes.

How Activating and Deactivating Affects Items

When you first create an activatable subworkspace, it is active. Subsequently resetting or restarting the KB renders the subworkspace deactivated and it must then be activated programmatically.

When you activate an activatable subworkspace, G2 invokes all initially rules upon that subworkspace, and resets variables and parameters that have initial values to those values. Default attribute values changed since instantiation are not reset.

When you deactivate an activatable subworkspace, G2 ignores the rules, objects, and connections (but not class definitions) that it and its subworkspaces contain, until that subworkspace is again activated. Variables and parameters are reset to their initial values. Deactivating a subworkspace also deactivates all of its subworkspaces automatically.

You activate and deactivate activatable subworkspaces programmatically by using the activate and deactivate actions. For a description of these actions, see activate and deactivate.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 12)

Copyright © 1997 Gensym Corporation, Inc.