| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (3 out of 17)

Declaring Configurations for Items

 You declare configurations for items by entering configuration statements in their Item-configuration and Instance-configuration attributes.

You use an item configuration to customize the behavior of an item, based on its location within the current KB's workspace hierarchy. You declare an item configuration by entering configuration statements into the Item-configuration attribute of an item. Items of every class have an Item-configuration attribute.

You use an instance configuration to customize the behavior of a class of items, based on the position of their class in the KB's class hierarchy. You declare an instance configuration by entering configuration statements into the Instance-configuration attribute of a class definition.

Only class definitions have an Instance-configuration attribute. Therefore, you can use instance configurations only to customize items of user-defined classes.

The next figure shows two configuration statements. The first declares that clicking the mouse on any object, connection, or message definition causes G2 to create an instance of the class. The second is a declaration that improves efficiency for an item.


You can also declare global configurations by entering them in the KB Configuration system table. Some configurations exist there by default, which you can change as you require.

Kinds of Configuration Statements

An Item-configuration or Instance-configuration attribute can contain one or more configuration statements. There are five general types of configuration statements, summarized in the following table. For information on cooperative combinations, see Combining Cooperatively.

Type of Configuration Statement Support Cooperative Combinations? Purpose
configure the user interface as follows
Yes
Determines how an item responds to interactive operations
restrict proprietary items as follows
Yes
Determines how a proprietary item responds to interactive operations (and certain programmatic operations)
set up network access as follows
No
Determines access to an item (or to the entire KB) by other G2 process and by G2 Gateway bridge and Telewindows processes; affects read, write, execute, inform, and connect access
declare properties ... as follows
No
Declares an item as: disabled, text-stripped, stable-for-dependent-compilations, independent-for-all compilations, stable-hierarchy, inlineable, or not In instance configurations, configures items to support: activatable-subworkspace, external-simulation, manual-connections, subworkspace-connection-posts, or optimizable The G2 Simulator, which can provide external simulation, is a superseded capability. For more information, see Appendix F, Superseded Practices.
comment as follows
No
Declares comment text in a configuration

A configuration statement can have more than one clause. Within one configuration statement, use a semicolon (;) to separate the statement's clauses. Do not append a semicolon to the last configuration statement.

Configurations propagate through your KB's class and workspace hierarchies. Thus, there is no need to specify configurations in each item of your KB.

Note: The Item-configuration and Instance-configuration attributes are compiled attributes. G2 saves a compiled version of the attribute's text in the item, not the exact text that you enter.

Scope of Configurations

The scope of a configuration means the items to which it applies.

Items can inherit the configurations that are declared for items higher in the class and workspace hierarchies. Thus, one configuration can apply to many items in your KB. For example, the following configuration statement optimizes the compilation of all tracked-vehicle items in a KB:

Different configurations can overlap, such as when you declare configurations on two items on the same branch of the KB's workspace hierarchy. Thus, more than one configuration can also apply to the same item.

You can also declare a configuration that applies to only one item. Such a configuration is not inherited down the class or workspace hierarchies. In the configuration statement, instead of naming the class of items that the configuration applies to, include the this item phrase. For example:

Precedence of Configurations

If two configurations apply to the same item, it is possible that they declare conflicting behaviors for that item. For example, one configuration declared for any item of the VEHICLE class might declare that each vehicle item must respond to a mouse click by rotating, and another configuration declared for the vehicle item named security-vehicle might declare that it not respond to mouse-clicks at all.

In this situation, G2 uses a predictable mechanism to determine which of two or more conflicting configurations to use. G2's precedence rules for configurations are based on the current KB's class and workspace hierarchies. By default, if configurations for an item conflict, G2 uses the configuration declared closest to the target item in the class and workspace hierarchy, and ignores the conflicting configurations.

Example of the Scope of Configurations

The following example illustrates how the KB's class and workspace hierarchies determine the scope of an item configuration. Consider a KB that monitors vehicles. Assume that one of the KB's top-level workspaces is named Top Level, and that it contains two navigation button items, Definitions and Schematic, each of which has a subworkspace of the same name.

The Schematic navigation button declares an item configuration, which optimizes the compilation of the navigation button itself, and all items below it in the workspace hierarchy. Thus, by default, all items on the Schematic workspace are automatically optimized for compilation.


The next figure shows that an instance configuration stored in a class definition applies to all items of that class and to all items of any subclass of that class. In this way, one instance configuration can affect a large set of items.

The figure shows that an instance configuration declared in the CAR-CLASS definition applies to all instances of CAR-CLASS and to all items of the SERVICE-CARS class, which is a subclass of CAR-CLASS. The instance configuration restricts the menu choices on to exclude rotate, reflect, and change size. Thus, the two cars on the Schematic workspace both inherit the configuration in the CAR-CLASS definition.


How G2 Searches for Applicable Configurations

When an item is the target of a user gesture, before G2 performs the operation associated with that user gesture, G2 must determine which configurations apply to the item at that particular moment in time. To do so, G2 searches in the following order for configuration statements in the following items:

  1. Configuration statements in the Item-configuration attribute of the item.

  2. Configuration statements in the Item-configuration attribute of each item that is above the current item in the workspace hierarchy.

    If the item that declares the configuration is contained in an attribute of some other item, G2 searches all workspaces above the item containing the configured item.

  3. Configuration statements in the Item-configuration attribute of the KB Configuration system table.

  4. If the class of the item is user-defined, configuration statements in the Instance-configuration attribute of the class definition that defines the item's class.

  5. If the class of the item is user-defined, for each definition item that declares a class in the Class-inheritance-path attribute of the class definition, configuration statements in the Instance-configuration attribute of that definition item.

Given the KB shown in the previous figures, the following figure shows how G2 searches for the configurations that apply when a user clicks the mouse on car-class-1. G2 reacts to this user gesture as follows:

  1. Checks whether the Item-configuration attribute of the CAR-CLASS contains configuration statements.

  2. Checks whether any configuration statements apply to car-class-1 in the Item-configuration attribute of the SCHEMATIC workspace.

  3. Checks the Schematic navigation button for an Item-configuration.

  4. Checks the Top Level workspace for an Item-configuration, which is the superior item of the workspace hierarchy for car-class-1.

  5. Checks whether any configurations declared in the Item-configuration attribute of the KB Configuration system table apply to car-class-1.

  6. Finally, since the CAR-CLASS class is user-defined, G2 checks whether the Instance-configuration attribute of the CAR-CLASS definition contains configuration statements that apply to car-class-1.

    Items Searched for Configurations that Apply to CAR-CLASS


Because the direct superior class of CAR-CLASS is OBJECT, which is a foundation class, G2 stops searching for additional instance configurations. (A foundation class is a G2 system-defined class that can be the direct superior class of a user-defined class.) Otherwise, G2 would search for any instance configuration declared in the definitions of all user-defined superior classes of CAR-CLASS.

As stated in Precedence of Configurations, if two configuration statements, or clauses within a configuration statement conflict for an item, the last statement or clause takes precedence.

Instance Configurations and Definition Items

An instance configuration does not apply to the definition item itself, nor to the definition items that define subclasses of the configured class.

For example, in the figure below, an instance configuration declared in the PIPE connection definition includes in its scope all items of the PIPE class and all items of the PRESSURIZED-PIPE and REFRIGERATED-PIPE classes. However, the scope of that instance configuration does not include the items PIPE, PRESSURIZED-PIPE, and REFRIGERATED-PIPE themselves.


| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (3 out of 17)

Copyright © 1997 Gensym Corporation, Inc.