GeometryItems, GeometryDescriptors and GeometryDescriptorItems, such as those listed in the previous section's xml fragment, will be loaded into runtime java objects whose classes share the same names. These objects provide the what and where to draw data that is needed during runtime rendering.
The classes Primitive and Composite,
on the other hand, provide the runtime how to draw functionality.
Of course, objects of these classes utilize all of the geometry data you have
configured. We only mention these classes because you are allowed direct access to them
and sometimes need their instances when requesting new visual elements from a factory.
We should mention that a Primitive in the Tensegrity Graph API is not the same
thing as the word “primitive” used in other programming contexts. Primitives
are those parts of a Composite container that are responsible
for the atomic pieces of a drawing, such as lines, rectangles, polygons and so forth.
A Primitive basically takes information configured in
a geometry file and translates it into objects that are needed for rendering inside
a specific device or drawing context.
A Composite will hold one or more of these
Primitive objects and draw them in its own
CoordinateSystem. In short, you provide the information about
what to draw and our framework classes take care of the rest.
Although we cover these topics in much greater detail in the Elements chapter inside the Framework Manual, we shall provide you with some of the key geometry concepts here as well.
A GeometryItem defines a basic, atomic geometric shape, such
as a line, rectangle, ellipse, polygon or label. These items are created in a
geometry.xml or similarly named file and customized with attribute
parameters. These attributes define specific visual aspects of the geometry item and
vary depending on the item's basic type.
Once a GeometryItem has been defined, it can be referenced by
any number of composites, which group items into new geometry entities of type
GeometryDescriptor. This separation of items and composites
allows you to easily attain a consistent look and feel for all of your repository
elements by centralizing and reusing one or more GeometryItem
definitions.
Every GeometryItem consists of a name, a type and a list of
optional attributes. A minimal GeometryItem looks like this:
Example 5.2. Minimal GeometryItem
<!-- A Minimal Item --> <list name="GeometryItem"> <attribute name="Name" value="GEOMETRY_ITEM_NAME"/> <attribute name="Type" value="GEOMETRY_ITEM_TYPE"/> </list>
The GEOMETRY_ITEM_NAME text in the example above may be any unique string you wish.
The GEOMETRY_ITEM_TYPE text, however, must be one of several predefined values that
are described in the Elements chapter inside the
Framework Manual, which is distributed separately.
Please read that chapter when you are finished reading this section. There you will
discover which additional attributes are required for each geometry item type listed.
A GeometryDescriptorItem represents the first level of
GeometryItem (aka “basic item”) reuse. It
exists because basic items will be referenced by one or more composites (which
we will discuss next). Additionally, basic items do not specify any
coordinate data for the objects that draw them. This makes perfect sense. A composite
will need to position basic items relative to one another. In most cases,
drawing individual items in the context of a composite will not always begin in the
upper left-hand corner of a composite's coordinate system.
To make things perfectly clear, a GeometryDescriptorItem
represents an association between a single GeometryItem
(atomic geometry, basic item) and a single GeometryDescriptor
(composite geometry, to be discussed next). A GeometryDescriptorItem
element is embedded inside a <DescriptorItem> tag, which you can see in the XML
fragment in the previous section.
Every GeometryDescriptorItem, embedded inside a parent
GeometryDescriptor element, consists of its unique name,
the name of the referenced GeometryItem as well the drawing
coordinates within the composite.
A minimal GeometryDescriptorItem therefore looks like this:
Example 5.3. Minimal GeometryDescriptorItem
<!-- A minimal geometry descriptor item -->
<list name="DescriptorItem">
<attribute name="Name" value="GEOMETRY_DESCRIPTOR_ITEM_NAME"/>
<attribute name="GeometryItemName"
value="REFERENCED_GEOMETRY_ITEM_NAME"/>
<list name="Coordinates">
<attribute name="Coordinate" value="X_COMPONENT, Y_COMPONENT" />
<attribute name="Coordinate" value="X_COMPONENT, Y_COMPONENT" />
[...]
</list>
</list>
The Coordinate attributes listed above define
two points for the GeometryItem being referenced.
Depending on the item type, you may require more data than this. Please
refer to the Elements chapter inside the
Framework Manual for more detailed
information about specifying coordinate attributes for the various geometry
types available in our framework.
A GeometryDescriptor represents a grouping of one or more
basic items of type GeometryItem.
Each item referenced the GeometryDescriptor file definition
is represented as a uniquely named GeometryDescriptorItem.
Each GeometryDescriptor definition consists of a name,
a type, a coordinate system and, of course, a list of
GeometryDescriptorItem elements. In its minimal form
it looks like the following:
Example 5.4. Minimal GeometryDescriptor
<!-- a minimal geometry descritptor -->
<list name="GeometryDescriptor">
<attribute name="Name" value="GEOMETRY_DESCRIPTOR_NAME"/>
<attribute name="Type" value="GEOMETRY_DESCRITPOR_TYPE"/>
<list name="CoordinateSystem">
<attribute name="ScaleX" value="MINIMUM_VALUE, MAXIMUM_VALUE" />
<attribute name="ScaleY" value="MINIMUM_VALUE, MAXIMUM_VALUE" />
</list>
<!-- optional attributes of the geometry descriptor -->
<set name="Attributes">
<attribute name="ATTRIBUTENAME"
type="ATTRIBUTETYPE" value="ATTRIBUTEVALUE" />
[...]
</set>
<list name="DescriptorItems">
<list name="DescriptorItem">
[...]
</list>
</list>
</list>
A GeometryDescriptor has a Type
attribute that can be one of the following string enumerations:
Composite, CompositeLine or
CompositeGroup. Descriptor types are described in more
detail in the Elements chapter inside the
Framework Manual, which is distributed separately.
We recommend that you browse this chapter now to acquire a better understanding
of the attributes required for a more complex GeometryDescriptor.
© 2004, 2005 Tensegrity Software GmbH