Chapter 3. Elements

Chapter 3. Elements
Prev	Part I. Creating and Modeling Graphs	Next

This chapter explains how to add new elements to or modify existing elements of a Repository configuration by explaining how to alter the required XML definition files that contain the basic and aggregated Repository data. An example at the end of this chapter will reinforce the concepts and constants introduced in the following sections.

A Repository in the Tensegrity Graph Framework is not the same thing as a “repository” used in other domain vocabularies, such as in RDMS contexts, where the words “database, store, persistence and repository” are quite often used interchangeably. To avoid confusion, you might think of our Repository as a “library” of predefined, domain-specific VisualGraph elements that may be copied or “instantiated” into your working design documents.

All visual Repository elements used in your application are defined by structured data contained in four distinct XML files. Three of these files contain specific data that is merged into the fourth and final aggregated element file, as shown in this table:

Table 3.1. Repository Files

File	Definition
`geometry.xml`	Contains the atomic `GeometryItem` and aggregated `GeometryDescriptor` fragments that allow users to configure runtime `Primitive` and `Composite` instances. Geometries describe basic geometrical shapes without any notion of styles and style formats.
`styles.xml`	Contains the atomic `StyleItem` and composite `StyleDescriptor` fragments that allow users to configure runtime `Primitive` objects. A type-aware `StyleItem` aggregates zero or more stroke, paint, font and/or marker `Format` configurations. While you read this chapter, try not to be confused by the “style” attribute found inside most of these `Format` definitions. Just as a `StyleItem` requires a type attribute to describe its basic form, so too does a `Format` definition require such a type attribute. In the latter case, however, a `Format` definition's type attribute is named “style.”
`rules.xml`	Contains the definition of runtime interaction rules which influence user-interaction in any type of `VisualGraph` or `VisualSubgraph`.
`elements.xml`	Contains the definition of new Repository elements by referencing definitions contained in the previous three files.

Introduction

While a GeometryItem defines the geometry (shape) of a Repository element, a StyleItem defines the visual appearance of it. Both types of items can be grouped by collection definitions called GeometryDescriptor and StyleDescriptor respectively.

The structure of both descriptor types is identical and looks as follows:

Example 3.1. Structure of geometry and style descriptors

<list name="ITEM_NAME">
 <attribute name="ATTRIBUTE_NAME" value="ATTRIBUTE_VALUE"/>
 [...]
</list>
<list name="DESCRIPTOR_NAME">
 <attribute name="ATTRIBUTE_NAME" value="ATTRIBUTE_VALUE"/>
 [...]
  <list name="DescritporItems">
    <list name="DescritporItem">
      <attribute name="ATTRIBUTE_NAME" value="ATTRIBUTE_VALUE"/>
      [...]
    </list>
    [...]
  </list>
</list>

The following figure shows the structure of a complex element that represents a Switch/Transducer, which is used in fluid power diagrams to document hydraulic or pneumatic control systems.

Figure 3.1. Structure of a Geometry

This element consists of many different basic geometrical shapes, including rectangles, lines, polygons and labels. Each shape is called a GeometryItem and describes an individual geometrical part of the whole: a dashed line, a continuous line, a rectangle, or something else. Inside the GeometryDescriptor, which composes all of these basic geometric parts, each referenced GeometryItem is placed inside a CoordinateSystem.

A StyleItem, on the other hand, describes the visual appearance of a particular GeometryItem. In this example we have five different StyleItem definitions for five different GeometryItem definitions. The StyleDescriptor subsequently specifies which StyleItem is associated with which GeometryItem.

There are two ways to create an association between a GeometryItem and a StyleItem. The first way is to simply list them in the same order within the StyleDescriptor as they appear in the GeometryDescriptor. The second way is to add an attribute to a StyleItem with the name of the corresponding GeometryItem. Both ways are explained later in more detail in section GeometryItem and StyleItem respectively.

Prev	Up	Next
Composite Groups	Home \| ToC	Geometries