Types

A type identifies a kind of business object and the collection of attributes that characterize it.

Types are used to create business objects that represent any type of document or related information in your company. A business object might be one of the following types:

  • A document such as a drawing, specification, or memo
  • A concept such as a part, change description, or comment
  • A description such as a solid model or N/C path

For more information, see MQL Command Reference: type Command.

This page discusses:

Type Hierarchy

A type can be derived from another type. This signifies that the derived type is of the same kind as its parent. For example, a Book is a kind of Publication which in turn is a kind of Document. In this case, there may be several other types of Publications such as Newspaper, Periodical, and Magazine.

This arrangement of derived types is called a type hierarchy. Derived types share characteristics with their parent and siblings. This is called attribute inheritance. When creating a derived type, other attributes, methods, and triggers can be associated with it, in addition to the inherited ones. For example, all Periodicals may have the attribute of Page Count. This attribute is shared by all Publications and perhaps by all Documents. In addition, Periodicals, Newspapers, and Magazines might have the attribute Publication Frequency.

If a derived type has a defined trigger (from a relationship, for example), that trigger replaces any triggers inherited from the parent type. Only the triggers for the derived type will execute. If you want the inherited triggers to execute, call them from within the trigger for the derived type.

Note: When you print type DERIVEDTYPENAME, the inherited triggers output lists the triggers inherited from the parent type, even if they will not run because the derived type has its own trigger defined.

Implicit and Explicit Characteristics

Types use explicit and implicit characteristics:

  • Explicit characteristics are attributes that you define and are known to the apps.
  • Implicit characteristics are implied by the name only and are know only to the individual user.

For example, you may create a type called "Tax Form" which contains administrator-defined explicit attributes such as form number, form type, and tax year. Or, Tax Form may contain no explicit attributes at all.

When a type exists without administrator-defined attributes, it still has implicit characteristics associated with it. You would know a tax form when you saw it and would not confuse it with a type named "Health Form." But the characteristics you use to make the judgment are implicit—known only by you and not the apps.

Inherited Properties

Types can inherit properties from other types:

  • Abstract types act as categories for other types.

    Abstract types are not used to create any actual instances of the type. They are useful only in defining characteristics that are inherited by other object types. For example, you could create an abstract type called Income Tax Form. Two other abstract types, State Tax Form and Federal Tax Form, inherit from Income Tax Form.

  • Non-abstract types are used to create instances of business objects.

    With non-abstract types, you can create instances of the type. For example, assume that Federal Individual Tax Form is a non-abstract type. You can create business objects that contain the actual income tax forms for various individuals. One object might be for a person named Joe Smith and another one for Mary Jones. Both objects have the same type and characteristics although the contents are different based on the individuals.