What Is a Mapping in the Server/Views Integration?

Each object within an object server can be represented on the component side by a representation object. The relation between a server object and the corresponding representation object on the component side is not necessarily a one-to-one relation. This means that a server object can be

• not represented,

• represented once (one instance of IlsRpObject), or

• represented n times (n instances of IlsRpObject).

During a notification cycle, representation objects are created in the component (see Interaction Cycles). The creation requests (as well as the deletion and update requests) are sent to the component through the generic representation protocol, which is the unique interface between a dynamic view server and the representations. These requests trigger in turn the creation, deletion or update of representation objects. All representation objects in a component derive from the class IlsRpObject.

Creating objects of type IlsRpObject is of little interest: these are “empty” objects intended to be subclassed so as to show different representations. Most likely, these will be graphical representations, but not necessarily. For example, an instance of IlsRpObject can be computing an object that would implement an inference engine or perform calculations.

When you subclass an instance of IlsRpObject, you need to specify how this subtype can map server objects to your IlsRpObject objects. This is done in two steps:

1. You must declare your representation types and their attributes to the representation model interpreter at compile time. This is the static part of the representation model.

2. You must specify:

   • how server types are mapped to representation types;

   • how server attributes are mapped to your representation attributes,

   • the dynamic part of the representation model at runtime.

Network Object Model

For example, a Network server object and its attribute name could be represented by a GrapherGadget object and its attribute label. When a Network object is created in the server, the corresponding GrapherGadget representation object is instantiated. And each time the name of the network object is changed, its representation object receives a request to set its label attribute to the new value. This example can be implemented as described below.

• The static part consists in:

  • implementing the GrapherGadget as a subclass of IlsRpObject, as well as all the modifiers (for example, the setLabel function);

  • declaring the representation objects to the representation model interpreter. To do so, you must:

    • use the ILS_RP_OBJECT_DECL macros in the header file,

    • use the ILS_RP_OBJECT_BEGIN macro in the body

    • specify via the ILS_RP_ATTR_STRING macro that the setLabel function must be called whenever the label attribute is modified.

      This step is called “mapping” because the generic protocol is mapped to a specific representation model.

• The dynamic part consists of specifying the representation associated with the Network server object using the View Specification Language, as in the following code sample:

subscribe Network

represent GrapherGadget rep:

string label=name;

A mapping is made of three items :

• a specific representation model which interfaces with an implementation model;

• an implementation model which is a set of Views data sources;

• A dynamic view which enables you to “map” your server object model to your representation model—that is, to establish a correspondence between them.

The Server/Views integration is a specific mapping designed to interface Server with the Views/Controls-Enterprise module and, through those data sources, with various Views graphical objects. This specific integration offers several representation classes which interface an implementation model made of Views/Controls-Enterprise data sources.