Purpose

Concept

The ObjectManager, ObjectInfo, ObjectFieldConnection, ObjectConstrainedIterator, ObjectManagerInspector, ObjectLoader, ObjectDump, and ObjectLoaderDump modules are part of a powerful concept - the ObjectManager concept - for data and message exchange between dependent parts of a module-based application.

Module-based applications consist of numerous modules that can be structured in macro modules to build self-contained functionality on a higher level. In order to be able to communicate parameters and results a kind of data exchange is required. Here is where the ObjectManager concept comes to work.

The ObjectManager module itself lays the foundation by acting not only as database for all kinds of information but also as communication switchboard.

Each macro module contains at least one ObjMgrClient module (e.g. ObjectInfo, ObjectConstrainedIterator, or ObjectFieldConnection module) that acts as interface between the database and the macro module’s functionality (e.g. other modules, scripts, etc.).

The ObjectInfo module provides complete access to the database on an elementary level. The ObjectFieldConnection facilitates the direct information exchange between an information cell of the database and a field. The ObjectConstrainedIterator is used to iterate over all objects that meet the given criteria. The ObjectLoader module loads information from files and stores them in the ObjectManager database by employing specialized loaders derived from a framework that is part of the ObjectLoader implementation. The loaders are realized as plug-ins to facilitate the integration of additional file loaders (the ObjectLoaderDump and ObjectLoaderHepaVision modules work this way). The ObjectInspector module displays the entire database stored in the connected ObjectManager module. It allows for easy inspection of every aspect of an object and displays related events. The ObjectDump module dumps the entire database to an XML file. To load this XML file and restore the ObjectManager database instantiate the ObjectLoaderDump module that provides a loader-plugin for the ObjectLoader. The ObjectVolume module is an example of how to write a specialized client (it stores and retrieves volume information in a hard-coded information cell).

../../../Modules/ML/MLObjectManager/mhelp/Images/ObjectManager_1.png

Purpose of this Module

The ObjectManager module accommodates a hierarchical organized database. ObjectManager-client modules, hereinafter also called ObjectManagerClients, may modify the database and will be notified about modifications to the database by the ObjectManager. Those notifications are called Events.

Furthermore, different ObjectManagers may be connected by means of a TCP/IP socket connection and share marked parts of the database thereby allowing an application to span multiple computers or to exchange information via the Internet with other applications based on the ObjectManager concept.

Usage

Connect the module to the ObjectManager or other ObjectManager-client modules and access the database.

ObjectManager-clients may be cascaded as shown in the figure below (ObjectFieldConnection is connected to the ObjectManager via an ObjectInfo module).

../../../Modules/ML/MLObjectManager/mhelp/Images/ObjectManager_2.png

Details

The ObjectManager database is hierarchically organized.

Each information item has three address components: Object Id, Layer Id, and Info (Item) Id (see figure below) and may have a simple or complex data-type (e.g. string, integer, or array of vec3s).

At the highest level, called the object level, each object has a unique Id. Each object may have an unlimited number of layers, the Id must be unique within an object. Again, each layer may possess an unlimited number of information items with unique Id.

../../../Modules/ML/MLObjectManager/mhelp/Images/ObjectManager_6.png

Each ObjectManagerClient has full access to the database and may apply modifications. The ObjectManager records these modifications.

If the ObjectManagerClient is done with its modifications it sends a notification to the ObjectManager. The ObjectManager will then send out events to all connected ObjectManagerClients that want to be notified about those recent changes to the database. There are six different types of events, each describes a specific modification:

Name Description
Connected To Database The ObjMgrClient has been (re)connected to the ObjMgr database.
Object Created A new object has been created in the database. The event will carry information about the Object Id.
Object Removed An object has been removed from the database. The event will carry information about the Object Id.
Attribute Created An information item has been created in the database. The event will carry information about the Object Id, the Layer Id, the Info Id, and the Value. Layers are not explicitly created, they are set up when the first information item (sometimes called attribute) requires their existence.
Attribute Modified An information item has been modified in the database. The event will carry information about the Object Id, the Layer Id, the Info Id, the Value and its Previous Value.
Attribute Removed An information item has been removed from the database. The event will carry information about the Object Id, the Layer Id, and the Info Id.

Each ObjectManagerClient may express its wish to be notified about all, only selected, or none of those events. The selection mechanism allows to specify the Ids or full regular expressions of objects and/or layers from which events will be propagated to the ObjectManagerClient.

