Tables

Table Concept

Sometimes it is useful to take a dynamic extend structure to get specific properties to an object. Here you can use a table to abstract the interna of this structure, which holds properties to an object class.

We used this concept realising tables for:

The static table means that content of table is constant after creation of this table.

A dynamic table can increase the size of information stored in it by using this table. To do this it uses a hash table. If you need an item from the table, the table first looks if it already stores this item in the table and then gets this item from the hash. If this is not the case, the table looks at an external storage, e.g. a file, to get the item and bind it to the hash and return it. So you have a maximum of flexibility and performance. Use this table if you don't exectly know which, and how much properties you need for a set of objects.

All tables implement an abstract interface. This gurantees the extendablity of the tables. You can implement another table algorithm for the same function. The interface gurantess that it works with the existing methods.

Pixmap Tables

Figure 5-21. Pixmap Tables Overview

Pixmap Table Diagram

X stands for normal size pixmaps or small size pixmaps used for zoom.

Motivation

  • You can get in an easy way the correct pixmap for your node. Save each used node type one pixmap. Only the needed pixmaps are stored.

  • Pixmaps are better to maintain through different abstraction layers. You have different layers for different node classes.

  • It is easy to extend and adaped at new requirements.

  • It is flexible and high performant. The needed pixmap for a node you can get in an efficent way (ca. O(1)).

  • The used Pixmap for each node type is congureable.

Mechanics

Principle

We have split the pixmap table problem in 2 layers:

  • Node pixmap layer

  • Type node pixmap layer

Node Pixmap Layer

In this layer one default pixmap vector which contains one pixmap per node status will be load from disk by creating node pixmap table using default path and default filename including the status name. Now, if you use Get_Pixmap method this one will returned which has the status of Status argument.

Exception handling: If not exist the default pixmap Error Message will generated. Get_Pixmap returns a null pointer.

Type Node Pixmap Layer

Type Node Pixmap extends Node Pixmap Table. Additional a hash table will generated by the creation of this class. This hash table is used to get a type specific pixmap vector. If you have the type specific pixmap vector you can use Get_Pixmap method of standard node pixmaps to get the correct pixmap for the status.

Now, if you call Get_Pixmap at first it looks at the hash table, if there exist one for this type. Is it exist it will be returned and thats all. Otherwise it will try to load this from disk. If it exist then it will be stored in hash table and returned. At least it failed it will be used the default one (used means stored in hash table as the current one for this type and returned).

Exception handling: If used the default pixmap vector (because some of the typed pixmaps is not found), it will pint a Warning Message.

Implementation

Node_Pixmap implements the interface Pixmap_Table. Get_Pixmap returns the to drawn pixmap of the node (Node_Model) with this State Zoom declares the used zoom.

Node_Pixmap represents the nodes typeless. It means thatthe used pixmap depends only on state and zoom factor. For each State will used one pixmap which are stored in State_Pixmap-Array-Vector. By creation of Node_Pixmap this vector will initialized. The pixmaps will load from corresponding pixmap file. Here Get_Pixmaps_Filename and Get_Default_Id and Get_Default_Path is used to get the name of the pixmap file. The constructor Create(GC, Id):Node_Pixmap can be used if you need an other pixmap vector (it means the pixmap set, which contains one pixmap for each state) as the default one. This will be used in the Type Node Layer which is represented by Type_Node_Pixmap. As you can see this table is static.

Type_Node_Pixmap represents nodes which can have different types. It will use the hash table Node_Tables.Mapping to store Node_Pixmap-Vector depending on the type of the node. At first Get_Pixmap will look, if a vector to this type (the type of the node is known from GIF using the Node_Model of the node) is existant in the hashtable. If yes then it is reutrned. Otherwise it will be loaded from the file using the Node_Pixmaps Create(GC, Id)-Constructor. Id represents the node type here. The Node_Pixmap-Functionality is also used to get the pixmap for the state and zoom from Node_Pixmap-Vector-Array.

Node Attribute Pixmap

Figure 5-22. Attrbiute Tables Overview

Node Attribute Pixmap Diagram

Motivation

  • Have a structure which contains for each actribute a pixmap.

    Its not known which attribute pixmap are needed before it will be started Get_Pixmap(Model, State, Zoom) to get a Pixmap which contains all attribute of this node, which is given by Model.

    Fast access geting this pixmap.

Mechanics

Node_Attribute_Pixmap implements the Pixmap_Table-Interface just like Node_Pixmap.

Node_Attribute_Pixmap is represented as Dynamic Table, see at Table Concept (the Section called Table Concept). The hash table is here Attribute_Table.

Attr_Pos_Map contains the relative position to the node O-point at which the attributes are drawn. Here Get_Position from Interface Position_Mapis used to get the Position for an Attribute. Pot_Map implements this Interface by using a Parameter_Pot in which the different Attributes to the Position of itself is known. This Pot is generated from the configuration xml-file of OpenCAGE.

ID_Map generates a unique number for each set of attributes. In Dynamic_Bit_Vector each attribute gets a bit-flag in the number. If you want to have the Id of the Attribute_List, you take the logical or out of this masks. The first Attribure gets the lowest bit of the number and so is 1. For each new Attribute you get higher one bit. Note: There is a limit of bits in the number. All "new" Attributes "behind" the highest bit (this is represented by Max_Attrib_Count) are not represented and get the Id 0.

Note:The representation of Attributes in the Pixmap is limited by the following conditions:

  • The position of the attribute in the OpenCAGE-configuration file is defined in a correct way.

  • less than Max_Attrib_Count attributes are represented "before" this attribute.

Each attribute not fitting this conditions this conditions, will not be represented in the returned pixmap.

Name Tables

Figure 5-23. Name Table Overview

Name Table Diagram

Motivation

  • Configuration depended presentation of node names.

  • Easy extendable structure which generates node names, so that it can e.g. generate node name use different node names for different node types.

Mechanics

The Interface Node_Name specifies the method Get_Name which returns the to drawn name of the node using this model in correct format.

The class Format implements this interface. The name will generated by using an global configureable format for all nodes. The used format-type can extract from Pot in Create With the Set_Pot-Routine you can give it the Format-Object later. Create or Set_Pot respectively generate the format-type Format_Type which will use in Get_Name to generate the drawn name of the node from its Model used GIF.Get_Annotation. Get_Name cuts long names (it means names which are longer as 50 characters).

Zoom Tables

Figure 5-24. Zoom Table Overview

Zoom Table Diagram

Motivation

  • Easy extendable structure which manages the Zoom-Level and determines the position of nodes according to the Zoom-Level.

Mechanics

The Interface Zoom_Table specifies the methods like Zoom_In and Zoom_Out.

The class Simple_Zoom_Table implements this interface and basicly stores one Zoom-Level which can be incremented or decremented.

Color Tables

Figure 5-25. Color Table Overview

Color Table Diagram

Motivation

  • Structure to make configuration of edge colors more easy.

Mechanics

The class Edge_Type_Color_Table implements a hash table which maps Colors represented by a Sring (e.g. "red") to Edge_Models.

Pot_Type_Color_Table is the concrete implementation of Edge_Type_Color_Table. The Pot is the hash table mentioned before. It fetches its data from the OpenCAGE configuration file. As color strings, all colors specified in the local file rbg.txt can be used.