Principle

In the dynamic-view type approach, each dynamic view notifies its associated component representation using a generic representation protocol supplied in the Server libraries (mvserver, mvcomp). On the component side, this representation protocol is implemented by the classes IlsRpObject and IlsRepresentation.

• The class IlsRpObject is the base class for any representation object class.
  A representation object is a component object associated with a unique server object.
  Its purpose is to make a bridge between the generic representation object level of the protocol and the internal objects (either graphical or not) of the component. This bridge maps the update requests emitted by the server through the generic representation protocol to call member functions of the internal component objects. Conversely, it maps the modifications made locally on the internal objects to the execution of callback functions declared on IlsRpObject and is responsible for notification to the server.

• The class IlsRepresentation is the base class for any representation class.
  A representation is a component object associated with one server view. Each view (except if it has no origin or is closed) is associated with a single representation.

In order to implement a component-specific type of representation, it is necessary to establish a bridge between each internal class used to implement a specific kind of representation and the class IlsRpObject.

Optionally, a similar bridge can be established at the representation level. When a representation has no specific properties, it can be directly implemented as an instance of the class IlsRepresentation.

A representation model is defined at compile time by the internal component classes, which are usually independent from the Server library (for example, graphic classes implementing a grapher), and by the representation object classes that implements the bridge between these internal classes and the generic representation protocol.

The bridge classes —that is, the representation object classes and sometimes a representation class— with their “runtime attributes” are used to specify the representations associated with server object classes in dynamic view types. The Server library provides a set of macros that allow registration of these classes with a representation model interpreter. More precisely the following information is declared:

• a label and a constructor for the bridge class;

• the label and type of their runtime attributes, and their associated editing function.

This mechanism can be illustrated as follows.

Implementing a Representation Model

At runtime, each dynamic view type successfully loaded by the server creates its own corresponding dynamic representation model (see the class IlsRpModel in the Server Reference Manual). This model is an abstract structure that internally describes the representations specified in the dynamic view type. It is made up of a set of representation object models (see class IlsRpObjModel in the Reference Manual).

There is one representation object model for each representation associated with a server object type in the dynamic view type. The purpose of a representation object model is to associate internal identifiers with representation labels and representation attributes. These internal identifiers are used by the generic representation protocol to optimize communication between server and components.

Once created, the dynamic representation model is transmitted to any component that requests the opening of an instance of the view type. When received on the component side, it is interpreted by the representation model interpreter. In particular, tables are created to map each attribute identifier directly to an editing function of a representation object class.

The sections in this chapter explain how to implement the bridge for two different kinds of graphical representations.

• The next section, Implementing a Tree Representation Model, describes a plain tree representation model with a one-to-one mapping between the bridge classes and the graphic tree classes.

• Section Implementing a Table Representation Model illustrates a table representation model that implements two classes as a bridge between the generic representation protocol and a single graphic matrix class.

For each of these two examples, the first subsection presents the API of the graphic class(es) and the bridge class(es), while the second subsection shows how the bridge handles the updates received from the server and sends updates issued by the component to the server.