skip to main content
TGO > Programmers documentation > Graphic components > Architecture of graphic components > The representation model
 
The representation model
Describes the representation model of the MVC paradigm.
*Overview
*Provides an overview of model representation in the MVC paradigm,
*Representation objects
*Describes representation objects in a graphic component model.
*Predefined representation object classes
*Identifies the predefined representation object classes.
Overview
According to the MVC paradigm, the model represents the application data. In JViews TGO, the model module, referred to as the representation model, is a container for representation objects to which it provides access. See Representation objects.
Whenever possible, JViews TGO representation models are derived from existing Swing models and like them use listeners to notify attached views of any changes in the data. Like Swing models, JViews TGO representation models use the JavaBeans™ Event model to implement the notification process. In JViews TGO, notifications are stateful, which means that they not only inform that a modification has occurred, but also indicate what is the nature of that modification.
Also, like Java™ Swing models, representation models impose a specific structure on the objects they hold. Therefore, JViews TGO provides a different representation model for each type of data structure to be addressed and hence for each type of graphic component displaying this data.
JViews TGO provides the following representation model interfaces:
*A network model defined by the class IlpNetworkModel.
*An equipment model defined by the class IlpEquipmentModel.
*A tree model defined by the class IlpTreeModel.
*A table model defined by the class IlpTableModel.
For more information about these predefined representation models, see the information on each graphic component.
Representation objects
Representation objects constitute the basic elements of a specific graphic component model. Therefore, they cannot be shared across graphic components. More specifically, these objects map business objects to the specific object type by which they will be represented in the related component. For example, a business object to be displayed in a table is stored in the table representation model as a row representation object. A business object to be displayed in a network view is stored in the network representation model as a network node or link.
Representation objects contain sufficient data to be graphically represented inside a graphic component, but are independent of a particular graphic rendering. The graphic component, where the representation object is inserted, translates its attribute information into graphic objects using a renderer. You can associate graphic settings either with a representation object class or with a specific instance of that class in order to customize the rendering process. For further information, see Introducing cascading style sheets.
Representation objects are linked to business objects. For more information about business objects, see Introducing business objects and data sources. Representation objects are defined by the interface IlpRepresentationObject, which provides methods to:
*Link the representation object to a business object.
*Retrieve its attribute group.
*Get and set attribute values.
*Notify listeners about modifications to the representation object.
Like business objects, representation objects include an attribute group that can be either static or dynamic. For more information, see Attribute group.
If you instantiate a representation object directly, you have to create a specific attribute group to define the list of attributes attached to that object. When a representation object is linked to a business object, it contains all the attributes defined for the associated business object plus any other additional attributes that you would like to include, for example, a computed attribute calculated from other attributes present in the business object.
A dynamic attribute group does not necessarily have to be based on that of the corresponding business objects. To create such an attribute group, you have the following choices:
*Skip the business object.
In basic applications, the user can directly instantiate representation objects. For example, when almost all data is displayed in only one graphic component or when the back-end application data is such that sharing the business model data across components is difficult.
*Use the business object directly.
The attribute group of the representation object is taken from that of the corresponding business object.
*Extend the business object.
The representation object may add extra attributes or hide some of the attributes present in the connected business object. Certain attribute values can be stored locally in the representation object.
*Define a custom attribute group.
The attribute group for the representation object is completely different from that of the business object. Individual attributes may obtain their value directly or indirectly from the business object attributes, but most of the attributes are not the same.
Predefined representation object classes
JViews TGO includes predefined representation object classes for each one of the graphic components:
*IlpNetworkNode represents a node in a network.
*IlpNetworkLink represents a link connecting two nodes in a network.
*IlpEquipmentNode represents a piece of equipment in an equipment view.
*IlpEquipmentLink represents a link connecting two nodes in an equipment.
*IlpTreeNode represents a node in a tree.
*IlpTableRow represents a row in a table.
For more information about these classes, see the information on each graphic component.

Copyright © 2018, Rogue Wave Software, Inc. All Rights Reserved.