RADF Document Objects are a set of collaborating classes, which:
- Belong to the core and referenced by all parts of RADF
- Keep all the information about the structure of a 3D Document and its contents
- Help to create and manage objects in the Document
- Serve as a data source for viewers.
Categories of Document Objects
The main Document objects, shown below, may be divided into three categories:
- Structural Objects
- RadfDocument, DocumentNode, DocumentNodeCollection
- Content Objects
- ContentRegistry, AContentItem, ContentItem<T> objects that implement the IDocumentCompatible interface
- Services Objects
- All remaining objects
The RadfDocument object is the entry point into the RADF Document. It owns:
- ContentRegistry – Collection of all loaded registry content, created by the application data, each represented by AContentItem.
- root DocumentNode – Document structure represented by a tree; this node is in a single root of the tree and is an access point to the entire tree.
- ContentFactory – Class responsible for the creation of AContentItem items and for populating ContentRegistry (this is the only way to create AContentItem).
- DocumentNodeFactory – Class responsible for the creation of DocumentNode instances.
The DocumentNode object is the main building block of the Document tree. Each DocumentNode owns a collection of child DocumentNodes; each DocumentNodeCollection (which could be empty) has a single parent node. A tree built from DocumentNodes represents a composite structure with possibly multiple models and other data in different branches and levels.
The DocumentNodeCollection object represents children nodes of a DocumentNode.
The ContentRegistry object keeps and manages a collection of AContentItems.
An AContentItem object holds actual geometry data. Most DocumentNodes (except grouping nodes) point to a certain AContentItem. Each AContentItem keeps a collection of DocumentNodes (DocumentNodeContentCollection), in which it is referenced. Thus, the link between these two classes is bi-directional.
- The AContentItem knows which DocumentNodes references it.
- Each of the DocumentNodes that refers to the AContentItem has a reference to it.
A DocumentNodeContentCollection object is owned by AContentItem. This object holds back references to all DocumentNodes, where the AContentItem is referenced.
The IDocumentCompatible interface must be implemented by each class that could be used as ContentData in AContentItem.
Service type Document Objects add functionality to DocumentNodes from other components via:
- Attributes (NodeAttribute descendants)
- Bridge-type connections (using the Bridge design pattern)
A ContentFactory object creates ContentItem instances. This class is always used in ContentItem creation, directly or indirectly from inside other classes.
A DocumentNodeFactory object creates DocumentNode instances, populates the tree, and connects nodes with AContentItems. This class is always engaged in DocumentNode creation, directly or indirectly from inside DocumentNode methods.
The NodeAttribute object is used for holding DocumentNode attributes. The attributes represent optional data in the document that belong to DocumentNode. NodeAttributes do not contribute to document structure and do not affect content data. Examples of NodeAttribute classes include: NodeAttributeTransformation, NodeAttributeVisibility and NodeAttributeTransparency.
The NodeAttributeCollection object holds all the attributes that belong to a single DocumentNode. It controls attribute attachment and limits each node to one attribute of a certain type.