--- title: Setting the type information for module classes related: - https://docs.kentico.com/k10/custom-development/creating-custom-modules.md - https://docs.kentico.com/k10/custom-development/creating-custom-modules/creating-installation-packages-for-modules.md - https://docs.kentico.com/k10/custom-development/creating-custom-modules/creating-custom-binding-classes.md --- > Agent instructions: > **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown. > > - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version. > - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt). **Object type information** is code that sets the metadata of classes in Kentico. The system uses the type information to determine the basic properties and behavior of objects of the given class, including the following areas: - Relationships with other classes (parent-child, object references and bindings) - Object dependencies (automatic deleting of related objects) - [Export/Import](https://docs.kentico.com/k10/deploying-websites/exporting-and-importing-sites.md) - [Staging](https://docs.kentico.com/k10/deploying-websites/content-staging.md) - [Continuous integration](https://docs.kentico.com/k10/developing-websites/preparing-your-environment-for-team-development/setting-up-continuous-integration.md) - [Caching](https://docs.kentico.com/k10/configuring-kentico/optimizing-website-performance/configuring-caching.md) - [Macros](https://docs.kentico.com/k10/macro-expressions.md) - [REST service](https://docs.kentico.com/k10/integrating-3rd-party-systems/kentico-rest-service.md) - [Object cloning](https://docs.kentico.com/k10/custom-development/miscellaneous-custom-development-tasks/cloning-objects-through-the-api.md) - [Versioning](https://docs.kentico.com/k10/configuring-kentico/working-with-object-versioning.md) - Administration interface components (such as the [UniGrid](https://docs.kentico.com/k10/references/kentico-controls/ui-controls/unigrid.md) and [UniSelector](https://docs.kentico.com/k10/references/kentico-controls/ui-controls/uniselector.md)) - Building of administration interface elements based on portal engine templates The type information is defined in the code of individual _**Info**_ classes and consists of the following basic parts: - A unique _**object type name**_ as an identifier (the standard approach is to store the value in a public string constant named _OBJECT\_TYPE_). - A public object of the **ObjectTypeInfo** class (the standard name for the object is _TYPEINFO_). - The **RegisterObjectType** assembly attribute. The attribute assigns the type information definition to the _Info_ class via the unique _object type name_. > **Info:** **Terminology - Classes and Object types** > > To make the concepts easier to understand for developers who are new to class development in Kentico, the documentation uses the term **"class"** to refer to the sum of all metadata defined by a type information instance. This terminology matches the classes that you create in the administration interface of the **Modules** application. Technically, each type information definition represents an **"object type"** rather than a class, and some of the default Kentico classes have [multiple type information definitions](#classes-with-multiple-type-information-definitions). > > **Note**: The comments and XML-based documentation in the Kentico API use the term "object type" for this purpose. > **Tip:** **Tip**: You can find an overview of the available object types in the Kentico administration interface. Open the **System** application and view the **Object types** tab. ![Diagram showing the relationships between type information definitions, classes, object types and Info code. User and Category object types used as examples.](https://docs.kentico.com/docsassets/k10/setting-the-type-information-for-module-classes/Class_ObjectType_TypeInfo_diagram.png "Diagram showing the relationships between type information definitions, classes, object types and Info code. User and Category object types used as examples.") ## Configuring the type information for custom classes After creating a new class for a [custom module](https://docs.kentico.com/k10/custom-development/creating-custom-modules.md) in the **Modules** application, you can generate basic _Info_ and _InfoProvider_ class files on the **Code** tab of the class editing interface. The default code of the Info class automatically includes: - The _RegisterObjectType_ assembly attribute. - An object type name assigned to the _OBJECT\_TYPE_ constant (the value matches the class's code name by default). - A basic _ObjectTypeInfo_ definition (based on the fields defined for the class). Click **Save code** to create the class files in your project. You can then adjust the type information in the code of the given _Info_ class: 1. Open your Kentico solution in Visual Studio. 2. Edit the _Info_ class representing your module class. 3. Expand the **Type information** region. 4. Set the parameters in the **ObjectTypeInfo** constructor (the standard name for the object is _TYPEINFO_): - **providerType** - the [Type](http://msdn.microsoft.com/en-us/library/system.type%28v=vs.110%29.aspx) of the class's _InfoProvider_ class. For example: _typeof(ForumPostInfoProvider)_ - **objectType** - **objectClassName** > **Info:** **Class identifiers** > > Kentico classes have two different identifiers: > > - **object type name** _(objectType_ parameter) - defined in the code of the _Info_ class (typically in an _OBJECT\_TYPE_ constant). Serves as the primary identifier for the class. Use the object type name to select classes in the API, user interface components ([UniGrid](https://docs.kentico.com/k10/references/kentico-controls/ui-controls/unigrid.md), [UniSelector](https://docs.kentico.com/k10/references/kentico-controls/ui-controls/uniselector.md)), [REST calls](https://docs.kentico.com/k10/integrating-3rd-party-systems/kentico-rest-service/getting-data-using-rest.md), etc. > - **class code name** _(objectClassName_ parameter) - the code name assigned to the class in the Kentico administration interface. Identifies the class's definition in the database. For example, use the class code name when writing SQL where conditions for loading and filtering class records.Most classes use the same value for both identifiers, for example _cms.user_ for user objects. The purpose of having two different identifiers is to allow management of classes with [multiple type information definitions](#classes-with-multiple-type-information-definitions) that share the same _Info_ code and database class record. - **idColumn** - the name of the class field that stores the IDs of objects (i.e. the primary key column). Can be _null_ in rare cases (for example binding classes without an identity column). - **timeStampColumn** - the name of the class field that stores the last modification date for objects. Can be _null_. - **guidColumn** - the name of the class field that stores the [GUID identifiers](http://en.wikipedia.org/wiki/Globally_unique_identifier) of objects. Can be _null_. - **codeNameColumn** - the name of the class field that stores the unique text identifiers of objects. Can be _null_ for classes without a dedicated code name column. - **displayNameColumn** - the name of the class field that stores the visible names of objects (names used in the administration interface or on the live site). Can be _null_. - **binaryColumn** - the name of the class field that stores binary data for objects. Can be _null_. - **siteIDColumn** - the name of the class field that stores site IDs for site-related objects. Can be _null_. Only use site ID columns if you do not have a separate [binding class](https://docs.kentico.com/k10/custom-development/creating-custom-modules/creating-custom-binding-classes.md) for the site relationship. - **parentIDColumn** - the name of the class field that stores the IDs of parent objects. Set to _null_ for classes without a parent class. See [Setting parent-child relationships for classes](https://docs.kentico.com/k10/custom-development/creating-custom-modules/setting-the-type-information-for-module-classes/setting-parent-child-relationships-for-classes.md) to learn more. - **parentObjectType** - the _object type name_ of the class's parent (as defined in the type information of the parent class). Set to _null_ for classes without a parent class. 5. Use the [initializer](http://msdn.microsoft.com/en-us/library/bb384062.aspx) to set other properties for the **ObjectTypeInfo** object. - You must always set the **ModuleName** property to the _**code name**_ of the module under which the class belongs. - See [Reference - ObjectTypeInfo](https://docs.kentico.com/k10/custom-development/creating-custom-modules/setting-the-type-information-for-module-classes/reference-objecttypeinfo.md) for more information about the available properties. You can use the type information to configure a large number of scenarios and options for your classes. See the following sections to learn about the most common scenarios: > **Info:** > > ### [Adding references between classes](https://docs.kentico.com/k10/custom-development/creating-custom-modules/setting-the-type-information-for-module-classes/adding-references-between-classes.md) > > Define fields for your custom classes that store references (foreign keys) to objects of other classes and vice versa. > **Info:** > > ### [Setting parent-child relationships for classes](https://docs.kentico.com/k10/custom-development/creating-custom-modules/setting-the-type-information-for-module-classes/setting-parent-child-relationships-for-classes.md) > > Use the type information to define a hierarchy for the classes representing your module's data. Setting parent-child relationships for classes ensures that the system can provide many types of _**automatic**_ behavior. > **Info:** > > ### [Enabling export and staging for the data of classes](https://docs.kentico.com/k10/custom-development/creating-custom-modules/setting-the-type-information-for-module-classes/enabling-export-and-staging-for-the-data-of-classes.md) > > Configure the type information of your custom classes to allow transferring of data through the [Export - Import](https://docs.kentico.com/k10/deploying-websites/exporting-and-importing-sites.md) and [Staging](https://docs.kentico.com/k10/deploying-websites/content-staging.md) features. > **Info:** > > ### [Enabling continuous integration for custom classes](https://docs.kentico.com/k10/custom-development/creating-custom-modules/setting-the-type-information-for-module-classes/enabling-continuous-integration-for-custom-classes.md) > > Configure the type information of your custom classes to support synchronization of data using the Kentico [continuous integration solution](https://docs.kentico.com/k10/developing-websites/preparing-your-environment-for-team-development/setting-up-continuous-integration.md). ## Object type information example The following code is an advanced _ObjectTypeInfo_ example. This instance contains the metadata of the system's forum post objects (defined in the **ForumPostInfo** class). ```csharp title="Example" [assembly: RegisterObjectType(typeof(ForumPostInfo), ForumPostInfo.OBJECT_TYPE)] ... public class ForumPostInfo : AbstractInfo, ISearchable { // Sets the object type name for the forum post class public const string OBJECT_TYPE = "forums.forumpost"; public static ObjectTypeInfo TYPEINFO = new ObjectTypeInfo(typeof(ForumPostInfoProvider), OBJECT_TYPE, "Forums.ForumPost", "PostID", "PostLastModified", "PostGUID", null, "PostSubject", null, "PostSiteID", "PostForumID", ForumInfo.OBJECT_TYPE) { DependsOn = new List { new ObjectDependency("PostParentID", OBJECT_TYPE, ObjectDependencyEnum.NotRequired), new ObjectDependency("PostApprovedByUserID", UserInfo.OBJECT_TYPE, ObjectDependencyEnum.NotRequired), new ObjectDependency("PostUserID", UserInfo.OBJECT_TYPE, ObjectDependencyEnum.NotRequired) }, LogEvents = true, TouchCacheDependencies = true, SupportsVersioning = false, AllowRestore = false, ModuleName = "cms.forums", SupportsCloning = false, ObjectIDPathColumn = "PostIDPath", ObjectLevelColumn = "PostLevel", OrderColumn = "PostStickOrder", RegisterAsChildToObjectTypes = new List { ForumInfo.OBJECT_TYPE, ForumInfo.OBJECT_TYPE_GROUP }, ImportExportSettings = { IncludeToExportParentDataSet = IncludeToParentEnum.None, LogExport = false, LogProgress = false }, SynchronizationSettings = { LogSynchronization = SynchronizationTypeEnum.None, IncludeToSynchronizationParentDataSet = IncludeToParentEnum.None } }; ... } ``` ## Classes with multiple type information definitions A single _Info_ class can have multiple type information definitions representing different variants of the class. All variants share the same _Info_ code and database class record. Each type information definition must be registered under a unique object type name using a separate _RegisterObjectType_ assembly attribute. An example from the Kentico system classes is _CategoryInfo,_ which has one **ObjectTypeInfo** instance for [global and site page categories](https://docs.kentico.com/k10/managing-website-content/configuring-the-environment-for-content-editors/configuring-categories/creating-global-and-site-categories.md) and another for [personal categories](https://docs.kentico.com/k10/managing-website-content/working-with-pages/categorizing-pages/creating-personal-page-categories.md) that belong to individual users. We do not recommend creating custom classes with multiple type information definitions. Such classes require more complex type information settings or custom coding to achieve certain scenarios. > **Info:** **Handling of object type name requests** > > The following points summarize how the system loads the correct metadata when an object type name is requested: > > - The **RegisterObjectType** attributes register all available _**Info classes**_ under specific _**Object type names**_ during the initialization of the application. > - The system gets the Info class registered for the requested object type name. > - The **TypeInfo** override in the code of the Info class branches to the correct type information definition (_**ObjectTypeInfo**_ instance) based on a condition. > - The type information stores the _**Class code name**_, which allows the system to access the class definition in the database.