Runtime

## Package org.eclipse.gmf.runtime.emf.type.core

This package contains the classes that define primary classes in the Element Type framework.

See:
Description

Interface Summary
IClientContext: Interface of an object that defines a context to which clients of the element type registry may bind element types and advice.
IContainerDescriptor: Describes a model element container using an element matcher and containing references.
IEditHelperContext: The context of an editing gesture.
IElementMatcher: Determines whether or not a model element matches a fixed set of criteria.
IElementType: Interface used to define application-layer types that describe the kinds of elements that can be displayed, created, modified and destroyed.
IElementTypeDescriptor: Descriptor for an element type that has been defined in XML using the `elementTypes` extension point.
IElementTypeFactory: Factory for custom element types, which must implement one of the `IMetamodelType` or `ISpecializationType` interfaces.
IElementTypeRegistryListener: Interface implemented by clients wishing to know when element types are added to the element type registry.
IHintedType: A type that requires a semantic hint for view creation.
IMetamodelType: Interface used to define application-layer types that map directly to an `EClass`.
IMetamodelTypeDescriptor: Descriptor for a metamodel element type that has been defined in XML using the `elementTypes` extension point.
ISpecializationType: Interface used to define application-layer types that describe a specialization of a metamodel type.
ISpecializationTypeDescriptor: Descriptor for a specialization element type that has been defined in XML using the `elementTypes` extension point.

Class Summary
AbstractElementTypeEnumerator: Abstract superclass for types wishing to define constants that represent element types contributed in the `org.eclipse.gmf.runtime.emf.type.core.elementTypes` extension point.
AbstractElementTypeFactory: Abstract implementation for element type factories.
ClientContext: The implementation of the client context interface.
ClientContextManager: The context manager loads contexts from the `elementTypeBindings` extension point and makes them available to the element type registry.
EditHelperContext: The concrete implementation of the context of an editing gesture.
ElementType: Abstract implementation for application element types.
ElementTypeAddedEvent: Notification that an element type has been added to the `ElementTypeRegistry`.
ElementTypeRegistry: The registry of application element types, contributed by the `org.eclipse.gmf.runtime.emf.type.core.elementTypes` extension point, or registered directly through `ElementTypeRegistry.register(IMetamodelType)` or `ElementTypeRegistry.register(ISpecializationType)`.
MetamodelType: Represents an element type that maps directly to a metamodel element type ( `EClass`).
MultiClientContext: Implements a multi-context, which is a compound context representing a group of client contexts.
NullElementMatcher: Element matcher that matches nothing.
NullElementType: Singleton element type that has no `EClass`.
SpecializationType: Represents an application type that specializes other application types.

## Package org.eclipse.gmf.runtime.emf.type.core Description

This package contains the classes that define primary classes in the Element Type framework.

`IElementType`s are used to represent application types for the purpose of displaying and editing model elements. These types are contributed by extension point. A registry of such types, (`ElementTypeRegistry`) is maintained, and can be used to find:

- The element type that best matches a given EObject, and
- The element types that can be contained in a given feature of a given EObject

There are two kinds of element types, `IMetamodelType` and and specializations of metmodel types, `ISpecializationType`.

Each metamodel type defines the base icon, name and editing behaviour for all elements with its EClass. Only one metamodel type can be registered for each EClass in a given metamodel. The registry logs an error when an attempt is made to register a new metamodel type that has the same EClass as a type that has already been registered. The second type is rejected from the registry.

Specializations of metamodel types can define a new icon and name for their type, but can only contribute behaviour 'before' or 'after' the base editing behaviour. They cannot replace the base editing behaviour.

Custom element types (which must be subtypes of metamodel or specialization types) can be contributed to the registry using a `IElementTypeFactory`. Custom element types have arbitrary parameters specified by name and value pairs in XML.

The `NullElementType` can be specialized when an element type does not directly correspond to an EClass. Such specializations will not have any default editing behaviour. Instead, they will only have the 'before' and 'after' behaviour contributed by their edit helper advice. As well, the ElementTypeRegistry will not find these specializations when asking for types and advice that match an existing EObject. They will only be found when asking for types and advice that match the specialization types themselves.

See Also:
  `org.eclipse.gmf.runtime.emf.type.core.commands`, `org.eclipse.gmf.runtime.emf.type.core.edithelper`, `org.eclipse.gmf.runtime.emf.type.core.requests`,

  `org.eclipse.gmf.runtime.emf.type.core.elementTypes` extension point

Runtime

Guidelines for using Eclipse APIs.

Copyright (c) IBM Corp., Borland Software Corp., and others 2005,2006. All rights reserved.