type Command

[add|copy|modify|print|list]type NAME {CLAUSE};

• NAME is the name you assign to the type. Type names must be unique. For more information, see About Administrative Object Names.
• CLAUSEs provide additional information about the type.

Syntax

add type NAME [ADD_ITEM {ADD_ITEM}];

ADD_ITEM provides additional information about the type:

icon FILENAME

description VALUE

attribute NAME {, NAME}

derived TYPE_NAME

abstract [true|false]

method PROG_NAME {, PROG_NAME}

form NAME {,NAME}

TRIGGER PROG_NAME [input ARG_STRING]

composed

[!|not]hidden

property NAME [to ADMINTYPE NAME] [value STRING]

history STRING

All these clauses are optional. You can define a type by simply assigning a name to it. If you do, 3DSpace assumes that the type is non-abstract, does not contain any explicit attributes, and does not inherit from any other types. If you do not want these default values, add clauses as necessary.

You might notice performance problems when adding a Type to a very large type hierarchy. If you experience this, from Oracle, turn off “cost-based optimization” and the situation should improve. See the Oracle documentation for more information.

Attribute Clause

This clause assigns explicit attributes to the type. These attributes must be previously defined with the Add Attribute command. For more information, see Add Attribute Command. If they are not defined, an error message is displayed.

Adding an attribute to a business type should not be included in a transaction with other extensive operations. This is a “special” administrative edit, in that it needs to update all business objects of that type with a default attribute.

If you add an attribute that is part of an index, the index is disabled. For more information, see MQL Concepts: Indexes.

A type can have any combination of attributes associated with it. For example, the following Add Type command assigns three attributes to the Shipping Form type:

add type “Shipping Form”
   description “Use for shipping materials to external locations”
   attribute “Label Type”
   attribute “Date Shipped”
   attribute “Destination Type”;

Three explicit attributes are associated with this type definition: Label Type, Date Shipped, and Destination Type. When the user creates a business object of a Shipping Form type, that person is required to provide values for these attributes. For example, the user might enter the following values at the attribute prompts:

These values are then associated with that instance along with any files the user might want to check in.

Derived Clause

Use the Derived clause to identify an existing type as the parent of the type you are creating. The parent type can be abstract or non-abstract. A child type inherits the following items from the parent:

• All attributes
• All methods
• All triggers
• Governing policies

  For example, if two policies list the parent type as a governed type, then those two policies can also govern the child type. In such a case, the child type is not listed as a governed type in the policy definitions.

• Allowed relationships

  For example, if a relationship allows the parent type to be on the FROM end, then the child type can also be on the FROM end of the relationship. The child type is not listed in the relationship definition.

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.

Assigning a parent type is an efficient way to define several object types that are similar because you only have to define the common items for one type, the parent, instead of defining them for each type. The child type inherits all the items listed above from the parent but you can also add attributes, programs, and methods directly to the child type. Similarly, you can (and probably will) assign the child type to a policy or relationship that the parent is not assigned to. Any changes you make for the parent are also applied to the child type.

For example, suppose you have a type named “Person Record”, which includes four attributes: a person’s name, telephone number, home address, and social security number. Now, you create two new types named “Health Record” and “Employee Record:”

add type “Health Record” derived “Person Record”;
add type “Employee Record” derived “Person Record”;

Both new types require the attributes in the Person Record type. Rather than adding each of the four Person Record attributes to the new types, you can make Person Record the parent of the new types. The new types then inherit the four attributes, along with any methods, programs, policies, and relationships for parent.

Abstract Clause

An abstract type indicates that a user will not be able to create a business object of the type. An abstract type is helpful because you do not have to reenter groups of attributes that are often reused. If an additional field is required, it needs to be added only once. For example, the “Person Record” object type might include a person’s name, telephone number, home address, and social security number. While it is a commonly used set of attributes, it is unlikely that this information would appear on its own. Therefore, you might want to define this object type as an abstract type.

Since this type is abstract, there will never be any actual instances made of the Person Record type. However, it can be inherited by other object types that might require the attribute information. Even though a user might never be required to enter values for the attributes of a Person Record object, they might have to enter values for these attributes for an object that inherited the Person Record attributes (such as an Employee Record or Health Record).

Use one the following clauses:

If the user can create an object of the defined type, set the abstract argument to false. If not, set the abstract argument to true. If you do not use the Abstract clause, false is assumed, allowing users to create instances of the type.

For example, in the following definition of Federal Individual Income Tax Form, the user can create an object instance because an Abstract clause was not included in the definition:

add type “Federal Individual Income Tax Form”
   derived “Federal Tax Form”;

This definition is equivalent to:

add type “Federal Individual Income Tax Form”
   derived “Federal Tax Form”
   abstract false;

Method Clause

The Method clause of the Add Type command assigns a method to the type. A method is a program that can be executed from 3DSpace when it is associated with the selected object. Programs selected as methods require a business object as a starting point for executing. For example, the following adds the existing program named “calculate tax” to the Federal Individual Income Tax Form.

add type “Federal Individual Income Tax Form”
   derived “Federal Tax Form”
   method “calculate tax”;

A user can then select any Federal Individual Income Tax Form object and execute the program “calculate tax.”

Form Clause

The Form clause of the Add Type command assigns a form design to the type. This form must be previously defined with the Add Form command. For more information, see Add Form. If it is not defined, an error message is displayed.

A type can have any number of forms associated with it. For example, the following Add Type command assigns three forms to the Employee types:

add type “Employee Record”
   description “employees of Acme, Inc.”
   form “insurance information”
   form "work history"
   form “pension and savings plans;

Trigger Clause

Event Triggers provide a way to customize behavior through Program objects. Triggers can contain up to three Programs, (a check, an override, and an action program) which can all work together, or each work alone. The Trigger clause specifies the program name, which event causes the trigger to execute, and which type of trigger program it is. Types support triggers for many events.

The format of the Trigger clause is:

TRIGGER PROG_NAME [input ARG_STRING]

| trigger EVENT_TYPE TRIGGER_TYPE [suppressinbatch] |
| trigger PROMOTE_EVENT_TYPE precommit              |
| trigger CREATE_EVENT_TYPE precreate               |

• EVENT_TYPE is any of the valid events for Types:

  addinterface	create	modifydescription
  addownership	delete	removefile
  batchclone	disconnect	removeinterface
  batchrevise	grant	removeownership
  changename	implicitcopy	revoke
  changeowner	implicitdelete	reserve
  changepolicy	implicitmajorrevision	transaction
  changetype	implicitminorrevision	unlock
  changevault	lock	unreserve
  checkin	majorrevision	CUSTOMEVENT_NAME
  checkout	minorrevision
  connect	modify*
  copy	modifyattribute
  * The modify EVENT_TYPE only supports action triggers.

• TRIGGER_TYPE is check, override, action, or precommit.
• PROMOTE_EVENT_TYPE is promote or demote.
• CREATE_EVENT_TYPE is create, connect, majorrevision, or clone.
• PROG_NAME is the name of the program to execute when the event occurs.
• ARG_STRING is a string of arguments to be passed into the program. When you pass arguments into the program they are referenced by variables within the program. Variables 0, 1, 2… and so on are reserved by the system for passing in arguments.
• Environment variable “0” always holds the program name and is set automatically by the system.
• Arguments following the program name are set in environment variables “1”, “2”,… and so on.
• The precreate trigger allows customization before instance object creation. The precreate trigger can be configured only with the event types create, connect, copy, and revision.

When included, the suppressinbatch keyword indicates that the specified trigger does not run when running in batch mode (batchrevise or batchclone). This keyword only applies during any of these event types:

• minorrevision
• majorrevision
• copy
• implicitcopy
• implicitmajorrevision
• implicitminorrevision

By default (suppressinbatch not included in the trigger definition), if a type has a copy trigger defined, during a batch operation (batchclone), the copy trigger is executed. If a type has minorrevision or majorrevision triggers defined, the trigger is executed during a batch revision operation. However, if the trigger is defined with suppressinbatch, the copy or minorrevision/majorrevision triggers are not fired during batch operations.

The selectable for the suppressinbatch keyword is issuppressedinbatch.

History Clause

The history keyword adds a history record marked “custom” to the type that is being added. The STRING argument is a free-text string that allows you to enter some information describing the nature of the addition. For more information, see Adding History to Administrative Objects.

Syntax

copy type SRC_NAME DST_NAME [MOD_ITEM {MOD_ITEM}];

• SRC_NAME is the name of the type definition (source) to copied.
• DST_NAME is the name of the new definition (destination).
• MOD_ITEM s are modifications that you can make to the new definition. For more information, see Modify Type.

History Clause

The history keyword adds a history record marked “custom” to the type that is being copied. The STRING argument is a free-text string that allows you to enter some information describing the nature of the copy operation. For more information, see Adding History to Administrative Objects.

modify type NAME [MOD_ITEM {MOD_ITEM}];

• NAME is the name of the type you want to modify.
• MOD_ITEM is the type of modification you want to make.

  You can make the following modifications. You only need to specify fields to be modified.

  Modify Type Clause	Specifies
  name NEW_NAME	The current type name changes to that of the new name entered.
  description VALUE	The current description, if any, changes to the value entered.
  icon FILENAME	The image is changed to the new image in the field specified.
  add attribute NAME	The named attribute is added to the type's list of explicit attributes.
  add form NAME	The named form is added to the type.
  add method PROG_NAME	The named method is added to the type.
  add trigger EVENT_TYPE PROG_TYPE PROG_NAME	The named trigger program name is added. This Modify clause must obey the same construction and syntax rules as when defining a type.
  remove attribute NAME	The named attribute is removed from the type's list of explicit attributes.
  remove form NAME	The named form is removed from the type.
  remove method PROG_NAME	The named method is removed from the type.
  remove trigger EVENT_TYPE PROG_TYPE	The named trigger program is removed from the type. This clause must obey the same construction and syntax rules as when defining a type.
  derived TYPE_NAME	The type being modified inherits attributes, methods, triggers, governing policies, and allowed relationships of the type named.
  abstract true	Business object instances of this type cannot be created.
  abstract false	Business object instances of this type can be created.
  hidden	The hidden option is changed to specify that the object is hidden.
  nothidden	The hidden option is changed to specify that the object is not hidden.
  property NAME [to ADMINTYPE NAME] [value STRING]	The named property is modified.
  add property NAME [to ADMINTYPE NAME] [value STRING]	The named property is added.
  remove property NAME [to ADMINTYPE NAME] [value STRING]	The named property is removed.
  history STRING	Adds a history record marked "custom" to the type that is being modified. The STRING argument is a free-text string that allows you to enter some information describing the nature of the modification. For more information, see Adding History to Administrative Objects.

Each modification clause is related to the arguments that define the type. For example, the following command changes the name and attribute list of the Shipping Form type:

modify type “Shipping Form” name “Shipping Label”
add attribute “Label Color”;