The notification order is determined by the priority that each ObjectManagerClient possesses. Originating from the ObjectManager module, the directly connected ObjectManagerClient module with the highest priority is first notified. If this ObjectManagerClient has other ObjectManagerClients connected, the one with the highest priority that is directly connected will be second. This scheme is equivalent to depth first traversal of a tree data structure. The priority is used to determine the order in which child modules of the same parent module will be traversed.

For more information about event handling see ObjectInfo.

Windows

Default Panel

../../../Modules/ML/MLObjectManager/mhelp/Images/Screenshots/ObjectManager._default.png

Network Panel

Defines the current TCP/IP network settings of the ObjectManager.

Multiple ObjectManagers may be connected. One ObjectManager must be configured as Server whereas all other ObjectManagers must be Clients.

The ObjectManagers may share the whole or only a limited part of the database. Events will be propagated to connected ObjectManagers and their ObjectManagerClients. The figure below illustrates the configuration for three connected ObjectManagers.

../../../Modules/ML/MLObjectManager/mhelp/Images/ObjectManager_4.png ../../../Modules/ML/MLObjectManager/mhelp/Images/ObjectManager_5.png

Info / Debug Panel

This panel allows to generate a debug info file that can be further processed by Graphviz layout engines (dot, circo, or neato) to visualize the current ObjectManager network including important settings such as the priority of the ObjectManagerClients and Event selection information.

../../../Modules/ML/MLObjectManager/mhelp/Images/ObjectManager_3.png

An ObjecManagerClient’s priority is displayed as edge label, event selection information is shown in the box.

Output Fields

outObjectContainer

name: outObjectContainer, type: omObjMgrConnection/omObjMgrConnection(MLBase)

The module has one bidirectional output connector that allows other ObjectManager-clients to connect.

Parameter Fields

Visible Fields

Event Logging

name: eventLogging, type: Bool, default: TRUE

If checked, all modifications to the database are recorded and propagated to the ObjectManagerClients if they wish to be notified.

Otherwise no recording and notification takes place.

Internal Event Filter

name: eventFilter, type: Bool, default: TRUE

If checked, the modifications to the database between two notifications are analyzed to suppress unnecessary events thereby minimizing event traffic.

It is therefore highly recommended to have this option enabled.

Permit Recursive Notification

name: permitRecursiveNotification, type: Bool, default: TRUE

If checked, all connected ObjectManagerClients are allowed to recursively call their handleNotification() method.

This is desired in most cases but may have side effects if not properly implemented.

Clients Receive Own Notification

name: clientsReceiveOwnNotification, type: Bool, default: FALSE

If checked, the ObjectManagerClient that triggered a notification as indication of database modifications will receive its own notification.

This might be desirable in some cases. In many cases, however, the ObjectManagerClient is well aware of its modifications to the database. In those cases, it is better to unchecked this field.

Clear Object Container

name: clearObjectContainer, type: Trigger

If pressed, the entire databaseis cleased.

Events for the removed objects will be propagated. This functionality is useful mainly for debugging purposes.

Info File Name

name: infoFileName, type: String

Sets the file path to which the debug info is saved. Click the Browse button to select a file path using a standard file dialog.

Save Info

name: saveInfo, type: Trigger

If pressed, the information is saved.

Network Mode

name: networkMode, type: Enum, default: NotConnected

Defines the network mode of this module.

Values:

Title Name Description
Not Connected NotConnected This ObjectManager is not connected with other ObjectManager modules via TCP/IP network connection.
Server Server This ObjectManager will listen on the specified Network Port for connections from other ObjectManagers.
Client Client This ObjectManager will try to connect to an ObjectManager at the specified Network Address and Network Port.

Network Address

name: networkAddress, type: String, default: localhost

Sets the hostname or IP address of the Server. For a local server (running on the same computer) use ‘localhost’.

Network Port

name: networkPort, type: Integer, default: 7623

Sets the port on which the Server will listen.

Comm Only Marked Info

name: commOnlyMarkedInfo, type: Bool, default: TRUE

If checked, only those information will be communicated to other ObjectManagers if one of its address components (Object Id, Layer Id, or Info Id) is flagged with network communication mode ‘Communicate’.

If unchecked, an information is communicated if none of its address components are flagged as not being communicated by choosing network communication mode ‘Conceal’.