ModuleAPI Component

Open

Figure – The ModuleAPI Object Model

Most objects accessible via the ModuleAPI object hierarchy are only valid in the context of that hierarchy. A newly created object is initially detached from the object hierarchy, hence unknown to Noah. When e.g. an Action object is added to the Actions collection then the action object is also persisted via Noah and made available to other modules.

As shown in the diagram above, all of the Noah objects are organized into an object hierarchy, in which each object is indirectly accessible as a property of its parent. All objects are ultimately connected to the ModuleAPI object through a series of such parents. For example, a Module Filter is the child of a Module collection, which is the child of the ModuleAPI.

For the collection objects the naming convention is that they are prepended with the letter ‘s’, e.g. the Actions collection object is container for Action objects. For the Sessions collection and Modules collection, there are special “filter” objects that control which objects appear in their collections. For example, the ModuleFilter object controls which Module objects appear in the Modules collection according to criteria such as “module category” and “supported inter-module communication protocols”.