Graphic Components > Architecture of Graphic Components > The Representation Model

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:

For more information about these predefined representation models, see the sections dealing with each individual graphic component in this documentation.

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. See section Introducing Cascading Style Sheets in the Styling documentation for further information.

Representation objects are linked to business objects. See the Business Objects and Data Sources documentation for more information about business objects. Representation objects are defined by the interface IlpRepresentationObject, which provides methods to:

Like business objects, representation objects include an attribute group that can be either static or dynamic. For more information, see Attribute Group in the Business Objects and Data Sources documentation.

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:

Predefined Representation Object Classes

JViews TGO includes predefined representation object classes for each one of the graphic components:

For more information about these classes, see the sections dealing with each individual graphic component in this documentation.