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

Creating and Using a Workspace Hierarchy

Each top-level workspace, the items it contains, the subworkspaces of those items, and so on, form a pattern called a workspace hierarchy. Each workspace hierarchy forms a tree, with the top-level workspace at the root of the tree.

Only KB workspaces and the items they contain can participate in a workspace hierarchy.

Creating a Subworkspace for an Item

Some items can optionally have an associated child workspace, called a subworkspace. An item's subworkspace can contain other items. Use the subworkspace of an item to collect other items that have some relationship to that item. For example, you can create a variable that has a subworkspace containing the rules that conclude a new current value for the variable.

Items of many system-defined classes can have a subworkspace. Items of any subclass of OBJECT can also have a subworkspace. An item can have only one subworkspace.

To create a new subworkspace for an item interactively:

This menu choice creates a new workspace and automatically makes it the subworkspace of the selected item. G2 automatically displays the new workspace with its center at the current center of the window.

After the subworkspace of an item exists, the create subworkspace choice no longer appears on the item's menu.

To go to the subworkspace of an item:

To create a new subworkspace for an item programmatically:

G2 does not automatically display a new subworkspace that is created programmatically. To display a new subworkspace programmatically, use the show action.

For instance, this action button creates a new item-list and creates its subworkspace:


Displaying the Workspace Hierarchy

Each top-level workspace in your KB has a distinct workspace hierarchy. You can use the Inspect facility to view the current workspace hierarchies.

To display the workspace hierarchy:

This figure shows an example of a workspace hierarchy:


You can also display the workspace hierarchy for a particular workspace by using a command like this:

Determining Whether a Subworkspace Exists

An item has an implicit, system-defined relationship with its subworkspace, which you can determine interactively or programmatically:

Referring to Subworkspaces Programmatically

You refer to the subworkspace of an item and to the superior item like this:

Configuring Items Based on the Workspace Hierarchy

You can declare configurations in the Item-configuration attributes of a workspace to customize the behavior of items for particular categories of users.

Item configurations declared in one workspace can also pertain to all items below that item in the workspace hierarchy. Thus, the workspace hierarchy can serve as a framework for controlling the behavior of whole regions of KB knowledge. For more information about using item configurations, see Chapter 7, Configurations.

Organizing Knowledge in Subworkspaces by Using Connection Posts

You can make the relationship between an item and its subworkspace explicit by using connections and connection posts. To do this, create an object class definition that declares the following instance configuration:

When you create an instance of this user-defined class, the subworkspace of the new instance automatically contains a connection post for each stub defined in the object class definition or for each connection that the instance receives from a connection post.

This figure shows an instance of a user-defined class named COMPONENT-SUBASSEMBLY. This definition declares two stubs for each instance.


The definition also declares this instance configuration:

As a result, for each instance of this class with a subworkspace, G2 automatically places permanent connection post items on the subworkspace for each declared stub in the definition. G2 also positions the connection posts within the subworkspace relative to the location of the stubs on the instance.

In this example, each connection drawn between a stub on the instance and any connection post is automatically associated with one of the connection posts on the subworkspace of the instance. G2 associates each connection in the Superior-connection attribute of the appropriate subworkspace connection post.

If the object class definition does not declare stubs, and you interactively create a connection by dragging a stub from a connection post into the instance, G2 automatically creates connection post items on the subworkspace of the instance when you create the subworkspace. G2 locates the connection posts on the subworkspace relative to the location of the connections on the instance. The following figure illustrates this situation:


The figure shows a new version of the COMPONENT-SUBASSEMBLY definition that does not declare stubs. After you make a connection between the custom connection post and the instance, and then create a subworkspace for the instance, G2 automatically creates and places a connection post on the subworkspace, and places it relative to the position of the connection on the instance.

Associating Top-Level Workspaces with Modules

By assigning a top-level workspace to a module, you can associate a set of items with a module. Dividing a large KB into modules is the recommended way to organize the knowledge in your KB and to facilitate knowledge reuse.

To learn how to use top-level workspaces to identify the items associated with a module, see the section Associating Items With a Module.

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

Copyright © 1997 Gensym Corporation, Inc.