Implementing the Component
Before you can represent all or part of a server object model using a
dynamic view, you need to define a representation model. This representation model will include the static definition of representation object classes. For example, if you wish to represent your model as a graphical map, the representation model will include at least the following classes:
a panel type to hold the map,
one or more types for the points to be displayed on the map background, and
one or more types for the connectors (directional lines) linking the points to each other.
Like the server model, the static representation model must be supplemented with a set of macros (for C++ components) or with preprocessed external declarations (for Java components).
These macros or declarations enable the representation model to be registered at component start-up with a representation model interpreter provided with the Rogue Wave Server C++ and Java component libraries. In particular, they declare a constructor for each representation class and a modification function for each attribute or relation of these classes. When a dynamic-view type specification file is loaded, the server creates a dynamic representation model and associates it with the view type. This dynamic representation model will be sent to any component requesting to open a view.
The
representation model interpreter uses the dynamic representation model to map the editing actions carried out by the server through the
generic representation protocol to the relevant functions of the appropriate representation classes. Thus, when notifications are received from the server via the generic protocol, the model interpreter will directly call the user-declared editing functions on the representation objects.
Version 5.7
Copyright © 2013, Rogue Wave Software, Inc. All Rights Reserved.