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 ofIlsRpObject, 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 Rogue Wave 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 Rogue Wave Server/Rogue Wave Views integration is a specific mapping designed to interface Rogue Wave Server with the Rogue Wave Views/Controls-Enterprise module and, through those data sources, with various Rogue Wave Views graphical objects. This specific integration offers several representation classes which interface an implementation model made of Rogue Wave Views/Controls-Enterprise data sources.
Version 5.8
Copyright © 2014, Rogue Wave Software, Inc. All Rights Reserved.